Re: xs4all dns (194.109.6.66 als 194.109.104.104) stuk?

In article <480aa2f4$0$14360$e4fe514c@news.xs4all.nl>,
	root@dragon.doktercom.nl (Operator) writes:
> In article <480a81ce$0$14347$e4fe514c@news.xs4all.nl>,
> 	"Miquel van Smoorenburg" <mikevs@xs4all.nederland.invalid> writes:

>>>>>>>[servfail]

>> Er zijn tot nu toe 2 domeinen hier genoemd die het niet doen,
>> en 1 daarvan is uitgezocht en volledig verklaarbaar: de DNS
>> van dat domein is (of was, zo lijkt het) gewoon stuk bij de
>> ISP die het domein runt.
> 
> Er lijkt een probleem te zitten bij
> ; <<>> DiG 9.3.4-P1 <<>> -4 @wf-dns-ext1.juniper.net www.juniper.net
> ; (1 server found)
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
> 
> Toen ik dat zag en van de ene naar de andere machine sprong
> waarbij de ene het wel deed en de andere het niet
> begon ik aan de OS versies te twijfelen, of aan de NAT
> in de router, maar bij remote hosts ging het ook (soms) fout.

Voorwat betreft wf-dns-ext1.juniper.net denk ik nu aan een
routing probleem. Die server zit in 2 verschillende netwerken.
149.140.194.65.in-addr.arpa domain name pointer wf-dns-ext1.juniper.net.
149.232.129.66.in-addr.arpa domain name pointer wf-dns-ext1.juniper.net.
    ^^^^^^^^^^
traceroute komt niet verder dan alter.net.

>> Ik zeg niet dat er niets mis is .. maar tot nu toe is het
>> niet te reproduceren, en worden we niet overspoeld met klachten.
>> Need more input.

Zolang er niet meer niet-werkende domeinen zijn is het lastig
debuggen en zou het best wel eens _niet_ aan de xs4all resolvers
kunnen liggen. Blijft over: het verschil in gedrag tussen
bind en pdns. Wat me nu is opgevallen:

;; ANSWER SECTION:
westford-nat.juniper.net. 300   IN      A       66.129.232.2

;; AUTHORITY SECTION:
juniper.net.            300     IN      NS      udns1.ultradns.net.
juniper.net.            300     IN      NS      udns2.ultradns.net.
juniper.net.            300     IN      NS      colo-dns.juniper.net.
juniper.net.            300     IN      NS      wf-dns-ext1.juniper.net.
juniper.net.            300     IN      NS      colo-dns-ext1.juniper.net.

;; ADDITIONAL SECTION:
udns1.ultradns.net.     23026   IN      A       204.69.234.1
udns2.ultradns.net.     23148   IN      A       204.74.101.1
colo-dns.juniper.net.   149127  IN      A       207.17.137.29
colo-dns-ext1.juniper.net. 35465 IN     A       207.17.137.57

;; SERVER: 194.109.9.99#53(194.109.9.99)

Bind heeft geen A record voor de problematische server.
Zou het kunnen zijn pdns_recursor in zo'n geval alle
RR records uit zijn cache delete...

Zelfde host geeft op pdns:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12913
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;westford-nat.juniper.net.      IN      A

;; SERVER: 194.109.6.66#53(194.109.6.66)


Iemand zin om in de source te duiken?