J'ai un serveur DNS qui résout toutes les requêtes pour un groupe interne de serveurs. Il s'agit d'un bind sur CentOS 5.5 (identique à RHEL5) et je l'ai configuré pour autoriser la récursion et la direction de résolution sans aucun forwarder.
Le problème auquel je suis confronté est qu'il faut un temps anormalement long pour résoudre un nom pour la première fois. (de l'ordre de 20 secondes). Cela conduit les clients à donner un timeout.
Lorsque je le configure pour qu'il transfère tout vers le DNS public de Google, c'est-à-dire 8.8.8.8+8.8.4.4, cela fonctionne très bien (en une seconde).
J'ai essayé de surveiller le trafic sur le net pour voir pourquoi il fait ça :
[root@ns1 ~]# tcpdump -nnvvvA -s0 udp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:06:36.137797 IP (tos 0x0, ttl 64, id 35903, offset 0, flags [none], proto: UDP (17), length: 60) 172.17.1.10.36942 > 172.17.1.4.53: [udp sum ok] 19773+ A? www.paypal.com. (32)
E..<.?..@..A...
.....N.5.(6.M=...........www.paypal.com.....
23:06:36.140594 IP (tos 0x0, ttl 64, id 56477, offset 0, flags [none], proto: UDP (17), length: 71) 172.17.1.4.6128 > 192.35.51.30.53: [udp sum ok] 10105 [1au] A? www.paypal.com. ar: . OPT UDPsize=4096 (43)
E..G....@........#3....5.3fR'y...........www.paypal.com.......)........
23:06:38.149756 IP (tos 0x0, ttl 64, id 13078, offset 0, flags [none], proto: UDP (17), length: 71) 172.17.1.4.52425 > 192.54.112.30.53: [udp sum ok] 54892 [1au] A? www.paypal.com. ar: . OPT UDPsize=4096 (43)
E..G3...@.j&.....6p....5.3.q.l...........www.paypal.com.......)........
23:06:40.159725 IP (tos 0x0, ttl 64, id 43016, offset 0, flags [none], proto: UDP (17), length: 71) 172.17.1.4.24059 > 192.42.93.30.53: [udp sum ok] 11205 [1au] A? www.paypal.com. ar: . OPT UDPsize=4096 (43)
E..G....@..@.....*].]..5.3..+............www.paypal.com.......)........
23:06:41.141403 IP (tos 0x0, ttl 64, id 35904, offset 0, flags [none], proto: UDP (17), length: 60) 172.17.1.10.36942 > 172.17.1.4.53: [udp sum ok] 19773+ A? www.paypal.com. (32)
E..<.@..@..@...
.....N.5.(6.M=...........www.paypal.com.....
23:06:42.169652 IP (tos 0x0, ttl 64, id 44001, offset 0, flags [none], proto: UDP (17), length: 60) 172.17.1.4.9141 > 192.55.83.30.53: [udp sum ok] 1184 A? www.paypal.com. (32)
E..<....@..e.....7S.#..5.(...............www.paypal.com.....
23:06:42.207295 IP (tos 0x0, ttl 54, id 38004, offset 0, flags [none], proto: UDP (17), length: 205) 192.55.83.30.53 > 172.17.1.4.9141: [udp sum ok] 1184- q: A? www.paypal.com. 0/3/3 ns: paypal.com. NS ns1.isc-sns.net., paypal.com. NS ns2.isc-sns.com., paypal.com. NS ns3.isc-sns.info. ar: ns1.isc-sns.net. AAAA 2001:470:1a::1, ns1.isc-sns.net. A 72.52.71.1, ns2.isc-sns.com. A 38.103.2.1 (177)
E....t..6./A.7S......5#..................www.paypal.com..................ns1.isc-sns.net..............ns2.isc-sns...............ns3.isc-sns.info..,.......... ..p.............,..........H4G..I..........&g..
(this goes on for a few more seconds)Si vous regardez attentivement, vous verrez que les 3-4 premiers serveurs racine n'ont pas répondu du tout. Cela a fait perdre 7-8 secondes, jusqu'à ce que l'un d'entre eux réponde.
Pensez-vous que j'ai fait quelque chose de mal ici ? Il est intéressant de noter que lorsque je creuse directement à partir des serveurs racine qui n'ont pas répondu, ils répondent toujours très rapidement (ce qui montre que le pare-feu/nat n'est pas le problème ici). Par exemple
dig www.paypal.com @192.35.51.30fonctionne parfaitement, régulièrement, et très rapidement. Que pensez-vous de ce mystère ?
