[ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)
On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning@vacation.karoshi.com wrote:
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).
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.
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
[itojun copied as he replied on something similar but on the sig-ipv6 list] On Thu, 2004-08-19 at 21:59, Daniel Roesen wrote:
On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning@vacation.karoshi.com wrote:
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).
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.
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.
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
On Thu, Aug 19, 2004 at 09:59:51PM +0200, Daniel Roesen wrote:
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.
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
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 <robert@martin-legene.dk>さんに頂いた 「Re: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)」への返事です。
On Thu, Aug 19, 2004 at 09:59:51PM +0200, Daniel Roesen wrote:
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.
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鈩e
On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote:
(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.
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.
David, Thank you very much!
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.
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 <dwmalone@maths.tcd.ie>さんに頂いた 「Re: [ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)」への返事です。
On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote:
(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.
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.
Hi, On Fri, Aug 20, 2004 at 07:40:46PM +0900, kawamura seiichi wrote:
(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.
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: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (6)
-
Daniel Roesen -
David Malone -
Gert Doering -
Jeroen Massar -
kawamura seiichi -
Robert Martin-Legène