[ipv6-wg@ripe.net] 2.0.0.2.ip6.arpa broken
On Sat, Aug 14, 2004 at 09:17:56AM +0100, David Malone wrote:
2.0.0.2.ip6.int has become completely unavailable in the last few days, resulting in delays for people connecting from 6to4 addresses via ssh and the like.
2.0.0.2.ip6.arpa is also broken in all colors. soa @ns.apnic.net. for ip6.arpa. has serial: 2004071900 soa @ns.icann.org. for ip6.arpa. has serial: 2004071900 soa @ns-sec.ripe.net. for ip6.arpa. has serial: 2004071900 dig @tinnie.arin.net. for SOA of parent (ip6.arpa.) failed ==> tinnie.arin.net IPv6 connectivity is broken: $ dig @69.25.34.195 ip6.arpa. SOA +short dns1.icann.org. hostmaster.icann.org. 2004071900 3600 1800 604800 10800 $ dig @2001:440:2000:1::22 ip6.arpa. SOA ; <<>> DiG 9.2.3 <<>> @2001:440:2000:1::22 ip6.arpa. SOA ;; global options: printcmd ;; connection timed out; no servers could be reached Found 0 NS and 0 glue records for 2.0.0.2.ip6.arpa. @ns.apnic.net. (AUTH) Found 0 NS and 0 glue records for 2.0.0.2.ip6.arpa. @ns.icann.org. (AUTH) Found 4 NS and 4 glue records for 2.0.0.2.ip6.arpa. @ns-sec.ripe.net. (AUTH) DNServers for ip6.arpa. === 3 were also authoritatve for 2.0.0.2.ip6.arpa. === 0 were non-authoritative for 2.0.0.2.ip6.arpa. ERROR: Found 2 diff sets of NS records === from servers authoritative for 2.0.0.2.ip6.arpa. WARNING: ns.apnic.net. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone WARNING: ns.icann.org. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone WARNING: ns-sec.ripe.net. claims to be authoritative for 2.0.0.2.ip6.arpa. == but no NS record at parent zone ==> so although the three remaining NS for ip6.arpa have the same SOA serial, they obviously have a different view on the NS RRset for 2.0.0.2.ip6.arpa... and all are authoritative for 2.0.0.2.ip6.arpa. Now looking at the NS RRset ns-sec.ripe.net returns for 2.0.0.2.ip6.arpa: == ns-apnic.6to4.nro.net. ns-arin.6to4.nro.net. ns-lacnic.6to4.nro.net. == ns-ripe.6to4.nro.net. soa @ns-apnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 dig @ns-arin.6to4.nro.net. for SOA of 2.0.0.2.ip6.arpa. failed soa @ns-lacnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 soa @ns-ripe.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 ==> ns-arin.6to4.nro.net == tinnie.arin.net, so we have the same IPv6 reachability problem again What a mess all over... why do ns.apnic.net and ns.icann.org return NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but ns-sec.ripe.net returning one? It looks like the whole 2.0.0.2.ip6.arpa is missing in the ip6.arpa zone, and ns-sec.ripe.net is only by chance carrying the 2.0.0.2.ip6.arpa zone, thus returning the NS RRset. I wonder where's the right place to report such global (multi-RIR/org) DNS problems to, if not v6ops. I see no "global IPv6 operations" list, can anyone enlighten me? Best regards, Daniel
Daniel Roesen <dr@cluenet.de> writes: * 2.0.0.2.ip6.arpa is also broken in all colors. As far as I know, this zone has not yet been inserted in the DNS tree (maybe because setup is incomplete) and the queries you are making will not be relevant to recursive queries starting at the root. But perhaps your mail stems from an announcement made on the v6ops list about setup of 2.0.0.2.ip6.arpa being complete ? In that case I understand your concern! <SNIP> * Now looking at the NS RRset ns-sec.ripe.net returns for 2.0.0.2.ip6.arpa: * * == ns-apnic.6to4.nro.net. ns-arin.6to4.nro.net. ns-lacnic.6to4.nro.net. * == ns-ripe.6to4.nro.net. * * soa @ns-apnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * dig @ns-arin.6to4.nro.net. for SOA of 2.0.0.2.ip6.arpa. failed * soa @ns-lacnic.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * soa @ns-ripe.6to4.nro.net. for 2.0.0.2.ip6.arpa. serial: 2004072901 * * ==> ns-arin.6to4.nro.net == tinnie.arin.net, so we have the same IPv6 * reachability problem again * * What a mess all over... why do ns.apnic.net and ns.icann.org return * NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but * ns-sec.ripe.net returning one? Where are any of these servers listed for the zone ? Why are you querying them ? The reason for ns-sec.ripe.net returning an answer is an unfortunate curiousity of RIPE NCC's current nameserver rearrangement which is irrelevant since it will never be listed as a nameserver for 2.0.0.2.ip6.arpa. * It looks like the whole 2.0.0.2.ip6.arpa * is missing in the ip6.arpa zone, * and ns-sec.ripe.net is only by chance * carrying the 2.0.0.2.ip6.arpa zone, thus returning the NS RRset. * * I wonder where's the right place to report such global (multi-RIR/org) * DNS problems to, if not v6ops. I see no "global IPv6 operations" list, * can anyone enlighten me? I think the best place to start reporting zone-specific DNS problems is with the SOA record RNAME. Lee Wilmot RIPE NCC
On Mon, Aug 16, 2004 at 02:12:00PM +0200, Lee Wilmot wrote:
* 2.0.0.2.ip6.arpa is also broken in all colors.
As far as I know, this zone has not yet been inserted in the DNS tree (maybe because setup is incomplete)
This was my idea as well, as I pointed out.
and the queries you are making will not be relevant to recursive queries starting at the root.
They _are_ relevant. A resolver queries the roots, they delegate to the ip6.arpa nameservers. One of those is ns-sec.ripe.net. If a resolver then goes on asking ns-sec.ripe.net for 2.0.0.2.arpa, the resolver _does_ get an answer. So it _is_ relevant.
But perhaps your mail stems from an announcement made on the v6ops list about setup of 2.0.0.2.ip6.arpa being complete ?
Uhm no idea. I just assumed that things should work, as ns-sec.ripe.net returned some SOA for that.
* What a mess all over... why do ns.apnic.net and ns.icann.org return * NXDOMAIN when queried for the NS RRset for 2.0.0.2.ip6.arpa, but * ns-sec.ripe.net returning one?
Where are any of these servers listed for the zone ? Why are you querying them ?
Those are the servers for ip6.arpa.
The reason for ns-sec.ripe.net returning an answer is an unfortunate curiousity of RIPE NCC's current nameserver rearrangement which is irrelevant since it will never be listed as a nameserver for 2.0.0.2.ip6.arpa.
Resolvers start from the root and work their way up. ns-sec.ripe.net is one of the ip6.arpa servers, so it would answer.
* I wonder where's the right place to report such global (multi-RIR/org) * DNS problems to, if not v6ops. I see no "global IPv6 operations" list, * can anyone enlighten me?
I think the best place to start reporting zone-specific DNS problems is with the SOA record RNAME.
Well, as it was not clear which zone/server actually had what problem, to which SOA contact? Well yes, dns-admin@apnic.net would have been an idea, according to the SOA present for 2.0.0.2.ip6.arpa at ns-sec.ripe.net. BTW... I've tried mailing noc@icann.org to have them fix the broken int. TLD delegation, but this went unanswered. Not encouraging. ns.isi.edu is now authoritative again for int., but ns.ripe.net is still not in the delegation NS RRset within the root zone, albeit being listed in the NS RRset of the int. zone. Regards, Daniel
On Mon, Aug 16, 2004 at 02:12:00PM +0200, Lee Wilmot wrote:
The reason for ns-sec.ripe.net returning an answer is an unfortunate curiousity of RIPE NCC's current nameserver rearrangement which is irrelevant since it will never be listed as a nameserver for 2.0.0.2.ip6.arpa.
BTW... $ dig ip6.arpa. NS @a.root-servers.net. +short NS.APNIC.NET. NS.ICANN.ORG. NS.RIPE.NET. TINNIE.ARIN.NET. $ dig ip6.arpa. NS @ns.ripe.net +short ns.apnic.net. ns.icann.org. ns-sec.ripe.net. tinnie.arin.net. NS RRset in zone ip6.arpa is not matching the NS RRset for ip6.arpa in the root zone. ns.ripe.net != ns-sec.ripe.net by IP address, but still both are auth for 2.0.0.2.ip6.arpa: $ dig @ns.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 $ dig @ns-sec.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 So the relevance is given, no matter why ns-sec gets involved (because the in-zone NS RRset overwrites the NS RRset from the roots in caches). I think it would be a good idea[tm] to remove the 2.0.0.2.ip6.arpa zone from ns.ripe.net and ns-sec.ripe.net if you don't intend to publish the zone... Best regards, Daniel
Hi Daniel, <SNIP> * $ dig ip6.arpa. NS @a.root-servers.net. +short * NS.APNIC.NET. * NS.ICANN.ORG. * NS.RIPE.NET. * TINNIE.ARIN.NET. * $ dig ip6.arpa. NS @ns.ripe.net +short * ns.apnic.net. * ns.icann.org. * ns-sec.ripe.net. * tinnie.arin.net. * * NS RRset in zone ip6.arpa is not matching the NS RRset for ip6.arpa in * the root zone. Ah, that's a glaring problem. I wondered where you had seen ns-sec.ripe.net referenced. We asked the primary operator for ip6.arpa to move ns.ripe.net -> ns-sec.ripe.net a while ago, apparently they didn't notify the parent zone primary. We've sent them a reminder. In a previous post you mentioned: * ns.isi.edu is now authoritative again for int., but * ns.ripe.net is still not in the delegation NS RRset within the * root zone, albeit being listed in the NS RRset of the int. zone. Coincidentally, a few days ago we requested that the primary operator for int change the server ns.ripe.net -> ns-sec.ripe.net (and notify their parent...) * ns.ripe.net != ns-sec.ripe.net by IP address, but still both are auth * for 2.0.0.2.ip6.arpa: * * $ dig @ns.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short * master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 * $ dig @ns-sec.ripe.net. 2.0.0.2.ip6.arpa. SOA +norec +short * master.apnic.net. dns-admin.apnic.net. 2004072901 7200 1800 604800 172800 * * So the relevance is given, no matter why ns-sec gets involved (because * the in-zone NS RRset overwrites the NS RRset from the roots in caches). * * I think it would be a good idea[tm] to remove the 2.0.0.2.ip6.arpa * zone from ns.ripe.net and ns-sec.ripe.net if you don't intend to * publish the zone... We've temporarily moved the zone to a different machine prior to delegation so you should get NXDOMAIN going via the roots. APNIC will update the ns-ripe.6to4.nro.net record as they are running the primary for 6to4.nro.net. Finally, we've notified ARIN that tinnie.arin.net is not reachable over v6 and that it's presenting the 2.0.0.2.ip6.arpa zone due to also running ip6.arpa. Thanks very much for your problem reports! Lee Wilmot RIPE NCC
participants (2)
-
Daniel Roesen -
Lee Wilmot