Re: [dns-privacy] bootstrapping NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[John Levine <[e-mail]>]

In article <CAH1iCir5KaEr6JU5exF7VRQ2yYe6xZ-cLmwmXg3yM=[e-mail]> you write:
>That leaks information to an attacker ONLY if the attacker has successfully
>caused the resolver to get the wrong NS name at the first step.
>
>There is a method for preventing that: if the delegating name server (e.g.
>TLD) supports DNS-over-TLS-to-Authority (DoTA), and the resolver obtains
>the unsigned NS over a TLS connection. ...

Right.  We have to bootstrap somehow and this seems about as good as we can ask for.

>The details involved in getting the TLSA record for the NS name are left as
>an exercise for the reader (but are easy enough to figure out, they're
>literally an exercise in 4033/4034/4035.)

The principle is easy. What's hard is the Provisioning Crudware(TM)
that will have to be updated to handle TLSA glue. You might see this
as a dealbreaker, with the alternative being to abuse DS or some other
record that we hope the Crudware already handles.

>(The reason for this is mostly about how EPP handles host records needed
>for maintaining TLD glue, and scalability of management of all of that.)

See above.  It's not just EPP, it's the provisioning system for any DNS server
that delegates a subtree to another server.

R's,
John