[Résolu] Problème de connexion à un dédié

tu n'aurais pas un antivirus internet machin chose?
en le désactivant?

Ou bien c'est un problème de routage ou bien...
mais avec le nom de domaine masqué, donc pas d'IP donc pas moyen de reproduire, pas moyen de donner de l'aide.
Sorry.

Non aucun antivirus ni pare-feu côté box/client.

Problème de routage côté client ? Sachant que comme indiqué je n'ai eu aucun souci en plus de 5 ans et cela fonctionne depuis différents vpn en France ou non.
Le domaine est le suivant : popallo.com

```text je suis chez free:
```text
curl --head popallo.com
curl: (7) Failed to connect to popallo.com port 80:
Connexion terminée par expiration du délai d'attente

curl --head https://popallo.com
curl: (7) Failed to connect to popallo.com port 443:
Connexion terminée par expiration du délai d'attente
```

serveur de noms out: https://zonemaster.fr/result/434c41b9e6dfdaa6

```text
dig +short popallo.com SOA
no servers could be reached [connection]

dig +nocmd +noall +answer popallo.com NS @ks3359686.kimsufi.com.
;; connection timed out; no servers could be reached

dig +nocmd popallo.com MX +noall +answer @ks3359686.kimsufi.com.
;; connection timed out; no servers could be reached

dig +nocmd popallo.com A +noall +answer @ks3359686.kimsufi.com.
;; connection timed out; no servers could be reached

dig +nocmd www.popallo.com A +noall +answer @ks3359686.kimsufi.com.
;; connection timed out; no servers could be reached

dig +nocmd popallo.com AAAA +noall +answer @ks3359686.kimsufi.com.
;; connection timed out; no servers could be reached

dig +nocmd www.popallo.com AAAA +noall +answer @ks3359686.kimsufi.com.
;; connection timed out; no servers could be reached
```

```text
whois popallo.com
Updated: 2018-05-01T14:52:41Z

Name Server: KS3359686.KIMSUFI.COM
Name Server: NS.KIMSUFI.COM
``` ```

Mais comment un tel truc est possible alors que je viens juste de tester en 4g depuis Bouygues et j'accède bien au domaine sans problème ?!
Je ne m'explique pas non plus le zonecheck dès lors que celui ci n'a jamais retourné ce genre de résultats auparavant..

je sors de mes expériences...
cela supposerait que tes NS ne répondent pas à free et zonemaster?
problème chez Ovh?

d'autres confirmeront?

```text sur ton site, on est sensé voir un smiley :) ?
(ce que je vois avec kproxy.com)

via wanadoo, c'est ok, :) aussi:
```text
curl --head https://popallo.com/
HTTP/1.1 200 OK
Date: Sun, 16 Dec 2018 07:33:02 GMT
Server: Apache
Content-Length: 3
``` ```

Ahah oui c'est bien un smiley sur ce domaine là 😁

```text je verrais bien un problème de route entre free et ovh

```text
ping 37.187.96.105
PING 37.187.96.105 (37.187.96.105) 56(84) bytes of data.
^C
--- 37.187.96.105 ping statistics ---
242 packets transmitted, 0 received, 100% packet loss, time 984ms

Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-16 09:04 CET
Note: Host seems down.
``` ```

Mais comment un tel truc est possible alors que je viens juste de tester en 4g depuis Bouygues et j'accède bien au domaine sans problème ?!
Je ne m'explique pas non plus le zonecheck dès lors que celui ci n'a jamais retourné ce genre de résultats auparavant..

C'est un pb de DNS
les DNS associés à ton domaine sont
ks3359686.kimsufi.com.
ns.kimsufi.com.

Si l'on requête le serveur DNS primaire ks3359686.kimsufi.com, les réponses sont OK
Si l'on requête le serveur DNS secondaire de OVH ns.kimsufi.com. il ne donne aucune réponse.

Sans entrer dans les détails techniques, c'est pour ça que cela fonctionne pour une connexion et pas pour une autre.

Relances bind9 et regardes les logs.

Cordialement,
Boris.

pourquoi ça marche de wanadoo et pas free?
```test
# from wanadoo
dig +nocmd popallo.com A +noall +answer @ks3359686.kimsufi.com
popallo.com. 38400 IN A 37.187.96.105

# from free
dig +nocmd popallo.com A +noall +answer @ks3359686.kimsufi.com
;; connection timed out; no servers could be reached
```
le NS est le même pourtant

et il suffit que un des deux répondent

et regarder zonemaster aussi...

En effet il semblerait qu'il existe un problème sur le ns.kimsufi.com.

Après avoir redémarré bind :
connection refused resolving 'ns.kimsufi.com/A/IN': 51.68.107.109#53

Après différents tests c'est vraiment très curieux, depuis différents vpn un coup j'y accède un coup non, comme si parfois le dns pris en compte est mon serveur puis un autre coup c'est le secondaire (qui lui ne semble donc pas fonctionner). Je ne maitrise pas assez ce domaine pour en connaitre la cause réel, toujours est-il que le DNS secondaire semble être la cause du dysfonctionnement ?!

un seul NS qui répond suffit pour résoudre un domaine, d'autant que ls ns.kimsufi.com n'est pas le primaire
un seul NS défaillant ne peut être la cause, heureusement, sinon pourquoi en utiliser plusieurs

D'autant que quand on lance un ping depuis une connexion qui ne veut pas s'y connecter, l'ip qui est renvoyée est la bonne à savoir 37.187.96.105

ah?.. ça veut dire que pendant un moment, ton résolveur a pu se connecter à un de tes NS

moi résolveur cloudfare ou openNic, nada
sur le wanadoo, DNS wanadoo, ça résoud

J'ai modifié le serial de toutes mes zones et ça semble être le retour à la normale, tout du moins sur ma connexion sfr (meaculpa les concernants, ce n'était donc pas leur faute). Je ne saurai donc pas ce qui s'est passé mais quoi qu'il en soit vos différents retours m'ont aidés. Merci à tous :)

```text depuis free, toujours out:
```text
dig +nocmd popallo.com A +noall +answer @ks3359686.kimsufi.com
;; connection timed out; no servers could be reached
```

zone master toujours en erreurs: https://zonemaster.fr/result/ccb47b657ee356b9 ```

pff bah zut alors :'(

j'avais tout compris pourtant :/

tu as déclaré le truc au support?

Oui j'ai fais un ticket sur le support avant hier

J'ai crié victoire trop vite.. ne fonctionne tjrs pas en fait aha, j'étais sur le vpn (ne me jetez pas la pierre).

remettre la zone sur des ns Ovh?
mais le support répondra alors que tout va bien

Oui je pense que je ne vais toucher à rien niveau configuration des zones car tout fonctionnait sans problème (tout du moins je le croyais ?) avant.

connection refused resolving 'ns.kimsufi.com/A/IN': 51.68.107.109#5

À partir de ton serveur si tu fais un
```
telnet ns.kimsufi.com 53
```
est ce que c'est OK ?
ça doit te retourner
```
Trying 2001:41d0:3:1c7::1...
Connected to ns.kimsufi.com.
Escape character is '^]'
```
si ça ne fonctionne pas tentes un ping
```
ping -c1 ns.kimsufi.com
```
quelle IP vois tu ?
ça doit te retourner
```
PING ns.kimsufi.com (213.186.33.199) 56(84) bytes of data.

--- ns.kimsufi.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
```
sinon peux-tu nous copier/coller ton fichier /etc/bind/named.conf

Cordialement,
Boris.

```text avant de s'occuper du secondaire, on ne doit pas s'occuper du primaire... inaccessible ?
```text
dig +nocmd popallo.com A +noall +answer @ks3359686.kimsufi.com
;; connection timed out; no servers could be reached
```
selon les réseaux? ```

Le problème est que je ne vois pas quoi faire dans la mesure où cela fonctionne sur la majorité des connexions que j'ai testé. Et ça ne semble pas cibler un opérateur précis car en testant cet après midi sur une connexion free cela fonctionnait bien. Je ne comprends pas l'origine du problème.

telnet ns.kimsufi.com 53

Pour ça j'ai bien ce qui est attendu.

Pour le ping j'ai ça :
```
PING ns.kimsufi.com (213.186.33.199) 56(84) bytes of data.
From ks3359686.kimsufi.com (37.187.96.105) icmp_seq=1 Destination Port Unreachable

--- ns.kimsufi.com ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
```

Et voici la zone :

```

$ttl 38400
popallo.com. IN SOA ks3359686.kimsufi.com. popallo.popallo.com. (
2018121600
10800
3600
1209600
38400 )
popallo.com. IN A 37.187.96.105
popallo.com. IN NS ks3359686.kimsufi.com.
popallo.com. IN NS ns.kimsufi.com.
www IN CNAME popallo.com.
```

Le named.conf j'ai ça
```
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
```

Le named.conf.options :
```
acl "trusted" {
127.0.0.1; # ns1 - can be set to localhost
213.186.33.199; # ns2
37.187.96.105; # host1
};

options {
directory "/var/cache/bind";

recursion yes;
allow-recursion { trusted; };
allow-transfer { none; };

dnssec-validation auto;

auth-nxdomain no; # conform to RFC1035

// listen-on-v6 { ::1; };bash: c: command not found

// listen-on { 127.0.0.1; };
// allow-recursion { 127.0.0.1; ::1; };

};
```

@popallo
et dans named.conf tu n'as pas

zone "popallo.com" {
...
...
}

?

J'ai ça dans le named.conf.local
```
zone "popallo.com" {
type master;
file "/etc/bind/zones/popallo.com.hosts";
allow-transfer {
37.187.96.105; 213.186.33.199;
};
};
```

allow-transfer {
37.187.96.105; 213.186.33.199;
};

@popallo
Ta conf me semble correcte meme si
```
allow-transfer {
37.187.96.105; 213.186.33.199;
};
```
pourrait être remplacé par ```
allow-transfer { 213.186.33.199; };
```
enfin dans tous les cas ce n'est pas bloquant
As- tu correctement configuré le DNS secondaire dans ton panel Kimsufi (onglet DNS).

Oui le DNS secondaire a été déclaré sur l'interface admin d'ovh, je l'avais fais au moment d'acquérir le domaine donc pas de problème de ce côté là non plus :'(

Voici la réponse du support ovh :
>
Effectivement le tracert que vous m'avez fourni ne parvient pas jusqu’à votre
service ks3359686.kimsufi.com.
Cependant, le blocage ne s'effectue pas juste après le nœud
vl7.16k.fr.eu.6k.fr.eu.
>
En effet, le fait que deux sauts apparaissent après ce nœud, indique que la
demande est bien transmise à un équipement réseau.
Le fait que vous ayez des étoiles ainsi que le message "Délai d’attente de la
demande dépassé" est normal.
>
Les équipements réseau de ces sauts ne sont :
>
- soit pas configuré pour répondre à la requête.
- Soit ils sont trop occupé pour répondre.
>
Toutefois, ils transmettent tout de même la requête à l'équipement réseau
suivant.
>
Je constate que votre demande date du 13 décembre.
De ce fait, rencontrez-vous toujours ce comportement ?
>
Avez-vous un pare-feu paramétré sur la machine ?
Si oui, avez-vous vérifié si votre nouvelle ip été bien trusté par ce pare-feu
ou par fail2ban si installé ?

Du coup cela ne m'avance pas plus pour le moment, j'ai donc répondu et attend un nouveau retour de leur part`.

Pensez-vous que si je retourne sur la zone par défaut pour mon domaine (fourni depuis le manager ovh) cela pourrait résoudre le problème ?!

Nouvelle réponse du support mais toujours pas de solution :
>
Effectivement le serveur DNS ns.kimsufi.com ne répond pas pour votre domaine
popallo.com.
Cela indique qu'il n'existe pas de zone DNS sur ce serveur pour ce domaine.
>
Le fonctionnement de ce serveur est un peu particulier dans le sens où il va
venir récupérer la zone DNS existant sur le serveur DNS principal. (dans votre
cas, le serveur ks3359686.kimsufi.com)
Ce genre de comportement est souvent visible si le serveur principal n'est pas
joignable sur le port 53 (port bind par défaut).
>
En essayant la commande nmap ainsi que la commande telnet sur votre serveur
ks3359686.kimsufi.com, je remarque que le port 53 est clos.
Avec ce port fermé, la résolution DNS ne s'effectue plus et traduit ce
comportement.
>
Une fois que vous aurez ouvert le port 53 de votre machine, tout va rentrer en
ordre.
>
Pour l'ouverture de ce port, je vous invite à vérifier les points suivants :
>
- Qu'un service bind est bien installé et actif sur le serveur
- Qu'une règle de pare-feu type iptable ne bloque pas ce port.

Sachant que du coup, en testant moi même le telnet depuis deux serveurs dédiés différents, sur l'un des serveurs ça passe alors que sur le second ça ne passe pas ... :'(

```text ah, car un parefeu ou un bind va sélectionner selon le réseau distant qui requête?

tu es tombé sur un champion ou c'est toi qui est vicieux?

```
# wanadoo
dig +nocmd popallo.com A +noall +answer @ks3359686.kimsufi.com
popallo.com. 38400 IN A 37.187.96.105

# free
dig +nocmd popallo.com A +noall +answer @ks3359686.kimsufi.com
;; connection timed out; no servers could be reached
```

et si pas de zone, pourquoi wanadoo résoud?

edit:
```text
#wanadoo
nmap -p 53 ks3359686.kimsufi.com

Starting Nmap 7.40 ( https://nmap.org ) at 2018-12-18 16:33 UTC
Nmap scan report for ks3359686.kimsufi.com (37.187.96.105)
Host is up (0.029s latency).
rDNS record for 37.187.96.105: popallo.com
PORT STATE SERVICE
53/tcp open domain

Nmap done: 1 IP address (1 host up) scanned in 1.31 seconds
``` ```

C'est exactement ce que je tente d'expliquer mais je ne sais pas si la personne du support a moyen de se rendre compte réellement de ce problème. C'est vraiment curieux comme comportement et je n'arrive pas à croire que mon serveur soit capable de faire une sélection de la sorte. N'ayant pas la main sur ce qui se passe à côté du serveur j'ai bien peur que la seule solution soit de dire au revoir à mon serveur bind et remettre la zone qu'ovh fournie :'( c'est frustrant.

```text pfff, et en changeant de DNS, ça changera quoi pour moi ? !!!

```text
traceroute 37.187.96.105
traceroute to 37.187.96.105 (37.187.96.105), 30 hops max, 60 byte packets
...
7 gsw-1-a9.fr.eu (54.36.50.110) 7.804 ms 8.157 ms 8.334 ms
8 be102.gra-g1-nc5.fr.eu (91.121.215.176) 12.743 ms 13.441 ms 12.924 ms
9 * * *
...
30 * * *
``` ```

bouygues mobile, paris, ça résoud et ça ping

Bon je n'aurai pas de solution de la part d 'ovh, pour eux le problème vient de mon serveur ...

>Un blocage ou une erreur au niveau du routage vous empêcheraient complètement
de vous connecter à la machine.
De même, vous n'auriez pas de réponse du service DNS non plus.
>
De mon côté, j'ai toujours un port fermé avec la commande "nmap" ou "telnet"
et ce même depuis une connexion externe.
>
Il semblerait qu'il y ait un blocage sur le serveur en lui-même.
Ce blocage pourrait être dû :
>
- Soit par le pare-feu du serveur
- Soit par la configuration de bind
- Soit par un comportement anormal de la machine.
>
N'ayant aucun moyen de voir la configuration logicielle de votre service, je
ne peux pas être plus précis et ne peux pas vous accompagner plus dans la
résolution de ce blocage.

Je vais tenter de changer la zone en prenant celle fournie par ovh par défaut mais même si cela fonctionne je ne saurai donc toujours pas pourquoi côté serveur ça bloquerait sachant que dans les logs je ne vois rien qui pourrait m'aiguiller.

réponse toujours sans justification technique, mais je suis curieux de voir le résultat...

pourquoi les resolveurs wanadoo sont plus efficaces que cloudflare?
pourquoi sans avoir besoin de résoudre, je n'atteins pas ton serveur

je suis impatient :/

Après il y a quelque chose que je ne comprends pas trop, quand je relance bind9 :
déc. 19 16:47:57 popallo.com named[14734]: connection refused resolving 'ns.kimsufi.com/AAAA/IN': 51.68.107.109#53
déc. 19 16:47:57 popallo.com named[14734]: connection refused resolving 'ns.kimsufi.com/A/IN': 51.68.107.109#53

L'ip 51.68.107.109 ne correspond en rien à ns.kimsufi.com.. ?! Lorsque je ping ns.kimsufi.com depuis le serveur j'ai l'ip 213.186.33.199 qui remonte.

En faisant une recherche cette ip correspond à ns112.ovh.net, qu'est-ce que ça vient faire là ?!

```text rDNS record for 37.187.96.105: popallo.com

arf, de free ou wanadoo, nskimsufi est down

```text
nmap -p 53 ns.kimsufi.com

Starting Nmap 7.40 ( https://nmap.org ) at 2018-12-19 16:02 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 4.17 seconds
```

ah oui :
```text
dig +short -x 51.68.107.109
ns112.ovh.net.
```
rien à voir avec ns.kimsufi.com :/

dans ta conf bind, tu as déclaré ns112?

ce qui n'explique toujours pas pour le réseau free n'atteint pas ton serveur, à moins que m'avoir blacklisté? ```

Pas blacklisté sur mon serveur pour sûr.

Chose étrange avec le ns.kimsufi.com, si je fais un
````
sudo nmap -sS -sU ns.kimsufi.com
````
Cela me dit
>Host seems down.

Si je fais un
````
sudo nmap -sS -sU -Pn ns.kimsufi.com
````
Cela me dit
>Nmap scan report for ns.kimsufi.com (213.186.33.199)
Host is up (0.0043s latency).
Other addresses for ns.kimsufi.com (not scanned): 2001:41d0:3:1c7::1
Not shown: 999 filtered ports, 999 open|filtered ports
PORT STATE SERVICE
53/tcp open domain
53/udp open domain

dans ta conf bind, tu as déclaré ns112?

Nulle part j'ai ça.

@popallo
Tu peux faire un
```
iptables -L
```

cdlt,
Boris.

```text Ca va piquer les yeux :

```text
Chain INPUT (policy DROP)
target prot opt source destination
pgl_in all -- anywhere anywhere ! ctstate RELATED,ESTABLISHED mark match ! 0x14
ufw-before-logging-input all -- anywhere anywhere
ufw-before-input all -- anywhere anywhere
ufw-after-input all -- anywhere anywhere
ufw-after-logging-input all -- anywhere anywhere
ufw-reject-input all -- anywhere anywhere
ufw-track-input all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
pgl_fwd all -- anywhere anywhere ! ctstate RELATED,ESTABLISHED mark match ! 0x14
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ufw-before-logging-forward all -- anywhere anywhere
ufw-before-forward all -- anywhere anywhere
ufw-after-forward all -- anywhere anywhere
ufw-after-logging-forward all -- anywhere anywhere
ufw-reject-forward all -- anywhere anywhere
ufw-track-forward all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
pgl_out all -- anywhere anywhere ! ctstate RELATED,ESTABLISHED mark match ! 0x14
ufw-before-logging-output all -- anywhere anywhere
ufw-before-output all -- anywhere anywhere
ufw-after-output all -- anywhere anywhere
ufw-after-logging-output all -- anywhere anywhere
ufw-reject-output all -- anywhere anywhere
ufw-track-output all -- anywhere anywhere

Chain DOCKER (1 references)
target prot opt source destination

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere

Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain pgl_fwd (1 references)
target prot opt source destination
RETURN all -- 10.8.0.1 10.8.0.1
RETURN all -- 10.8.0.1 37.187.96.0/24
RETURN all -- 10.8.0.1 172.17.0.0/16
RETURN all -- 37.187.96.0/24 10.8.0.1
RETURN all -- 37.187.96.0/24 37.187.96.0/24
RETURN all -- 37.187.96.0/24 172.17.0.0/16
RETURN all -- 172.17.0.0/16 10.8.0.1
RETURN all -- 172.17.0.0/16 37.187.96.0/24
RETURN all -- 172.17.0.0/16 172.17.0.0/16
RETURN all -- anywhere cdns.ovh.net
RETURN all -- anywhere localhost.localdomain
DROP all -- anywhere anywhere mark match 0xa
NFQUEUE all -- anywhere anywhere NFQUEUE num 92

Chain pgl_in (1 references)
target prot opt source destination
RETURN all -- 10.8.0.1 anywhere
RETURN all -- 37.187.96.0/24 anywhere
RETURN all -- 172.17.0.0/16 anywhere
DROP all -- anywhere anywhere mark match 0xa
NFQUEUE all -- anywhere anywhere NFQUEUE num 92

Chain pgl_out (1 references)
target prot opt source destination
RETURN all -- anywhere 10.8.0.1
RETURN all -- anywhere 37.187.96.0/24
RETURN all -- anywhere 172.17.0.0/16
RETURN all -- anywhere cdns.ovh.net
RETURN all -- anywhere localhost.localdomain
REJECT all -- anywhere anywhere mark match 0xa reject-with icmp-port-unreachable
NFQUEUE all -- anywhere anywhere NFQUEUE num 92

Chain ufw-after-forward (1 references)
target prot opt source destination

Chain ufw-after-input (1 references)
target prot opt source destination
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-ns
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:netbios-dgm
ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:netbios-ssn
ufw-skip-to-policy-input tcp -- anywhere anywhere tcp dpt:microsoft-ds
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootps
ufw-skip-to-policy-input udp -- anywhere anywhere udp dpt:bootpc
ufw-skip-to-policy-input all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
target prot opt source destination

Chain ufw-after-logging-input (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Chain ufw-after-logging-output (1 references)
target prot opt source destination

Chain ufw-after-output (1 references)
target prot opt source destination

Chain ufw-before-forward (1 references)
target prot opt source destination
ACCEPT all -- 10.8.0.0/24 anywhere
ACCEPT all -- anywhere 10.8.0.0/24
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp source-quench
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request
ufw-user-forward all -- anywhere anywhere

Chain ufw-before-input (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ufw-logging-deny all -- anywhere anywhere ctstate INVALID
DROP all -- anywhere anywhere ctstate INVALID
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp source-quench
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp parameter-problem
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ufw-not-local all -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900
ufw-user-input all -- anywhere anywhere

Chain ufw-before-logging-forward (1 references)
target prot opt source destination

Chain ufw-before-logging-input (1 references)
target prot opt source destination

Chain ufw-before-logging-output (1 references)
target prot opt source destination

Chain ufw-before-output (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ufw-user-output all -- anywhere anywhere

Chain ufw-logging-allow (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] "

Chain ufw-logging-deny (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere ctstate INVALID limit: avg 3/min burst 10
LOG all -- anywhere anywhere limit: avg 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Chain ufw-not-local (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
RETURN all -- anywhere anywhere ADDRTYPE match dst-type MULTICAST
RETURN all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST
ufw-logging-deny all -- anywhere anywhere limit: avg 3/min burst 10
DROP all -- anywhere anywhere

Chain ufw-reject-forward (1 references)
target prot opt source destination

Chain ufw-reject-input (1 references)
target prot opt source destination

Chain ufw-reject-output (1 references)
target prot opt source destination

Chain ufw-skip-to-policy-forward (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain ufw-skip-to-policy-input (7 references)
target prot opt source destination
DROP all -- anywhere anywhere

Chain ufw-skip-to-policy-output (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain ufw-track-forward (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere ctstate NEW
ACCEPT udp -- anywhere anywhere ctstate NEW

Chain ufw-track-input (1 references)
target prot opt source destination

Chain ufw-track-output (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere ctstate NEW
ACCEPT udp -- anywhere anywhere ctstate NEW

Chain ufw-user-forward (1 references)
target prot opt source destination

Chain ufw-user-input (1 references)
target prot opt source destination
DROP all -- 91.200.12.88 anywhere
DROP all -- 91.200.12.50 anywhere
DROP all -- 159.203.79.104 anywhere
DROP all -- 192.187.100.58 anywhere
DROP all -- 91.200.12.49 anywhere
DROP all -- 107.150.49.58 anywhere
DROP all -- 91.200.12.1 anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT udp -- anywhere anywhere udp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT udp -- anywhere anywhere udp dpt:http
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:mysql
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT udp -- anywhere anywhere udp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:openvpn
ACCEPT udp -- anywhere anywhere udp dpt:openvpn
ACCEPT udp -- anywhere anywhere udp dpt:openvpn
ACCEPT tcp -- anywhere anywhere tcp dpt:9090
ACCEPT udp -- anywhere anywhere udp dpt:9090

Chain ufw-user-limit (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning prefix "[UFW LIMIT BLOCK] "
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

Chain ufw-user-limit-accept (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain ufw-user-logging-forward (0 references)
target prot opt source destination

Chain ufw-user-logging-input (0 references)
target prot opt source destination

Chain ufw-user-logging-output (0 references)
target prot opt source destination

Chain ufw-user-output (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:mysql
``` ```

```text ```text
dig +short popallo.com SOA
dns12.ovh.net. tech.ovh.net. 2018121002 86400 3600 3600000 86400 [86400]
```
cette fois, je résous, avec cloudflare (viré les résolveurs free)

mais, aussi bien wanadoo que free
```
traceroute popallo.com
traceroute to popallo.com (37.187.96.105), 30 hops max, 60 byte packets
...
8 be102.gra-g1-nc5.fr.eu (91.121.215.176) 12.813 ms 13.017 ms 13.267 ms
9 * * *
...
30 * * *
```

donc explication:
dès que je rentre chez OVH, plus aucun routeur ne m'indique le chemin
montre ça au support! ```

Je viens de changer les DNS en remettant la zone par défaut d'ovh. Du coup je ne passe plus par bind côté serveur. Cela ne change absolument rien au problème.
Voici deux traceroute, un qui fonctionne depuis une connexion SFR PRO :
https://snag.gy/RzN3XS.jpg

Et un depuis la connexion sfr de chez moi :
https://snag.gy/LaABif.jpg

```text ça change:

**WANADOO**
```text
7 be100-169.th2-1-a9.fr.eu (91.121.131.193) 32.818 ms 30.184 ms 31.118 ms
8 be102.gra-g2-nc5.fr.eu (213.186.32.214) 36.181 ms 30.119 ms 28.726 ms
...
30 * * *
```

**FREE**
```text
8 be102.gra-g1-nc5.fr.eu (91.121.215.176) 12.807 ms 13.216 ms 13.427 ms
9 * * *
10 * * vl5.gra-3b-6k.fr.eu (178.33.103.228) 16.621 ms
...
``` ```

```text je vois que rien ne bouge :(

**wanadoo**:
```text
traceroute to popallo.com (37.187.96.105), 30 hops max, 60 byte packets
7 be100-169.th2-1-a9.fr.eu (91.121.131.193) 31.843 ms 26.282 ms 27.128 ms
8 be102.gra-g2-nc5.fr.eu (213.186.32.214) 32.070 ms 29.655 ms 30.520 ms
9 * * *
...
29 * * *
30 * * *
```

free:
```text
traceroute to popallo.com (37.187.96.105), 30 hops max, 60 byte packets
8 be102.gra-g1-nc5.fr.eu (91.121.215.176) 12.998 ms 13.504 ms 13.703 ms
9 * * *
10 vl5.gra-3b-6k.fr.eu (178.33.103.228) 13.105 ms vl5.gra-3a-6k.fr.eu (178.33.103.224) 13.438 ms *
...
29 * * *
30 * * *
``` ```

Non en effet ça ne bouge pas. Le support d'ovh m'a demandé de lui transmettre des tracert, ce que j'ai fais, dont certains qui aboutissent à mon serveur (notamment depuis un vpn en allemagne) mais pour l'instant je reste sans solution.
Je suis patient donc je vais encore attendre quelques jours mais si rien ne bouge à début janvier je vais migrer chez un autre prestataire, tant pis.

Bon eh bien boulet que je suis c 'était bien une (voire plusieurs) règles iptables qui bloquaient l'accès à mon serveur.
En cause deux choses :
1. mon inexpérience d'iptables
2. le logiciel peerguardian

En effet, j'avais installé peerguardian il y a 5 ans en arrière, car fournissant à quelques amis un service vpn, je voulais me prémunir un tout petit peu des problèmes liés au téléchargement illégal via torrent (même si ça ne suffisait bien évidemment pas ...).

Après désinstallation de peerguardian je ping de nouveau correctement mon serveur depuis les différentes connexions sur lesquelles ça ne fonctionnait plus.

Merci à tous pour votre écoute, à votre aide et notamment @kyodev qui m'aura accompagné tout du long :D

ce ne m'explique pas les traceroutes incomplets que j'ai toujours, à partir de free ou wanadoo

bien que cette fois, nmap détecte le port 443 ouvert

De mon côté, sur ma connexion SFR perso, le traceroute aboutit bien cette fois-ci.