IPv6 glue AAAA RRs in the root zone
Haven't seen an announcement right here, so FYI: as of SOA# 2004072000 the following AAAA RRs (aka "IPv6 glue") are available from within the root zone: A.DNS.JP. AAAA 2001:DC4:0:0:0:0:0:1 D.DNS.JP. AAAA 2001:240:0:0:0:0:0:53 E.DNS.JP. AAAA 2001:200:0:1:0:0:0:4 F.DNS.JP. AAAA 2001:2F8:0:100:0:0:0:153 G.DNS.KR. AAAA 2001:DC5:A:0:0:0:0:1 -Peter
On Wed, Jul 21, 2004 at 09:07:20AM +0200, Peter Koch <pk@TechFak.Uni-Bielefeld.DE> wrote a message of 13 lines which said:
Haven't seen an announcement right here, so FYI:
I do not know if this counts as an announcement: http://www.reuters.com/newsArticle.jhtml?type=internetNews&storyID=5717373 Do note that the IPv6 server of ".fr", requested in February 2003, is still not announced.
On Wed, 2004-07-21 at 09:16, Stephane Bortzmeyer wrote:
On Wed, Jul 21, 2004 at 09:07:20AM +0200, Peter Koch <pk@TechFak.Uni-Bielefeld.DE> wrote a message of 13 lines which said:
Haven't seen an announcement right here, so FYI:
I do not know if this counts as an announcement:
http://www.reuters.com/newsArticle.jhtml?type=internetNews&storyID=5717373
Do note that the IPv6 server of ".fr", requested in February 2003, is still not announced.
Unless I completely mis-understood, but isn't that article talking about *root* servers and not GTLD servers, which Peter showed... Then again reuters is of course journalist blurb they can't tell the difference. Even though now .jp + .kr have a nameserver as glue as long as the roots are not available using IPv6 then it doesn't make a real difference as you can't reach them anyway over only IPv6... Greets, Jeroen
On Wed, Jul 21, 2004 at 09:29:40AM +0200, Jeroen Massar <jeroen@unfix.org> wrote a message of 48 lines which said:
Unless I completely mis-understood, but isn't that article talking about *root* servers and not GTLD servers, which Peter showed...
No, Peter was talking about root name servers, nothing changed for the ICANN gTLDs.
Even though now .jp + .kr have a nameserver as glue as long as the roots are not available using IPv6 then it doesn't make a real difference as you can't reach them anyway over only IPv6...
Wrong, several root name servers (of course, not ICANN's one) are reachable over IPv6: read http://www.root-servers.org/ and edit your db.root.
On Wed, 2004-07-21 at 09:47, Stephane Bortzmeyer wrote:
On Wed, Jul 21, 2004 at 09:29:40AM +0200, Jeroen Massar <jeroen@unfix.org> wrote a message of 48 lines which said:
Unless I completely mis-understood, but isn't that article talking about *root* servers and not GTLD servers, which Peter showed...
No, Peter was talking about root name servers, nothing changed for the ICANN gTLDs.
Even though now .jp + .kr have a nameserver as glue as long as the roots are not available using IPv6 then it doesn't make a real difference as you can't reach them anyway over only IPv6...
Wrong, several root name servers (of course, not ICANN's one) are reachable over IPv6: read http://www.root-servers.org/ and edit your db.root.
I know those addresses and I also know that all of those boxes have a latency over at least 200ms and very odd routability and those are far far far from to be called production. One really doesn't want to use those, just to be able to say that one can use IPv6.... BTW that list is missing i.root-servers.org which is located in Sweden, but that is a testing address and routes over the US instead of staying inside Europe... Greets, Jeroen -- Just to make my point, traces from noc.sixxs.net: B.root-servers.org: traceroute to 2001:478:65::53 (2001:478:65::53) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.612 ms 0.357 ms 0.409 ms 2 at-0-0-1.schiphol-rijk.ipv6.concepts-ict.net (2001:838:0:12::1) 3.943 ms 3.955 ms 3.908 ms 3 ge-1-0-0.nikhef.ipv6.concepts-ict.net (2001:838:0:11::1) 4.572 ms 4.554 ms 4.515 ms 4 eth10-0-0.xr1.ams1.gblx.net (2001:7f8:1::a500:3549:1) 4.722 ms 5.136 ms 4.718 ms 5 2001:450:1:1::22 (2001:450:1:1::22) 160.68 ms * 160.748 ms 6 3ffe:80a::10 (3ffe:80a::10) 156.026 ms 155.655 ms 155.943 ms 7 * * * 8 * F.root-servers.org: traceroute to 2001:500::1035 (2001:500::1035) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.385 ms 0.35 ms 0.341 ms 2 at-0-0-1.schiphol-rijk.ipv6.concepts-ict.net (2001:838:0:12::1) 3.929 ms 3.909 ms 3.904 ms 3 ge-1-0-0.nikhef.ipv6.concepts-ict.net (2001:838:0:11::1) 4.56 ms 4.525 ms 4.513 ms 4 ge-0.ams-ix.amstnl02.nl.bb.verio.net (2001:7f8:1::a500:2914:1) 4.722 ms 4.734 ms 4.869 ms 5 p16-1-0-0.r80.asbnva01.us.bb.verio.net (2001:418:0:2000::2b5) 86.17 ms 86.037 ms 85.92 ms 6 p16-1-2-0.r21.asbnva01.us.bb.verio.net (2001:418:0:2000::89) 86.039 ms 88.355 ms 85.984 ms 7 p16-0-1-2.r20.plalca01.us.bb.verio.net (2001:418:0:2000::101) 146.398 ms 146.33 ms 146.32 ms 8 ge-6-1.a01.snfcca05.us.ra.verio.net (2001:418:0:702b::4) 147.015 ms 146.816 ms 146.932 ms 9 fa-4-6.a01.snfcca05.us.ce.verio.net (2001:418:1c00:5000::2) 147.053 ms 146.995 ms 147.068 ms 10 2001:500::1035 (2001:500::1035) 147.002 ms 147.054 ms 146.961 ms H.root-servers.org: traceroute to 2001:500:1::803f:235 (2001:500:1::803f:235) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.386 ms !H 0.347 ms !H 0.349 ms !H Which gets announced as a /48 thus doesn't come through the filters... M.root-servers.org: traceroute to 2001:dc3::35 (2001:dc3::35) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.376 ms 0.356 ms 0.333 ms 2 at-0-0-1.schiphol-rijk.ipv6.concepts-ict.net (2001:838:0:12::1) 3.918 ms 3.907 ms 3.895 ms 3 ge-1-0-0.nikhef.ipv6.concepts-ict.net (2001:838:0:11::1) 4.629 ms 4.533 ms 4.52 ms 4 eth10-0-0.xr1.ams1.gblx.net (2001:7f8:1::a500:3549:1) 7.297 ms 5.652 ms 4.703 ms 5 2001:450:1:1::22 (2001:450:1:1::22) 160.476 ms * 160.764 ms 6 3ffe:80a::10 (3ffe:80a::10) 155.729 ms 155.724 ms 155.655 ms 7 3ffe:80a::2 (3ffe:80a::2) 154.208 ms 153.992 ms 153.945 ms 8 otm6-bb1.IIJ.Net (2001:240:100:ffff::ff) 285.941 ms otm6-bb0.IIJ.Net (2001:240:100:fffe::ff) 286.119 ms 286.328 ms 9 tky001ix06.IIJ.Net (2001:240:100:2::30) 286.458 ms tky001ix06.IIJ.Net (2001:240:100:1::30) 286.441 ms otm6-gate0.IIJ.Net (2001:240:100::204) 286.345 ms 10 2001:200:0:1800::1d4c:3 (2001:200:0:1800::1d4c:3) 287.073 ms 287.17 ms 287.266 ms 11 2001:dc3::35 (2001:dc3::35) 287.178 ms 287.018 ms 287.981 ms
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-07-21, at 10.33, Jeroen Massar wrote:
BTW that list is missing i.root-servers.org which is located in Sweden, but that is a testing address and routes over the US instead of staying inside Europe...
Yes, you can try out 2001:7fe::53 for i.root-servers.net. We have this week ben busy working on the Ipv6 network and we are trying to get stable connectivity to i.root. As of today you should see a somewhat shorter path to i.root. We are also bringing up more peerings that will hopefully help to cut down latency. Feel free to use the address above, but please note that it's not listed publicly for a reason (although we appreciate any outage reports to dns-noc@netnod.se). - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQP46gaarNKXTPFCVEQJATQCfWu8xg2AtkkDm83Et5Bzto387A4sAmgJK 9Fw6EXLK2/U//xR5AVFUHkhI =UMXv -----END PGP SIGNATURE-----
On Wed, 2004-07-21 at 11:42, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2004-07-21, at 10.33, Jeroen Massar wrote:
BTW that list is missing i.root-servers.org which is located in Sweden, but that is a testing address and routes over the US instead of staying inside Europe...
Yes, you can try out 2001:7fe::53 for i.root-servers.net. We have this week ben busy working on the Ipv6 network and we are trying to get stable connectivity to i.root. As of today you should see a somewhat shorter path to i.root. We are also bringing up more peerings that will hopefully help to cut down latency.
Feel free to use the address above, but please note that it's not listed publicly for a reason (although we appreciate any outage reports to dns-noc@netnod.se).
Indeed, I know see various paths coming in over AORTA (Chello) etc. That is starting to become better. The roundtrip-paths are async over the US still though :( I've passed the above on to some other IPv6 routing fora maybe that should get some attention. Greets, Jeroen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
BTW that list is missing i.root-servers.org which is located in Sweden, but that is a testing address and routes over the US instead of staying inside Europe...
Yes, you can try out 2001:7fe::53 for i.root-servers.net. We have this week ben busy working on the Ipv6 network and we are trying to get stable connectivity to i.root. As of today you should see a somewhat shorter path to i.root. We are also bringing up more peerings that will hopefully help to cut down latency.
Feel free to use the address above, but please note that it's not listed publicly for a reason (although we appreciate any outage reports to dns-noc@netnod.se).
Indeed, I know see various paths coming in over AORTA (Chello) etc. That is starting to become better. The roundtrip-paths are async over the US still though :(
I've passed the above on to some other IPv6 routing fora maybe that should get some attention.
(this is getting seriously off-topic) What I did notice today, while doing some work on the routing, is that BGP changes seems to take forever to propagate through the IPv6 routing table. A change that to our direct peers lasted less than 5 minutes, lead to down-time of around 20 minutes for a host in the US. Wired. As for the paths, we should have more peers up by the end of the week. If you are an ISP, and your are present at Netnod, and you would like to investigate IPv6 peering with the root-server, send a mail to peering@netnod.se. I was almost going to offer tunnels with BGP over them to anyone, but I realized I would never be able to migrate away from that swap so I won't :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQP5Pt6arNKXTPFCVEQIN5gCg1ls4DWw+OzoNhuTk755oeAURqo8An2VX Tix22ttp2f8UTyVCkRy8CIRs =Z51y -----END PGP SIGNATURE-----
On 21 Jul 2004, at 15:33, Jeroen Massar wrote:
F.root-servers.org:
traceroute to 2001:500::1035 (2001:500::1035) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.385 ms 0.35 ms 0.341 ms
[etc] We are trying hard to make F available from our anycast nodes on its IPv6 address. Finding exchange points which (a) will give you v6 addresses and (b) have peers which will peer with you over IPv6 is not trivial, however.
H.root-servers.org:
traceroute to 2001:500:1::803f:235 (2001:500:1::803f:235) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.386 ms !H 0.347 ms !H 0.349 ms !H
Which gets announced as a /48 thus doesn't come through the filters...
If that doesn't make it through your filters, then your filters are broken. 2001:500:1::/48 is an ARIN micro-allocation, and it is perfectly legitimate to advertise it with no covering /32 supernet. Incidentally, F is also announced as a /48, and is also an ARIN micro allocation (the first one they made, in fact). 2001:500::/48 seems to get through your filters ok. Joe
No, Peter was talking about root name servers, nothing changed for the
At least this Peter wasn't. I talked about the root *zone*. The press article was "interesting", but thanks for the pointer to the ICANN website. Missed that while looking at IANA's where the new policy document was referenced, which (i.e. our discussion of that document) was the reason to point to its implementation. -Peter
On 21 Jul 2004, at 14:47, Stephane Bortzmeyer wrote:
Wrong, several root name servers (of course, not ICANN's one) are reachable over IPv6: read http://www.root-servers.org/ and edit your db.root.
With BIND, the hints file is used to bootstrap a nameserver such that it can find answers to the question "dig . NS", with attendant glue. Once such an answer has been received, the hints file is not used any more. So editing the hints file to include AAAA records might cause the first query a recursive nameserver makes after boot to be carried over IPv6, but until there are AAAA records in the root zone, all subsequent queries to the root will be sent over IPv4. It would be interesting to know what a recursive nameserver with AAAA records added to its hints file and no IPv4 transit would do, after it got an answer with no IPv6 glue from a root nameserver, though. I haven't tried it. Joe
[ note: aggregated mails ;) ] On Wed, 2004-07-21 at 14:57, Joe Abley wrote:
On 21 Jul 2004, at 14:47, Stephane Bortzmeyer wrote:
Wrong, several root name servers (of course, not ICANN's one) are reachable over IPv6: read http://www.root-servers.org/ and edit your db.root.
With BIND, the hints file is used to bootstrap a nameserver such that it can find answers to the question "dig . NS", with attendant glue. Once such an answer has been received, the hints file is not used any more.
Remove the hints and 'load' your roots as a master, that is the trick I employ when I want to use alternate roots. Bind will complain but won't dig ;) Dirty trick and indeed as you mentioned the AAAA's should be in the root (.) otherwise everybody will have to do this dirtywork. <SNIP>
It would be interesting to know what a recursive nameserver with AAAA records added to its hints file and no IPv4 transit would do, after it got an answer with no IPv6 glue from a root nameserver, though. I haven't tried it.
It throws away your hints information thus basically it is left dead on the street... On Wed, 2004-07-21 at 15:02, Joe Abley wrote:
On 21 Jul 2004, at 15:33, Jeroen Massar wrote:
F.root-servers.org:
traceroute to 2001:500::1035 (2001:500::1035) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.385 ms 0.35 ms 0.341 ms
[etc]
We are trying hard to make F available from our anycast nodes on its IPv6 address. Finding exchange points which (a) will give you v6 addresses and (b) have peers which will peer with you over IPv6 is not trivial, however.
Then I should advise you to come to the AMS-IX, there is no F there and it should not be hard to get IPv6 from the IX nor transit nor peers. Just give them a shout and I am sure people are willing to help out.
H.root-servers.org:
traceroute to 2001:500:1::803f:235 (2001:500:1::803f:235) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.386 ms !H 0.347 ms !H 0.349 ms !H
Which gets announced as a /48 thus doesn't come through the filters...
If that doesn't make it through your filters, then your filters are broken. 2001:500:1::/48 is an ARIN micro-allocation, and it is perfectly legitimate to advertise it with no covering /32 supernet.
Incidentally, F is also announced as a /48, and is also an ARIN micro allocation (the first one they made, in fact). 2001:500::/48 seems to get through your filters ok.
This is indeed something odd, as can be seen in GRH* most ISP's get it and indeed the 2001:500:1::/48 doesn't get trough, I've taken it up with AS12871 who provide the connectivity for that machine and they control the filters not me ;) * = http://www.sixxs.net/tools/grh/lg/?find=2001:500::/32 Greets, Jeroen
On 21 Jul, 2004, at 18:03, Jeroen Massar wrote:
We are trying hard to make F available from our anycast nodes on its IPv6 address. Finding exchange points which (a) will give you v6 addresses and (b) have peers which will peer with you over IPv6 is not trivial, however.
Then I should advise you to come to the AMS-IX, there is no F there and it should not be hard to get IPv6 from the IX nor transit nor peers. Just give them a shout and I am sure people are willing to help out.
F has v6 enabled for peerings at several exchanges, for instance at the SFINX in Paris, the GigaPIX in Lisbon and the Namex in Rome. We will turn it on in any other anycast location where the exchange supports IPv6 traffic directly and there are peers to peer with. We would love to be at the AMSIX but would need some sort of local sponsor for that, perhaps the AMSIX itself. I shall ask them. Of course, F's global nodes also announce the IPv6 prefix to their IPv6 peers. Joao
On Thu, 2004-07-22 at 11:36, Joao Damas wrote:
On 21 Jul, 2004, at 18:03, Jeroen Massar wrote:
We are trying hard to make F available from our anycast nodes on its IPv6 address. Finding exchange points which (a) will give you v6 addresses and (b) have peers which will peer with you over IPv6 is not trivial, however.
Then I should advise you to come to the AMS-IX, there is no F there and it should not be hard to get IPv6 from the IX nor transit nor peers. Just give them a shout and I am sure people are willing to help out.
F has v6 enabled for peerings at several exchanges, for instance at the SFINX in Paris, the GigaPIX in Lisbon and the Namex in Rome. We will turn it on in any other anycast location where the exchange supports IPv6 traffic directly and there are peers to peer with.
As can be seen under f.root-servers.net at the following url (use "IPv6 well known destinations"): http://www.sixxs.net/misc/latency/latency/ F is at about 100ms in IPv6 for most destinations, ~3ms from ptlis01 though. Then again if I look at f.root-servers.net over IPv4 in that same graph the average is ~150ms... hmmm IPv6 is better as IPv4? :)
We would love to be at the AMSIX but would need some sort of local sponsor for that, perhaps the AMSIX itself. I shall ask them.
See the off-list message for an offer from someone. Greets, Jeroen
On Wed, Jul 21, 2004 at 09:16:46AM +0200, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote a message of 12 lines which said:
Haven't seen an announcement right here, so FYI:
I do not know if this counts as an announcement:
http://www.reuters.com/newsArticle.jhtml?type=internetNews&storyID=5717373
The official one, better technically :-) http://www.icann.org/announcements/announcement-20jul04.htm
On 21.07 09:57, Stephane Bortzmeyer wrote:
The official one, better technically :-)
Isn't that lovely? So this was really and wholly an ICANN achievement? I hate announcmenets by bureaucrats about "their" achievements when their main contribution really is to introduce unnecessary friction, entropy and delay. Don't get me wrong: changes to root zone management require process. I am arguing *for* giving the IANA more discretion in timely operational matters, like part of the new procedure does. I just wish that both IANA and ICANN will increase the effectiveness of their processes and be *much* more humble about their role and contributions. Anyway: I am happy this has finally happened! Daniel
On Wed, Jul 21, 2004 at 09:16:46AM +0200, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote a message of 12 lines which said:
Do note that the IPv6 server of ".fr", requested in February 2003, is still not announced.
Done this night. ~ % dig @k.root-servers.net NS fr. ; <<>> DiG 9.2.4rc5 <<>> @k.root-servers.net NS fr. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10236 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9 ;; QUESTION SECTION: ;fr. IN NS ;; AUTHORITY SECTION: fr. 172800 IN NS dns.cs.wisc.edu. fr. 172800 IN NS ns1.nic.fr. fr. 172800 IN NS dns.inria.fr. fr. 172800 IN NS ns2.nic.fr. fr. 172800 IN NS dns.princeton.edu. fr. 172800 IN NS ns-ext.vix.com. fr. 172800 IN NS ns3.domain-registry.nl. fr. 172800 IN NS c.nic.fr. ;; ADDITIONAL SECTION: dns.cs.wisc.edu. 172800 IN A 128.105.2.10 ns1.nic.fr. 172800 IN A 192.93.0.1 dns.inria.fr. 172800 IN A 193.51.208.13 ns2.nic.fr. 172800 IN A 192.93.0.4 dns.princeton.edu. 172800 IN A 128.112.129.15 ns-ext.vix.com. 172800 IN A 204.152.184.64 ns3.domain-registry.nl. 172800 IN A 193.176.144.6 c.nic.fr. 172800 IN A 192.134.0.49 c.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1 ;; Query time: 16 msec ;; SERVER: 193.0.14.129#53(k.root-servers.net) ;; WHEN: Thu Jul 22 09:38:44 2004 ;; MSG SIZE rcvd: 377
On Thu, 2004-07-22 at 09:38, Stephane Bortzmeyer wrote:
On Wed, Jul 21, 2004 at 09:16:46AM +0200, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote a message of 12 lines which said:
Do note that the IPv6 server of ".fr", requested in February 2003, is still not announced.
Done this night.
Congratulations! Your hard fighting finally worked out ;) Now pray for .de Btw, is there a list of TLD's which support IPv6, transport and NS glue. Of course with a pointer where to request it ;) I hope to see it soon for .com/net/org and .ch + .nl too... Greets, Jeroen
On Thu, Jul 22, 2004 at 09:47:04AM +0200, Jeroen Massar <jeroen@unfix.org> wrote a message of 42 lines which said:
Now pray for .de
They made a formal request? When? Ours took 17 months to proceed.
On 22.07 09:57, Stephane Bortzmeyer wrote:
They made a formal request? When? Ours took 17 months to proceed.
Now that IANA *finally* have the rpocedure in place this should be much quicker. Daniel
On Thu, Jul 22, 2004 at 09:47:04AM +0200, Jeroen Massar <jeroen@unfix.org> wrote a message of 42 lines which said:
Btw, is there a list of TLD's which support IPv6, transport and NS glue.
Using only nameservers whose name is in the TLD (otherwise ns.ripe.net would give the impression of wide IPv6 adoption), twelve TLDs, all of them ccTLDs: CH: domreg.nic.CH. (2001:620:0:3:a00:20ff:fe85:9276) merapi.switch.CH. (2001:620::5) merapi.switch.CH. (2001:620:0:1:a00:20ff:fe88:a3f8) DE: a.nic.DE. (2001:608:6::5) EE: dns.estpak.EE. (2001:7d0:0:e010::1) FR: c.nic.FR. (2001:660:3006:1::1:1) IR: ns.nic.IR. (2001:960:618:70::89) persia.nic.IR. (2001:960:618:70::84) IT: dns.nic.IT. (2001:760:600:1::5) JP: d.dns.JP. (2001:240::53) e.dns.JP. (2001:200:0:1::4) a.dns.JP. (2001:dc4::1) f.dns.JP. (2001:2f8:0:100::153) KR: g.dns.KR. (2001:dc5:a::1) PT: ns2.dns.PT. (2001:690:a80:4001::100) SE: g.ns.SE. (2001:6b0:8:1::53) f.ns.SE. (2001:6b0:7::53) TN: ns.ati.TN. (2001:970:1:1::10) TW: a.dns.TW. (2001:cd8:800::8) c.dns.TW. (2001:238:800:1::1) d.dns.TW. (2001:c50:ffff:1::230)
Of course with a pointer where to request it ;)
Attached.
Yes, we are happy to announce about this: http://jprs.jp/en/press/20040721-e.html -- Yasuhiro 'Orange' Morishita DNS Technical Engineer Research and Development department, Japan Registry Service Co.,Ltd. (JPRS) E-Mail: yasuhiro@jprs.co.jp / orange@jprs.co.jp
Haven't seen an announcement right here, so FYI:
as of SOA# 2004072000 the following AAAA RRs (aka "IPv6 glue") are available from within the root zone:
A.DNS.JP. AAAA 2001:DC4:0:0:0:0:0:1 D.DNS.JP. AAAA 2001:240:0:0:0:0:0:53 E.DNS.JP. AAAA 2001:200:0:1:0:0:0:4 F.DNS.JP. AAAA 2001:2F8:0:100:0:0:0:153
G.DNS.KR. AAAA 2001:DC5:A:0:0:0:0:1
-Peter
participants (8)
-
Daniel Karrenberg -
Jeroen Massar -
Joao Damas -
Joe Abley -
Kurt Erik Lindqvist -
Peter Koch -
Stephane Bortzmeyer -
Yasuhiro Orange Morishita / 森下泰宏