Test your connectivity for World IPv6 Day

[Frank Bulk - iName.com]

For the record, this is what DNSstuff reported during that issue:
http://www.dnsstuff.com/tools/dnsreport?domain=juniper.net&format=raw&loadre
sults=true&token=1301138f89e269ff13071119163a5015
It also confirms that udns2 was not returning answers.

Frank

-----Original Message-----
From: ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de
[mailto:ipv6-ops-bounces+frnkblk=iname.com at lists.cluenet.de] On Behalf Of
Havard Eidnes
Sent: Wednesday, June 08, 2011 6:59 AM
To: daniel at shunoshu.net
Cc: ipv6-ops at lists.cluenet.de
Subject: Re: Test your connectivity for World IPv6 Day

>> 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