In article <CAH1iCir5KaEr6JU5exF7VRQ2yYe6xZ-cLmwmXg3yM=eac7d...@mail.gmail.com> 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 _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
