Re: (ngtrans) Re: IPv6 dns

["Cricket Liu" <Cricket@verisign.com>]

> % regarding the new root servers which respond to queries over IPv6 -
> % one thing you didn't quite mention, but I suspect is necessary, is
> % that their IPv6 addresses be stable. that is, that once root
> % servers are established at these addresses and are advertised,
> % that there will continue to be authoritative root servers at
> % those addresses for the forseeable future.
> %
> % this has implications for the roots; but perhaps also, for their
> % ISPs and for address assignment in general.  regardless of what
> % assumptions we make about IPv6 renumbering elsewhere, we don't
> % want to renumber the root servers very often.
>
> The stablitity of the addressing plan for a root structure was delt with
> about 5 years ago. THe cache usued to have TTL values of all nines, e.g.
> never expire. This effects how persistant any specific address has to be
> in the root cache. The values were changed to a week, forcing cahce aging
to
> occur.

More significantly, BIND's behavior changed and BIND began sending
system queries to get a "live" set of root NS RRs rather than using the
NS RRs in the root hints file.  The records in the root hints file just help
BIND find a name server to send the system query to.

(The current TTL on the root name servers' A RRs is 41 days, 16
hours.  If that's an implication of the stability of those addresses, I'd
say they're fairly stable.)

Regarding this proposed "reply with A6/AAAA RRs only if queried
over IPv6" suggestion:  Even if we imagine this enhancement patched
in to BIND 9.1.0 and deployed on the root name servers, how are we
going to prevent non-root name servers from redistributing the
A6/AAAA RRs?  For example, if my dual-homed IPv4 and IPv6
name server gets A6 RRs in response to its system query and caches
those, but lacks the patch, it'll respond with those A6 RRs to:

1.  Any name server that sends it a system query (because it's
misconfigured to think my dual-homed name server is a root name
server, for example).

2.  Any name server that sends it a query for a domain name
in a zone that it's lame for, assuming my dual-homed name
server can't find a set of enclosing NS RRs "closer" than the
root.

In case 2, a newer name server that received the response wouldn't
cache the RRs because of credibility, but an older BIND name
server would.

I'm pointing this out not because I'm sure that advertising A6 RRs
is a problem--I think the biggest problem may be inducing TCP
retries because of truncation--but because I've found it's really
difficult to "compartmentalize" cached RRs and therefore we
shouldn't count on being able to protect all of the Internet's name
servers from AAAA and A6 with a clever hack.

cricket