Test your connectivity for World IPv6 Day
Havard Eidnes
he at nordu.net
Wed Jun 8 13:59:29 CEST 2011
>> Perhaps it was just us, but I write it here just in case anyone else saw
>> something similar.
>
> saw the same thing, looks like the glue for juniper.net was broken at
> ultradns for quite a while.
The NS RRset from the delegating zone (.net) is:
juniper.net. 172800 IN NS udns1.ultradns.net.
juniper.net. 172800 IN NS udns2.ultradns.net.
At least one of those two pointed-to name servers then really
ought to work, and as you (and I) saw, both of them returned
SERVFAIL error code when asked for info about or from the
juniper.net zone when doing a lookup. (Easily demonstrated at the
time using "dig +norec @nameserver www.juniper.net. a", mimicking
what a recursive resolver would do when starting with an empty
cache.)
So technically, this isn't just "broken glue" -- it was simply
broken name service for the zone.
Now, this has been fixed, and the NS RRset from the zone itself
is apparently
juniper.net. 14400 IN NS wf-dns-ext1.juniper.net.
juniper.net. 14400 IN NS colo-dns-ext1.juniper.net.
juniper.net. 14400 IN NS udns1.ultradns.net.
juniper.net. 14400 IN NS udns2.ultradns.net.
juniper.net. 14400 IN NS colo-dns.juniper.net.
so now there is an inconsistency between the copy of the NS RRset
in the delegation point in the parent zone and the zone itself.
If I were them, I would hurry up to fix this inconsistency by
updating the delegation in the parent zone, to actually get a
more resilient name service which was apparently designed and
configured, but not fully implemented since the parent delegation
has not been updated to correspond.
Oh, yes, I would also fix wf-dns-ext1.juniper.net not to respond
with SERVFAIL when queried for juniper.net before updating the
delegation (missing slave configuration?).
Regards,
- Håvard
More information about the ipv6-ops
mailing list