Subject: Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)

From: [email-masked]
Date: Wed, 4 Aug 2004 03:59:35 +0000

> So the whole delegation thing is broken. The int. TLD servers delegate
> ip6.int to imag.imag.fr which feels it self authoritative, but isn't
> in the NS RRset of the ip6.int zone. And ip6.int is delegated to
> munnari.oz.au which doesn't know about this (anymore).
> 
> 
> Regards,
> Daniel

	so... this was apparently enough to get the attention it
	deserved.  the long postponed migration from imag.imag.fr.
	to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed
	from the NS list in the INT zone.
	and munnari.oz.au has been removed.  -  more cleanup in the
	next week or two.

--bill

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 4 Aug 2004 08:50:28 +0200

> 	and munnari.oz.au has been removed.  -  more cleanup in the

When you're at it, could you kick someone of isi.edu?

$ dig @a.root-servers.net. int. NS +norec +short
NS0.JA.NET.
NS1.CS.UCL.AC.UK.
NS.UU.NET.
NS.ICANN.ORG.
NS.ISI.EDU.

But ns.isi.edu is lame for .int:

$ dig @ns.isi.edu. int. SOA +norec | fgrep flags
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 8

I fully understand that the int. TLD is not your responsibility, but I
guess you know the right people (ns.isi.edu ops) there.

Best regards,
Daniel

---

From: David Malone <[email-masked]>
Date: Sat, 14 Aug 2004 09:17:56 +0100

On Wed, Aug 04, 2004 at 03:59:35AM +0000, [email-masked] wrote:
> 	more cleanup in the next week or two.

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. It seems that z.ip6.int is not listening on
port 53 (I'm getting ICMP port unreachable from both its IPv4 and
IPv6 addresses). {flag,dot}.ep.net seem to be both returning ServFail,
because I guess they've become lame.

As I can't get the SOA record, I can't tell who to contact.

	David.

---

From: [email-masked]
Date: Sat, 14 Aug 2004 11:50:33 +0000

> As I can't get the SOA record, I can't tell who to contact.

	well, it seems that IPv6 is not all that different than IPv4.
	we've been the target of a DDoS attack using IPv6 as the attack
	vector.  Mitigation techniques and SOPs are still oriented toward
	IPv4. :(  The problem should be stablized. Working thorugh the
	IPv6 backscatter traces is more problematic and will take some
	time - 

--bill

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 16 Aug 2004 12:10:17 +0200

On Sat, Aug 14, 2004 at 09:17:56AM +0100, David Malone wrote:
> 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

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 16 Aug 2004 14:41:07 +0200

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, [email-masked] 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 [email-masked] 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

---

From: Lee Wilmot <[email-masked]>
Date: Mon, 16 Aug 2004 14:12:00 +0200

Daniel Roesen <[email-masked]> writes:

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
 * 

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

Lee Wilmot
RIPE NCC

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 16 Aug 2004 20:51:11 +0200

> irrelevant since it will never be listed as a nameserver for

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

---

From: Lee Wilmot <[email-masked]>
Date: Tue, 17 Aug 2004 11:29:19 +0200

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

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 19 Aug 2004 21:59:51 +0200

> 	and munnari.oz.au has been removed.  -  more cleanup in the

Well, two weeks down the road and things got even worse:

NS list summary for ip6.int. from parent (int.) servers
  == flag.ep.net. ns3.nic.fr. y.ip6.int.
  == z.ip6.int.

$ dig @flag.ep.net. int. SOA +norec | fgrep status:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740
$ dig @ns3.nic.fr int. SOA +norec | fgrep status:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334
$ dig @y.ip6.int int. SOA +norec | fgrep status:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872
$ dig @z.ip6.int int. SOA +norec
;; connection timed out; no servers could be reached

So we have 3 out of 4 servers totally broken.

Looks like the importance of ip6.int is way overstated by some folks.

Regards,
Daniel

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 20 Aug 2004 09:32:51 +0200

[itojun copied as he replied on something similar but on the sig-ipv6
list]

> Looks like the importance of ip6.int is way overstated by some folks.

I guess the people running the servers have found out that ip6.int is
not that important and nicely let it rot away, apparently not enough/no
people complain thus this is a good thing. It is quite bad to see that
these 'important' (ahem) services have been so recklessly managed over
the last couple of years. 

I hope the 'powers that be' see that it is just better to remove the
ip6.int servers entirely and officially, that way at least people can
know why they are broken: because they have been deprecated 3 years ago.

Greets,
 Jeroen

---

From: Robert Martin-Legène <[email-masked]>
Date: Fri, 20 Aug 2004 09:39:40 +0200

> Looks like the importance of ip6.int is way overstated by some folks.

Shouldn't you be asking these servers for ip6.int instead of asking them
for int.? Either way, I seem to be getting the same results.

For int. itself, it seems that only ns.isi.edu is not authoritative.

-- Robert Martin-Legène

---

From: kawamura seiichi <[email-masked]>
Date: Fri, 20 Aug 2004 19:40:46 +0900

Greetings,

(First time writing to this Mailing list)
Are there any temporary solutions to this ip6.int.
broken problem? or do we just have to wait until 9/9?
Some applications keep asking for ip6.int. and 
servers not responding cause delays to the application services.
Would be very helpful if someone could give me tips.

Thank you 

-----
Seiichi

2004/08/20 09:39:40 +0200にRobert Martin-Leg鈩e <[email-masked]>さんに頂いた
「Re: [[email-masked]] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)」への返事です。
>-- Robert Martin-Leg鈩e

---

From: David Malone <[email-masked]>
Date: Fri, 20 Aug 2004 12:05:22 +0100

> servers not responding cause delays to the application services.

If you have access to the C libraries or whatever is generating the
lookups, it should be easy enough to edit the source or binary edit
the library to look up something else that will fail quickly rather
than time out.

A cleaner option might be to tell your recursive name server that
it is authorititive for ip6.int and give it an empty zone (this is
what I do for zones that have problems with AAAA lookups). This
prevents it having to time out.

	David.

---

From: kawamura seiichi <[email-masked]>
Date: Fri, 20 Aug 2004 20:22:40 +0900

David,

Thank you very much!

>prevents it having to time out.

I think this is the quickest and the more cleaner answer.
I was debating weather to do this or not since 
it would leave an "odd" record in the nameserver files, but
it feels a little bit more warm and fuzzy when I have 
confirmation :-)

thanks again.
------
Seiichi

2004/08/20 12:05:22 +0100にDavid Malone <[email-masked]>さんに頂いた
「Re: [[email-masked]] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)」への返事です。

---

From: Gert Doering <[email-masked]>
Date: Fri, 20 Aug 2004 13:54:33 +0200

Hi,

> Would be very helpful if someone could give me tips.

The best way would be to fix these applications as fast as possible.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  65398  (60210)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299