[debian] Bind9 geeft random geen antwoord

[hostname]

Hallo,

Ik heb een debian lenny server met daarop bind9 geinstalleerd staan. Dit is een authorative server voor mijn lokale (.local) sites. Dit werkt allemaal goed.
Echter, nu wil ik dat hij ook caching nameserver gaat spelen. In /etc/bind/named.conf.options de forwarders { } ingevuld (OpenDNS) en bind gerestart.
Het resultaat is dat bind voor z'n eigen domeinen wel goed gaat, maar voor sites op het internet behoorlijk random reageert. Soms doet hij het op alle sites, soms op sommige (tweakers.net gaat wel goed, tweakimg.net niet), soms doet hij het helemaal niet. Als hij het niet doet geeft nslookup een timeout met als melding 'no servers found'.

Wat doe ik fout?

[Seth4Chaos]

post je config eens en wat zegt de logfile (als een query niet lukt)

[hostname]

/etc/bind/named.conf.options:

code:

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

      forwarders {
              208.67.222.222;
              208.67.220.220;
      };

        auth-nxdomain no;    # conform to RFC1035
};

/etc/bind/named.conf:

code:

zone "local" {
   type master;
   file "/etc/bind/local.db";
};

zone "10.in-addr.arpa" {
   type master;
   file "/etc/bind/local.reverse.db";
};

Verdere config files heb ik niet gewijzigd. Log geeft, voor zowel normale als gefaalde queryies:

code:

31-Jan-2010 20:31:01.615 queries: client 10.1.1.50#45855: query: en.wikipedia.org IN A +        
31-Jan-2010 20:31:01.616 queries: client 10.1.1.50#45855: query: en.wikipedia.org IN AAAA +     
31-Jan-2010 20:31:02.181 queries: client 127.0.0.1#46610: query: en.wikipedia.org IN A +                                                                                     
31-Jan-2010 20:31:15.487 queries: client 127.0.0.1#54393: query: tweakers.net IN A +                                                                                                          
31-Jan-2010 20:31:18.302 queries: client 127.0.0.1#56999: query: tweakimg.net IN A +                                                                                                          
31-Jan-2010 20:31:22.398 queries: client 127.0.0.1#59186: query: tweakimg.net IN A +                                                                                                          
31-Jan-2010 20:31:27.293 queries: client 127.0.0.1#34843: query: tweakers.net IN A +
[snip]
31-Jan-2010 20:35:31.418 queries: client 127.0.0.1#54126: query: pop3.live.com.lan IN AAAA +
31-Jan-2010 20:35:31.418 queries: client 127.0.0.1#54864: query: pop3.live.com IN A +
31-Jan-2010 20:35:33.841 queries: client 127.0.0.1#49158: query: 2.debian.pool.ntp.org IN A +
31-Jan-2010 20:35:36.421 queries: client 127.0.0.1#54864: query: pop3.live.com IN A +
31-Jan-2010 20:35:38.846 queries: client 127.0.0.1#59755: query: 2.debian.pool.ntp.org.lan IN A +
31-Jan-2010 20:35:38.847 queries: client 127.0.0.1#37054: query: 3.debian.pool.ntp.org IN AAAA +
31-Jan-2010 20:35:38.847 queries: client 127.0.0.1#50323: query: 3.debian.pool.ntp.org.lan IN AAAA +
31-Jan-2010 20:35:38.847 queries: client 127.0.0.1#53206: query: 3.debian.pool.ntp.org IN A +

-4 meegeven bij het starten van bind maakt geen verschil.

[Seth4Chaos]

ik ga ervan uit dat in je /etc/resolv.conf alleen "127.0.0.1" staat, zodat je niet andere servers queried.

verder kan je eens kijken met dig (is iets nieuwer/beter dan nslookup) wat die zegt bij die queries en als het fout gaat kan je ook eens kijken wat OpenDNS op dat moment terug geeft (kijken of het niet daar ligt)

code:

$ dig 2.debian.pool.ntp.org

; <<>> DiG 9.4.3-P3 <<>> 2.debian.pool.ntp.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50847
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 9, ADDITIONAL: 10

;; QUESTION SECTION:
;2.debian.pool.ntp.org.     IN  A

;; ANSWER SECTION:
2.debian.pool.ntp.org.  270 IN  A   88.159.82.127
2.debian.pool.ntp.org.  270 IN  A   85.17.231.211
2.debian.pool.ntp.org.  270 IN  A   83.137.16.7

;; AUTHORITY SECTION:
pool.ntp.org.       356 IN  NS  g.ntpns.org.
pool.ntp.org.       356 IN  NS  f.ntpns.org.
pool.ntp.org.       356 IN  NS  a.ntpns.org.
pool.ntp.org.       356 IN  NS  e.ntpns.org.
pool.ntp.org.       356 IN  NS  h.ntpns.org.
pool.ntp.org.       356 IN  NS  c.ntpns.org.
pool.ntp.org.       356 IN  NS  i.ntpns.org.
pool.ntp.org.       356 IN  NS  d.ntpns.org.
pool.ntp.org.       356 IN  NS  b.ntpns.org.

;; ADDITIONAL SECTION:
f.ntpns.org.        1729    IN  A   207.171.7.84
f.ntpns.org.        1729    IN  A   118.67.212.230
e.ntpns.org.        42577   IN  A   70.85.157.108
g.ntpns.org.        41835   IN  A   80.96.148.8
d.ntpns.org.        34318   IN  A   94.23.191.112
a.ntpns.org.        36010   IN  A   78.153.203.28
h.ntpns.org.        43006   IN  A   212.12.50.229
h.ntpns.org.        43006   IN  A   85.214.25.217
b.ntpns.org.        43020   IN  A   194.106.223.156
i.ntpns.org.        41606   IN  A   141.89.226.53

;; Query time: 43 msec
;; SERVER: 192.168.6.254#53(192.168.6.254)
;; WHEN: Tue Feb  2 10:04:36 2010
;; MSG SIZE  rcvd: 397

$ dig @208.67.222.222 2.debian.pool.ntp.org

; <<>> DiG 9.4.3-P3 <<>> @208.67.222.222 2.debian.pool.ntp.org
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56478
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;2.debian.pool.ntp.org.     IN  A

;; ANSWER SECTION:
2.debian.pool.ntp.org.  44  IN  A   67.222.149.178
2.debian.pool.ntp.org.  44  IN  A   207.171.7.152
2.debian.pool.ntp.org.  44  IN  A   64.73.32.134

;; Query time: 13 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Tue Feb  2 10:04:38 2010
;; MSG SIZE  rcvd: 87

[hostname]

/etc/resolv.conf bevat inderdaad alleen maar 127.0.0.1. Dig gaf ook iets als connection timeout, meen ik me te herinneren. Aangezien hij het nu doet kan ik even niet testen
Dat het bij OpenDNS ligt verwacht ik niet, aangezien op een andere computer die rechtstreeks OpenDNS gebruikt het wel goed gaat.

EDIT: Nu doet ie het weer niet (andere sites geeft hetzelfde resultaat):

code:

$ dig adobe.com

; <<>> DiG 9.5.1-P3 <<>> @10.1.1.20 adobe.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34411
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;adobe.com.                     IN      A

;; Query time: 4706 msec
;; SERVER: 10.1.1.20#53(10.1.1.20)
;; WHEN: Tue Feb  2 19:36:03 2010
;; MSG SIZE  rcvd: 27

$ dig @208.67.222.222 adobe.com

; <<>> DiG 9.5.1-P3 <<>> @208.67.222.222 adobe.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached
$ ping 208.67.222.222
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
64 bytes from 208.67.222.222: icmp_seq=1 ttl=50 time=25.8 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=50 time=25.9 ms
64 bytes from 208.67.222.222: icmp_seq=3 ttl=50 time=23.6 ms
64 bytes from 208.67.222.222: icmp_seq=4 ttl=50 time=24.4 ms
^C
--- 208.67.222.222 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3010ms
rtt min/avg/max/mdev = 23.667/24.957/25.927/0.955 ms
$ dig @10.1.1.1 adobe.com

; <<>> DiG 9.5.1-P3 <<>> @10.1.1.1 adobe.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24185
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;adobe.com.                     IN      A

;; ANSWER SECTION:
adobe.com.              85959   IN      A       192.150.18.117

;; Query time: 1 msec
;; SERVER: 10.1.1.1#53(10.1.1.1)
;; WHEN: Tue Feb  2 19:38:24 2010
;; MSG SIZE  rcvd: 43

De 1e probeert de server zelf (10.1.1.20), de 2e met OpenDNS, waarbij ik een connection timeout krijg maar ik kan hem wel pingen, en de 3e is de router (10.1.1.1). In de router staan ook de IP adressen van OpenDNS ingesteld.

[ Voor 76% gewijzigd door hostname op 02-02-2010 19:41 . Reden: Resultaten toegevoegd van testen ]

[TwOkkie]

hostname schreef op dinsdag 02 februari 2010 @ 16:55:

$ dig @208.67.222.222 adobe.com

; <<>> DiG 9.5.1-P3 <<>> @208.67.222.222 adobe.com
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached

Dit is het probleem dat je moet oplossen. Hiermee ga je buiten je eigen bind om, dus zal het niet aan die configuratie liggen.

Als je het aan je router vraagt, kan het zijn dat het antwoord van de andere OpenDNS-server komt, of zelfs uit de cache. Dat getal in de tweede kolom van je answer section is overigens de tijd dat het antwoord nog in de cache bewaard zal worden. Is wel leuk omdat je daaruit kan afleiden wanneer het antwoord is verkregen. Uitgaande van een TTL van 86400 is adobe.com door je router 441 seconden geleden opgevraagd en in de cache geplaatst.

Mijn eerste vraag zou zijn of de .220.220 op dat moment ook een timeout gaf?

Dat je de server kan pingen is mooi, maar sluit niet uit dat de DNS-service op die server down is. Je zou ook een kale "dig @server" kunnen doen. Je zou daarmee de lijst van root-servers moeten krijgen.

Heb je firewall-problemen al uitgesloten? Werkt het beter als je de DNS-service op je ADSL-router uitzet?

[ Voor 4% gewijzigd door TwOkkie op 02-02-2010 22:05 ]

[hostname]

Dat de DNS-service eruit lag lijkt me sterk, aangezien het via de router met exact dezelfde DNS instellingen wel goed ging. Ik verdenk nu inderdaad ook de router.
Dat kan nog lastig worden omdat de router setup nogal raar is. Een standaard speedtouch van KPN wordt als modem gebruikt, maar wel met alle routing-functies nog aan. Vervolgens hangt daar een Sitecom (voor wireless-n) aan, met een statisch ip in het netwerk van de speedtouch. daaraan hangen weer alle computers (via switches). kan verder in de sitecom ook niks over dns vinden. Bij het instellen van internet moest ik 2 DNS server opgeven, meer niet. In de speedtouch staat het vinkje bij 'Activate DNS Server' uit.

[TwOkkie]

hostname schreef op dinsdag 02 februari 2010 @ 22:23:
Dat de DNS-service eruit lag lijkt me sterk, aangezien het via de router met exact dezelfde DNS instellingen wel goed ging. Ik verdenk nu inderdaad ook de router.

Maar hoe weet je dat die router het antwoord bij dezelfde server heeft gehaald en niet die andere? Bovendien stond het antwoord al 7:21 in de cache, zoals je aan de TTL kon zien.

Dat kan nog lastig worden omdat de router setup nogal raar is. Een standaard speedtouch van KPN wordt als modem gebruikt, maar wel met alle routing-functies nog aan. Vervolgens hangt daar een Sitecom (voor wireless-n) aan, met een statisch ip in het netwerk van de speedtouch. daaraan hangen weer alle computers (via switches). kan verder in de sitecom ook niks over dns vinden. Bij het instellen van internet moest ik 2 DNS server opgeven, meer niet. In de speedtouch staat het vinkje bij 'Activate DNS Server' uit.

Die sitecom is 10.1.1.1 ?

Ik heb gehoord dat er routers bestaan die uitgaande DNS-requests opvangen en zelf gaan resolven. Ik weet niet of die sitecom er ook zo een is.

Kun je voor de gein eens dit commando uitvoeren:

code:

dig @ns1.tweakers.net www.tweakers.net

Als je in de flags (onder HEADER) aa ziet staan, komt het antwoord direct van de authoritative nameserver. Je zal die flag ook zien staan als je je eigen bind om je .local-gegevens vraagt. Als die aa er niet staat, haalt je router smerige truuks uit.

Of kun je anders eens tcpdump laten draaien tijdens het dig-gen?
bv:

code:

 tcpdump -n -i eth0 -v -v host <nameserver>

[hostname]

10.1.1.1 is inderdaad de sitecom. de speedtouch is 10.0.0.138.
De server met bind is 10.1.1.20. Ik test vanaf 10.1.1.30.

Werkende dig:

code:

$ dig @ns1.tweakers.net tweakers.net
; <<>> DiG 9.5.1-P3 <<>> @ns1.tweakers.net www.tweakers.net
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25161
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.tweakers.net.      IN  A

;; ANSWER SECTION:
www.tweakers.net.   86400   IN  A   213.239.154.35

;; Query time: 15 msec
;; SERVER: 213.193.210.17#53(213.193.210.17)
;; WHEN: Thu Feb  4 23:11:32 2010
;; MSG SIZE  rcvd: 50

niet werkend:

code:

$ dig @ns1.tweakers.net www.tweakers.net

; <<>> DiG 9.5.1-P3 <<>> @ns1.tweakers.net www.tweakers.net
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

Binnen 1 minuut na elkaar uitgevoerd, zo willekeurig is ie dus. Tijdens een dig www.google.nl (met een timeout, zelfde output als bij het tweakers.net voorbeeld), geeft tcpdump dit:

code:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:15:59.390591 IP (tos 0x0, ttl 64, id 10811, offset 0, flags [none], proto UDP (17), length 55) 10.1.1.30.53600 > 10.1.1.20.53: [bad udp cksum f355!] 63440+ A? google.nl. (27)
23:16:04.393080 IP (tos 0x0, ttl 64, id 10812, offset 0, flags [none], proto UDP (17), length 55) 10.1.1.30.53600 > 10.1.1.20.53: [bad udp cksum f355!] 63440+ A? google.nl. (27)
23:16:09.397174 IP (tos 0x0, ttl 64, id 10813, offset 0, flags [none], proto UDP (17), length 55) 10.1.1.30.53600 > 10.1.1.20.53: [bad udp cksum f355!] 63440+ A? google.nl. (27)
23:16:14.400398 arp who-has 10.1.1.20 tell 10.1.1.30
23:16:14.400976 arp reply 10.1.1.20 is-at 00:24:21:9c:6f:74
23:16:17.087145 IP (tos 0x0, ttl 64, id 12231, offset 0, flags [none], proto UDP (17), length 185) 10.1.1.20.53 > 10.1.1.30.53600: 63440 q: A? google.nl. 3/4/0 google.nl. A 216.239.59.104, google.nl.[|domain]
23:16:17.087186 IP (tos 0xc0, ttl 64, id 10814, offset 0, flags [none], proto ICMP (1), length 213) 10.1.1.30 > 10.1.1.20: ICMP 10.1.1.30 udp port 53600 unreachable, length 193
    IP (tos 0x0, ttl 64, id 12231, offset 0, flags [none], proto UDP (17), length 185) 10.1.1.20.53 > 10.1.1.30.53600: 63440 q:[|domain][|icmp]

Als het wel werkt;

code:

; <<>> DiG 9.5.1-P3 <<>> google.nl
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13976
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.nl.         IN  A

;; ANSWER SECTION:
google.nl.      1631    IN  A   209.85.229.104
google.nl.      1631    IN  A   216.239.59.104
google.nl.      1631    IN  A   74.125.77.104

;; AUTHORITY SECTION:
google.nl.      7022    IN  NS  ns1.google.com.
google.nl.      7022    IN  NS  ns2.google.com.
google.nl.      7022    IN  NS  ns3.google.com.
google.nl.      7022    IN  NS  ns4.google.com.

;; Query time: 3 msec
;; SERVER: 10.1.1.20#53(10.1.1.20)
;; WHEN: Thu Feb  4 23:19:06 2010
;; MSG SIZE  rcvd: 157

code:

23:19:06.583749 IP (tos 0x0, ttl 64, id 10815, offset 0, flags [none], proto UDP (17), length 55) 10.1.1.30.42964 > 10.1.1.20.53: [bad udp cksum b840!] 13976+ A? google.nl. (27)
23:19:06.584301 IP (tos 0x0, ttl 64, id 12232, offset 0, flags [none], proto UDP (17), length 185) 10.1.1.20.53 > 10.1.1.30.42964: 13976 q: A? google.nl. 3/4/0 google.nl. A 209.85.229.104, google.nl.[|domain]

Ik zie allemaal dingen als bad udp checksum, lijkt me niet erg in orde, maar heb geen flauw idee wat het is.

[TwOkkie]

Ah, kijk. Als je naar de eerste tcpdump kijkt, zie je het volgende:

code:

23:15:59 Wat is het IP van google.nl?
23:16:04 Wat is het IP van google.nl? (poging 2)
23:16:09 Wat is het IP van google.nl? (poging 3)
[wat arp-traffic. Waarschijnlijk van geen belang als de machines elkaar al kennen. Check evt. met "arp -na"]
23:16:17 Uhh... google.nl zit op 216.239.59.104
23:16:17 Ja duh, er luistert niemand meer op udp poort 53600 hoor.

Blijkbaar doet je .20 er erg lang over om google.nl te resolven. Drie keer vragen en pas na 18 seconden met een antwoord komen. Jouw client op .30 heeft dan de hoorn al op de haak gegooid. Maar waarom duurt het zo lang? Worden de antwoorden wel de goeie kant op gestuurd? Is dat rondje arp-en toch een hint?

Nou ben ik heel erg benieuwd wat een tcpdump op die .20 laat zien.

Of je je ongerust moet maken over die UDP-checksum weet ik even niet. Ik heb dat bij tcpdump niet eerder gezien. Wireshark geeft vaak vals alarm als de checksum in de firmware van de ethernetkaart gedaan wordt in plaats van door je kernel, maar dat kun je uitzetten. Bij tcpdump is dit me nog niet eerder opgevallen, maar omdat het bij een goeie query ook optreedt, is er waarschijnlijk geen probleem.

[ Voor 5% gewijzigd door TwOkkie op 05-02-2010 10:18 ]

[hostname]

Een werkende dig google.nl geeft dit:

code:

# tcpdump -n -i eth0 -v -v host 10.1.1.102
16:22:00.582820 IP (tos 0x0, ttl 64, id 30063, offset 0, flags [none], proto UDP (17), length 55) 10.1.1.102.59316 > 10.1.1.20.53: [udp sum ok] 35079+ A? google.nl. (27)
16:22:05.579587 arp who-has 10.1.1.20 tell 10.1.1.102
16:22:05.579613 arp reply 10.1.1.20 is-at 00:24:21:9c:6f:74
16:22:05.582171 IP (tos 0x0, ttl 64, id 30064, offset 0, flags [none], proto UDP (17), length 55) 10.1.1.102.59316 > 10.1.1.20.53: [udp sum ok] 35079+ A? google.nl. (27)
16:22:10.582209 IP (tos 0x0, ttl 64, id 30065, offset 0, flags [none], proto UDP (17), length 55) 10.1.1.102.59316 > 10.1.1.20.53: [udp sum ok] 35079+ A? google.nl. (27)
16:22:15.334643 IP (tos 0x0, ttl 64, id 15971, offset 0, flags [none], proto UDP (17), length 185) 10.1.1.20.53 > 10.1.1.102.59316: 35079 q: A? google.nl. 3/4/0 google.nl. A 209.85.229.104, google.nl.[|domain]

(de .30 gaf nogal wat ruis van andere dingen, dus even op een andere computer (zelfde OS etc) gedaan). Query time was wel 4771msec, dus hij deed er wel erg lang over. Flags was qr rd ra.

Tijdens een (niet-werkende) dig op adobe.com (om de cache uit te sluiten), geeft een tcpdump van de OpenDNS servers op de .20 dit:

code:

# tcpdump -n -i eth0 -v -v host 208.67.222.222
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:26:50.057766 IP (tos 0x0, ttl 64, id 42500, offset 0, flags [none], proto UDP (17), length 66) 10.1.1.20.57473 > 208.67.222.222.53: [bad udp cksum d4a2!] 13607+ [1au] A? adobe.com. ar: . OPT UDPsize=4096 OK (38)
16:26:50.075952 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 82) 208.67.222.222.53 > 10.1.1.20.60697: [udp sum ok] 13607 q: A? adobe.com. 1/0/1 adobe.com. A 192.150.18.117 ar: . OPT UDPsize=4096 (54)
16:26:50.075990 IP (tos 0xc0, ttl 64, id 42501, offset 0, flags [none], proto ICMP (1), length 110) 10.1.1.20 > 208.67.222.222: ICMP 10.1.1.20 udp port 60697 unreachable, length 90
        IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 82) 208.67.222.222.53 > 10.1.1.20.60697: 13607 q:[|domain]
16:27:04.347197 IP (tos 0x0, ttl 64, id 42502, offset 0, flags [none], proto UDP (17), length 66) 10.1.1.20.48371 > 208.67.222.222.53: [bad udp cksum bb73!] 38350+ [1au] A? adobe.com. ar: . OPT UDPsize=512 OK (38)
16:27:04.366193 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 82) 208.67.222.222.53 > 10.1.1.20.60697: [udp sum ok] 38350 q: A? adobe.com. 1/0/1 adobe.com. A 192.150.18.117 ar: . OPT UDPsize=4096 (54)
16:27:04.366230 IP (tos 0xc0, ttl 64, id 42503, offset 0, flags [none], proto ICMP (1), length 110) 10.1.1.20 > 208.67.222.222: ICMP 10.1.1.20 udp port 60697 unreachable, length 90
        IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 82) 208.67.222.222.53 > 10.1.1.20.60697: 38350 q:[|domain]

code:

# tcpdump -n -i eth0 -v -v host 208.67.220.220
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:26:56.272069 IP (tos 0x0, ttl 64, id 64065, offset 0, flags [none], proto UDP (17), length 66) 10.1.1.20.31393 > 208.67.220.220.53: [bad udp cksum ab56!] 60212+ [1au] A? adobe.com. ar: . OPT UDPsize=4096 OK (38)
16:26:56.291744 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 82) 208.67.220.220.53 > 10.1.1.20.26104: [udp sum ok] 60212 q: A? adobe.com. 1/0/1 adobe.com. A 192.150.18.117 ar: . OPT UDPsize=4096 (54)
16:26:56.291779 IP (tos 0xc0, ttl 64, id 64066, offset 0, flags [none], proto ICMP (1), length 110) 10.1.1.20 > 208.67.220.220: ICMP 10.1.1.20 udp port 26104 unreachable, length 90
        IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), length 82) 208.67.220.220.53 > 10.1.1.20.26104: 60212 q:[|domain

Er lijtk wel een antwoord van OpenDNS te komen, alleen bind heeft de poort alweer gesloten? Of denk ik nu heel vreemd?

Omdat ik ook de router verdenk, heb ik de forwarders eens vervangen door 10.1.1.1 (de router). Tot nog toe heb ik nog geen DNS failures gehad (maar eerst ging het ook wel eens een half uur goed ). De tcpdump van een dig nu.nl (andere hosts geeft hetzelfde):

code:

# tcpdump -n -i eth0 -v -v host 10.1.1.1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:31:39.726172 IP (tos 0x0, ttl 64, id 36070, offset 0, flags [none], proto UDP (17), length 62) 10.1.1.20.63797 > 10.1.1.1.53: [bad udp cksum 3b2e!] 12931+ [1au] A? nu.nl. ar: . OPT UDPsize=4096 OK (34)
16:31:39.748141 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 94) 10.1.1.1.53 > 10.1.1.20.63797: 12931 q: A? nu.nl. 2/0/1 nu.nl. A 62.69.179.198, nu.nl. A[|domain

arp -na geeft trouwens dit:

code:

? (10.1.1.30) at 08:00:27:39:2a:60 [ether] on eth0
? (10.1.1.102) at 00:21:85:b6:ad:63 [ether] on eth0
? (10.1.1.50) at 00:1a:a0:3d:32:80 [ether] on eth0
? (10.1.1.21) at 00:24:1d:52:a4:45 [ether] on eth0
? (10.1.1.1) at 00:0c:f6:4a:b6:d2 [ether] on eth0
? (10.1.1.40) at 08:00:27:0e:92:ee [ether] on eth0
? (10.1.1.103) at 00:13:72:07:6c:81 [ether] on eth0

[TwOkkie]

hostname schreef op zaterdag 06 februari 2010 @ 16:37:
Er lijtk wel een antwoord van OpenDNS te komen, alleen bind heeft de poort alweer gesloten? Of denk ik nu heel vreemd?

Nee, dat is precies wat je ziet. Bind stuurt een vraag, krijgt zeer snel daarop een antwoord maar blijkt dan al de hoorn op de haak te hebben gegooid. Blijkbaar is bind niet meer geinteresseerd in antwoorden op dat moment. Vreemd, heel vreemd.

Wel jammer dat je de werkende google.nl in de richting van de client hebt gecaptured in plaats van richting de openDNS-servers of beide. Je kan "host A or host B or host C" doen als je alles tegelijk wil zien.

Waar ik nu aan zit te denken is een te korte time-out van bind of een ander proces dat zoveel UDP-verkeer genereert dat bind geen socket meer kan openen voor het antwoord. Maar het is vast iets heel anders, want via je router werkt het nu wel...

[Verwijderd]

Waarom gebruik je überhaupt forwarders?

[TwOkkie]

Verwijderd schreef op maandag 08 februari 2010 @ 01:22:
Waarom gebruik je überhaupt forwarders?

In het geval van OpenDNS waarschijnlijk vanwege de extra service die zij bieden.

Of anders om te profiteren van de veel beter gevulde cache van je provider.

[Guru Evi]

OpenDNS heeft niet zoveel servers in Europa (enkel in Londen). Misschien kun je eerst even testen met een andere reeks DNS servers.

[TwOkkie]

Guru Evi schreef op woensdag 17 februari 2010 @ 03:51:
OpenDNS heeft niet zoveel servers in Europa (enkel in Londen). Misschien kun je eerst even testen met een andere reeks DNS servers.

Hoe zou dat bovenstaande fenomeen kunnen verklaren?

[hostname]

Aangezien het nu via m'n router gaat en wel werkt heb ik het er even bij laten zitten (tijdgebrek enzo)...

Waarom ik forwarders gebruik? Omdat het bij een eigen resolver ook niet werkt. Andere forwarders had ik ook al geprobeerd.

(OpenDNS heeft volgens mij laatst ook in Amsterdam servers in gebruik genomen).