This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/dns-wg@ripe.net/
[dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
- Previous message (by thread): [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
- Next message (by thread): [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at unfix.org
Wed Jul 21 18:03:11 CEST 2004
[ 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: </ripe/mail/archives/dns-wg/attachments/20040721/b0737bf4/attachment.sig>
- Previous message (by thread): [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
- Next message (by thread): [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]