Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Bind vérifier serveur DNS interrogé

6 réponses
Avatar
Droopy191
Salut,

J'ai mis en place un serveur DNS pour mon réseau local.
Le DNS et le reverse marche correctement en local.

Pour les requetes en dehors de mon reseau, le DNS est sensé passer par
les DNS de mon FAI ( option forwarders ).

Comment vérifier que ce dernier point est correctement paramétré ?
exemple d'une réponse sur google.fr
J'ai l'impression qu'il interroge les serveurs racines ?

dig www.google.fr

; <<>> DiG 9.6.1-P1 <<>> www.google.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38170
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 13, ADDITIONAL: 7

;; QUESTION SECTION:
;www.google.fr. IN A

;; ANSWER SECTION:
www.google.fr. 344865 IN CNAME www.google.com.
www.google.com. 604047 IN CNAME www.l.google.com.
www.l.google.com. 52 IN A 209.85.225.147
www.l.google.com. 52 IN A 209.85.225.99
www.l.google.com. 52 IN A 209.85.225.103
www.l.google.com. 52 IN A 209.85.225.104
www.l.google.com. 52 IN A 209.85.225.105
www.l.google.com. 52 IN A 209.85.225.106

;; AUTHORITY SECTION:
. 104224 IN NS L.ROOT-SERVERS.NET.
. 104224 IN NS E.ROOT-SERVERS.NET.
. 104224 IN NS C.ROOT-SERVERS.NET.
. 104224 IN NS M.ROOT-SERVERS.NET.
. 104224 IN NS D.ROOT-SERVERS.NET.
. 104224 IN NS B.ROOT-SERVERS.NET.
. 104224 IN NS F.ROOT-SERVERS.NET.
. 104224 IN NS G.ROOT-SERVERS.NET.
. 104224 IN NS K.ROOT-SERVERS.NET.
. 104224 IN NS I.ROOT-SERVERS.NET.
. 104224 IN NS J.ROOT-SERVERS.NET.
. 104224 IN NS H.ROOT-SERVERS.NET.
. 104224 IN NS A.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 352622 IN A 198.41.0.4
A.ROOT-SERVERS.NET. 190913 IN AAAA 2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 190637 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 190632 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 190630 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 190637 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 190642 IN A 192.5.5.241

;; Query time: 40 msec
;; SERVER: 192.168.10.150#53(192.168.10.150)
;; WHEN: Sun Oct 25 11:18:38 2009
;; MSG SIZE rcvd: 510


Merci pour votre aide.


--
DR

6 réponses

Avatar
Patrick Mevzek
Le Sun, 25 Oct 2009 11:44:08 -0400, Droopy191 a écrit:
Comment vérifier que ce dernier point est correctement paramétré ?
exemple d'une réponse sur google.fr
J'ai l'impression qu'il interroge les serveurs racines ?

dig www.google.fr



Faites plutôt
dig +trace www.google.fr

ainsi vous verrez la chaîne de délégation empruntée, c'est à dire chaque
serveur DNS consulté au fur et à mesure et sa réponse propre.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>
Avatar
Droopy191
Le 25/10/2009 12:05, Patrick Mevzek a écrit :
Faites plutôt
dig +trace www.google.fr




Si je lis bien la suite, ca part bien directement sur les serveurs
racines, puis fr, et enfin google


dig +trace www.google.fr

; <<>> DiG 9.5.1-P3 <<>> +trace www.google.fr
;; global options: printcmd
. 3600000 IN NS L.ROOT-SERVERS.NET.
. 3600000 IN NS C.ROOT-SERVERS.NET.
. 3600000 IN NS G.ROOT-SERVERS.NET.
. 3600000 IN NS H.ROOT-SERVERS.NET.
. 3600000 IN NS I.ROOT-SERVERS.NET.
. 3600000 IN NS D.ROOT-SERVERS.NET.
. 3600000 IN NS F.ROOT-SERVERS.NET.
. 3600000 IN NS A.ROOT-SERVERS.NET.
. 3600000 IN NS B.ROOT-SERVERS.NET.
. 3600000 IN NS K.ROOT-SERVERS.NET.
. 3600000 IN NS M.ROOT-SERVERS.NET.
. 3600000 IN NS E.ROOT-SERVERS.NET.
. 3600000 IN NS J.ROOT-SERVERS.NET.
;; Received 228 bytes from 192.168.10.150#53(192.168.10.150) in 4 ms

fr. 172800 IN NS E.NIC.fr.
fr. 172800 IN NS B.EXT.NIC.fr.
fr. 172800 IN NS E.EXT.NIC.fr.
fr. 172800 IN NS C.NIC.fr.
fr. 172800 IN NS A.NIC.fr.
fr. 172800 IN NS G.EXT.NIC.fr.
fr. 172800 IN NS D.EXT.NIC.fr.
fr. 172800 IN NS F.EXT.NIC.fr.
;; Received 407 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 91 ms

google.fr. 172800 IN NS ns1.google.com.
google.fr. 172800 IN NS ns4.google.com.
google.fr. 172800 IN NS ns2.google.com.
google.fr. 172800 IN NS ns3.google.com.
;; Received 113 bytes from 194.146.106.46#53(F.EXT.NIC.fr) in 141 ms

www.google.fr. 345600 IN CNAME www.google.com.
www.google.com. 604800 IN CNAME www.l.google.com.
l.google.com. 86400 IN NS b.l.google.com.
l.google.com. 86400 IN NS a.l.google.com.
l.google.com. 86400 IN NS g.l.google.com.
l.google.com. 86400 IN NS f.l.google.com.
l.google.com. 86400 IN NS d.l.google.com.
l.google.com. 86400 IN NS e.l.google.com.
;; Received 271 bytes from 216.239.38.10#53(ns4.google.com) in 44 ms


Bind tourne sur une debian lenny.
J'ai indiqué les dns de mon fai dans named.conf.options de la facon
suivante. Ou est l'erreur ?

options {
directory "/var/cache/bind";
forwarders {
68.87.77.134;
68.87.72.134;
};

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


--
DR
Avatar
Pascal Hambourg
Salut,

Droopy191 a écrit :

Pour les requetes en dehors de mon reseau, le DNS est sensé passer par
les DNS de mon FAI ( option forwarders ).

Comment vérifier que ce dernier point est correctement paramétré ?
exemple d'une réponse sur google.fr
J'ai l'impression qu'il interroge les serveurs racines ?

dig www.google.fr

; <<>> DiG 9.6.1-P1 <<>> www.google.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38170
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 13, ADDITIONAL: 7

;; QUESTION SECTION:
;www.google.fr. IN A

;; ANSWER SECTION:
www.google.fr. 344865 IN CNAME www.google.com.
www.google.com. 604047 IN CNAME www.l.google.com.
www.l.google.com. 52 IN A 209.85.225.147


[...]
;; AUTHORITY SECTION:
. 104224 IN NS L.ROOT-SERVERS.NET.


[...]
;; Query time: 40 msec



Je ne vois rien là-dedans qui indique formellement si BIND a fait une
résolution récursive à partir des serveurs racines ou a transmis la
requête à un forwarder. Le seule indice est le temps de réponse de 40 à
comparer avec la latence de la connexion internet sachant qu'une
résolution récursive complète demande plusieurs requêtes (cf. le
résultat de dig +trace). Cependant si des résultats intermédiaires sont
déjà dans le cache de BIND, le nombre de requêtes nécessaires est moindre.

Par contre c'est curieux que la réponse contienne les serveurs racine
comme autorité. Mon BIND à moi m'indique les NS de l.google.com, ce qui
est quand même plus logique.

Un moyen simple est de faire une capture du trafic DNS (port 53 UDP et
TCP) pour voir l'adresse destination des requêtes sortantes. Il y a
peut-être un autre moyen via les options de log ou de debug de BIND,
mais je ne connais pas assez.

PS : dig +trace n'interroge pas le serveur DNS local mais fait la
résolution récursive lui-même, je ne vois pas ce que ça apporte.
Avatar
Stephane Bortzmeyer
Patrick Mevzek wrote:

Faites plutôt
dig +trace www.google.fr

ainsi vous verrez la chaîne de délégation empruntée,



Mais ce n'est pas la même qu'une résolution « normale » puisque cela ne
passera pas par le BIND local, et donc pas par les « forwarders »
configurés dans celui-ci.

Donc, cela n'aide pas à déboguer des problèmes comme celui posé.
Avatar
Stephane Bortzmeyer
Droopy191 wrote:

Comment vérifier que ce dernier point est correctement paramétré ?
exemple d'une réponse sur google.fr
J'ai l'impression qu'il interroge les serveurs racines ?



Oui, en effet, la réponse (ANSWER SECTION) est correcte mais l'autorité
(AUTHORITY SECTION) ne l'est pas (cela devrait être google.com et pas la
racine).

Je dirais que les résolveurs de votre FAI font des choses bizarres.
Essayez sans l'option forwarders, pour voir.
Avatar
Patrick Mevzek
Le Sat, 31 Oct 2009 22:54:06 +0100, Stephane Bortzmeyer a écrit:
Je dirais que les résolveurs de votre FAI font des choses bizarres.
Essayez sans l'option forwarders, pour voir.



Ce qui ne permettra pas de savoir si elle est correctement paramétrée
initialement :-)
En regardant les sources, je n'ai pas l'impression que même avec les logs
au maximum on puisse voir concrétement s'il utilise au final réellement
les forwarders. Sinon, évidemment, comme l'a dit Pascal, il reste
l'analyse du trafic réseau.

Ou, "par l'absurde", mettre une addresse IP dans le forwarders sur
laquelle on sait qu'il n'y a pas de serveur DNS qui tourne et vérifier
alors que le serveur DNS local ne répond pas à une requête qui fonctionne
en direct.

Ou, ce qui revient en gros au même d'utiliser l'adresse IP d'un autre
serveur qu'on contrôle et regarder dans les logs de ce dernier s'il
recoit les requêtes DNS du premier en forward.

Ou mettre en place dans le firewall une règle qui interdise tout le
trafic DNS, sauf celui depuis/vers le forwarder.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>