Résolution de nom capricieuse

Bonjour,

J’ai dû louper quelque chose lorsque j’ai configurer Bind… :think:

Je m’en sert comme cache DNS dans le réseau local, serveur primaire pour mon nom de domaine et pour la résolution inverse de ma connexion (IPv6).

Les machines de mon réseau local obtiennent l’adresse du serveur de nom par l’intermédiaire du serveur DHCP. C’est visible dans le /etc/resolv.conf : 192.168.1.200 (l’adresse du routeur où est installé le serveur DNS qui fait aussi NAT, firewall, etc.)

Lorsque je navigue sur Internet, parfois, la résolution de nom ne se fait pas :013 et c’est la page de mon site (hébergé sur une autre machine du réseau local) qui s’affiche. Par exemple, si je navigue sur Debian-fr et que je veux afficher la page mondomaineamoi.fr/support-debian.html qui est demandée. Mais comme sur mon site, il n’y a pas de page support-debian.html, ça fait une erreur 404. Parfois, en faisant plusieurs actualisation de la page dans le navigateur (CTRL-F5), je fini par obtenir gain de cause. :017 Parfois, non !

Je fais donc une requête manuelle :

dig www.debian-fr.org A

et… pas de réponse.

Du coup, je me connecte sur le routeur et le lance la même requête manuelle (dig) et j’obtiens une réponse.

Je retourne sur ma machine de travail et là, oh miracle :041 , la résolution se fait correctement. La commande dig retourne quelque chose et le navigateur fini par afficher le bon site.

Et ce qui m’intrigue encore plus c’est qu’aucun message ne figure dans le syslog du routeur :question:

Des pistes pour trouver où ça cloche ?

Merci.

Là je n’ai pas d’idée mais tu peux activer et désactiver le log de toutes les requêtes DNS avec

rndc querylog.
Si tu as une connectivité IPv6, n’oublie pas que debian-fr.org est aussi disponible en IPv6, des requêtes de type AAAA entrant alors en jeu.

Question : ton serveur DNS, il fait comment pour résoudre les noms extérieurs ? Il passe par des forwarders (si oui lesquels) ou il fait la récursion complète ?

Par contre je ne vois pas comment le nom de domaine du site demandé peut changer comme tu le décris, à moins d’une diablerie du navigateur ou d’un proxy ou redirecteur web qui réécrirait l’adresse. En tout cas le DNS seul ne peut en aucun cas réécrire le nom de site.

Ça pourrait peut être arriver avec 2 serveurs de noms déclarés dans /etc/resolv.conf, l’un correct, l’autre erroné. En fonction de qui répond le premier (dépend du cache peut être), la réponse donnée diffère…

Hello,

[strike]J’ai l’impression d’avoir[/strike] Je n’ai pas résolu le problème en décommentant la ligne suivante dans le /etc/bind/named.conf.local :

include "/etc/bind/zones.rfc1918";

[strike]À confirmer…[/strike]

Par contre, on dirait que ça a un rapport avec la charge du réseau… Bizarre…

Ce fichier définit les plages réservés aux réseaux locaux.
Donne laconfiguration de ton DNS

La voici :

[*] /etc/bind/named.conf.local

   zone "domaine.net" {
      type master;
      file "domaine.net.zone";
      allow-transfer { 2001:910:800::12; 2001:910:800::40; 80.67.169.12; 80.67.169.40; }; // ns0 et ns1 FDN
      notify yes;
   };

   // IPv6 connexion FDN : 2001:910:xxxx::/64
   // Enregistrements inverses de la connexion
   zone "x.x.x.x.0.1.9.0.1.0.0.2.ip6.arpa" {
      type master;
      file "db.2001.910.xxxx.ip6.arpa";
      allow-transfer { 2001:910:800::12; 2001:910:800::40; 80.67.169.12; 80.67.169.40; }; // ns0 et ns1 FDN
      notify yes;
   };

Ce fichier n’est qu’une partie de la configuration, qui ne concerne que les zones locales alors que le problème semble plutôt affecter la résolution récursive si j’ai bien compris. Il manque notamment named.conf, named.conf.options.

Peux-tu préciser un peu plus ?

Les voici :

[ul][li]named.conf[/li][/ul]

include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones";
[ul][li]named.conf.options[/li][/ul]

[code]options {
directory “/var/cache/bind”;
dnssec-validation auto;

    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };

};
[/code]

Ça arrive quand je télécharge des images ISO par exemple. Les téléchargements continuent mais la navigation est impossible (pas de résolution de noms).

Merci.

C’est minimaliste.
Pas d’ACL donc par défaut si le serveur reçoit des requêtes DNS de l’extérieur, il accepte les requêtes récursives de n’importe qui, ce qui n’est généralement pas souhaitable (risque d’abus, DoS, cache poisoning…)

Si le problème ne se produit que lors d’un téléchargement (à débit maximum je suppose), on peut penser à une saturation de la voie descendante qui provoque la perte des paquets de réponse (et avec UDP il n’y a pas de retransmission en cas de perte). Mais ce serait quand même étonnant.

Les requêtes DNS depuis le routeur réussissent-elles toujours ? Quel DNS interroge-t-il, voir dans /etc/resolv.conf : son propre serveur local ou ceux du FAI ?

[quote=“PascalHambourg”]C’est minimaliste.
Pas d’ACL donc par défaut si le serveur reçoit des requêtes DNS de l’extérieur, il accepte les requêtes récursives de n’importe qui(…)[/quote]
Je comprends mais je n’ai pas trop le choix vu que c’est aussi le serveur primaire de mon domaine…

[quote]
Si le problème ne se produit que lors d’un téléchargement (à débit maximum je suppose), on peut penser à une saturation de la voie descendante (…) Mais ce serait quand même étonnant.[/quote]
Oui c’est étonnant car c’est pas une bête de course le routeur/passerelle mais c’est quand-même un Atom 2 cœurs et 2 Go de RAM… Et un réseau Gigabit. Pour un téléchargement à grosso-modo 500 Ko/s (ADSL oblige)… Pas de quoi tout mettre par terre :017

[quote]
Les requêtes DNS depuis le routeur réussissent-elles toujours ?[/quote]
Oui toujours. Même pendant la période « DNS black-out ». Si je fait la requête DNS (via dig) à partir du routeur, ça marche…

Le routeur interroge celui du FAI :

[ul][li]/etc/resolv.conf[/li][/ul]

nameserver 80.67.169.12 nameserver 80.67.169.40 domain lan search lan

Mais je m’étais dit qu’à l’occasion, j’aurais pu le configurer pour s’interroger lui-même (j’ai pas encore chercher comment).

Bien sûr que si, tu as le choix. Tu peux limiter les adresses sources des requêtes récursives (options allow-query-cache, allow-recursion).

De toute façon la fonction routeur occupe normalement très peu de CPU pour un débit aussi faible.[quote=“microniko”]Le routeur interroge celui du FAI[/quote]
Intéressant. Et si tu interroges

  • ton propre DNS depuis le routeur
  • un DNS du FAI depuis le poste du LAN ?
    Tu peux spécifier l’adresse du serveur à interroger avec dig :

Tu peux aussi tenter de définir les DNS du FAI comme forwarders dans les options de BIND pour voir si ça fait une différence.

Hello,

Merci pour l’info. J’avais complètement zappé cette histoire de protection de mon serveur DNS… J’ai ajouté les options qui vont bien :023

[quote=“PascalHambourg”]Et si tu interroges

  • ton propre DNS depuis le routeur
  • un DNS du FAI depuis le poste du LAN ?
    [/quote]
    J’ai donc lancé trois téléchargements d’ISO.
    Voici le résultat des tests :
    192.168.1.200 est l’adresse du routeur.
    Test depuis une machine du réseau :

[code]nicolas@radon:~$ dig free.fr @192.168.1.200
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> free.fr @192.168.1.200

;; QUESTION SECTION:
;free.fr. IN A[/code]

En interrogeant directement le DNS de mon FAI :

[code]nicolas@radon:~$ dig free.fr @80.67.169.12
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> free.fr @80.67.169.12

;; QUESTION SECTION:
;free.fr. IN A

;; ANSWER SECTION:
free.fr. 76375 IN A 212.27.48.10[/code]
Et directement depuis le routeur :

[code]nicolas@antimoine:~$ dig free.fr
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> free.fr

;; QUESTION SECTION:
;free.fr. IN A

;; ANSWER SECTION:
free.fr. 76401 IN A 212.27.48.10[/code]

Et en ajoutant forwarders { 80.67.169.12; }; , le comportement est le même…

Et la suite ? Time-out sans réponse ?

Avec le DNS du FAI, puisque c’est ce qui figure dans resolv.conf. Et avec ton propre DNS ?

Configuration de BIND rechargée pour prendre en compte la modification ?

Je viens de refaire les tests. C’est vraiment incroyable. Lorsque j’arrête les téléchargements en court, tout rentre immédiatement dans l’ordre :think: … D’ailleurs, j’ai pas précisé mais le problème affecte toutes les machines du réseau (sauf le routeur quand je teste en direct du coup).

Du coup, j’essaie de plus détailler que ce matin.

Rappels : [mono]radon[/mono] est une machine du réseau, [mono]antimoine[/mono] : le routeur.

Avec ou sans forwarders { 80.67.169.12; };, le comportement est le même (et j’ai bien relancé bind pour qu’il prenne le changement en compte ). Il y a juste la réponse dans ;; AUTHORITY SECTION: qui diffère un peu…

nicolas@radon:~$ dig debian-fr.org A

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> debian-fr.org A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47688
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;debian-fr.org.                 IN      A

;; Query time: 563 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Tue Feb  4 20:31:19 2014
;; MSG SIZE  rcvd: 31

En précisant l’adresse du routeur (ça ne doit rien changer, il est automatiquement dans resolv.conf) :

[code]nicolas@radon:~$ dig debian-fr.org A @192.168.1.200

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> debian-fr.org A @192.168.1.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38014
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;debian-fr.org. IN A

;; Query time: 0 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Tue Feb 4 20:31:50 2014
;; MSG SIZE rcvd: 31[/code]

Curieusement, au bout de la quatrième fois :question: :

[code]nicolas@radon:~$ dig debian-fr.org A @192.168.1.200

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> debian-fr.org A @192.168.1.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10370
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;debian-fr.org. IN A

;; ANSWER SECTION:
debian-fr.org. 38400 IN A 91.121.50.62

;; AUTHORITY SECTION:
(…)

;; Query time: 4261 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Tue Feb 4 20:32:51 2014
;; MSG SIZE rcvd: 165[/code]

Sur le routeur :

[code]nicolas@antimoine:~$ dig debian-fr.org A @localhost

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> debian-fr.org A @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50063
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;debian-fr.org. IN A

;; Query time: 3001 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 4 20:36:42 2014
;; MSG SIZE rcvd: 31
[/code]
Réponse au bout de la 3ème fois.

[code]nicolas@antimoine:~$ dig debian-fr.org A @localhost

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> debian-fr.org A @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61866
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;debian-fr.org. IN A

;; ANSWER SECTION:
debian-fr.org. 38250 IN A 91.121.50.62

;; AUTHORITY SECTION:
(…)

;; Query time: 4059 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Feb 4 20:37:03 2014
;; MSG SIZE rcvd: 258
[/code]

Puis, sur radon, ça répond !

Ça vous laisse sans voix :108

Bon, ça signifie que le DNS utilisé ta box met du temps à répondre: cela explique les délais. Essaye en utilisant des DNS extérieurs alternatifs et que ceux là. (Je n’ai pas tout lu le fil donc je tape peut être à coté)

François, je crois en effet que tu n’as pas bien lu. Il n’est question nulle part du DNS de la box. microniko a son propre serveur récursif BIND sur la machine servant de passerelle, et c’est lui qui a des lenteurs lors d’un téléchargement, alors que dans le même temps l’interrogation d’un serveur DNS extérieur fonctionne.

En effet, merci Pascal.
Et maintenant voilà que j’arrive pû à m’connecté à certaines machines via SSH… Ça devient n’importe nawak !
:017

Ce n’est peut-être qu’une coïncidence…

Au temps pour moi. Est ce que le phénomène a lieu lors du communication avec un cable? On dirait que la communication marche mal ou que le réseau est saturé avec une perte de paquets, je pense à la connexion au serveur et non à la connexion vers l’extérieur. As tu essayé de regarder avec tcpdump le trafic échangé sur le port 53 entre le serveur et la machine demandeuse pour voir une eventuelle perte?

Deux éléments me semblent infirmer cette hypothèse.

  • Un poste du LAN peut interroger un serveur DNS extérieur sans problème.
  • Le problème se produit aussi si la passerelle interroge son propre BIND local.