[Yeti DNS Discuss] Yeti Root Server Glue

Paul Vixie paul at redbarn.org
Sun May 24 19:16:03 UTC 2015



Shane Kerr wrote:
> All,
> ...
> Once we figure out what we are going to do, I think it makes sense to
> document this on the Yeti site.

indeed, this may qualify as the project's first finding. my comments below:

> 2. Patch BIND 9 so that it includes the glue addresses in the
>    additional section, or so that it can be configured to respond this
>    way.


this is what we should do. bind9 is simply wrong in this case, since
it's necessary glue.

>    Requiring a special, patched version of BIND 9 is probably even
>    worse than not supporting it at all. (It might be possible to get
>    this sort of change included in upstream BIND 9, but given the use
>    case is so narrow I suspect that it would be rejected.)

mark andrews will likely agree, and the patch would be on a faster cycle
for that reason.


> 3. Add a zone file for each root server and answer for all of them at
>    each Yeti server.

this should not be done, because it won't scale, and would lead us to
conclude that...

> 4. Make a domain similar to "root-servers.net" and put all of the Yeti
>    servers in that (like "root-servers.yeti.org" or similar).

...that the IANA approach is somehow correct, which it is not. we should
not constrain our design to what works with current software, since our
goal is to determine how the system, and its software, should work in
the future.

we have a fifth alternative here, which is to put all of the root server
names inside the root zone itself. i am very interested in this
approach, since rssac-caucus is now starting work on analyzing this
approach, and we could help inform that discussion by our work here.
briefly, we would have to create a top level name (which is a policy
violation, so, would require study) called "yeti-root" or similar. this
would not be a delegation point. we would assign names under this
top-level, such as tisf.yeti-root, wide.yeti-root, bii.yeti-root, and so
on. these would be added by the distribution masters after stripping the
IANA apex NS RRset and while adding our own apex NS RRset. thus the glue
would move to be in-zone, and it would be signed with the yeti DNSSEC key.

i think we should explore #5 and #2 in parallel, and that we should be
certain to use both during the three-year expected duration of the
yeti-dns project.

-- 
Paul Vixie


More information about the discuss mailing list