[dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone

[ 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>