On Wed, Jun 10, 2020 at 8:33 AM John R Levine <[email protected]> wrote:
> >> That sounds quite painful for servers that serve hundreds or > >> thousands of zones. > > I think this will work for NS with names in the zone. Still scratching my > head about NS in other zones. > So, this seems to be failing to converge on the obvious aspects of all of this, particularly scalability and TLS session persistence. Use the NS name on the delegation (which is unsigned), assume that NS name has not been altered in transit, and make a TLS connection to that NS (which hosts the domain the client wants to query.) If that NS name is in a domain protected with DNSSEC, its TLSA record can be trusted after validation. At that point, it is then safe to do the TLS-protected query for the target DNS information. Doing things this way means resolvers can leverage persistent TLS connections to the large providers' name servers (to make queries for all the domains that share an NS), which is a win-win between the resolvers and auth operators. (Persistent TLS >> individual TLS connections per query. Or at least resuming TLS connections versus new TLS set-up.) However, the first step has a problem: Without a secure way of obtaining the first element (the unsigned NS name being used), the only way to confirm the authenticity of that NS name, is to make a TLS connection to the name server, and getting the apex NS records for the target zone. 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. (The other method that comes to mind, is obtaining the delegation zone itself, e.g. via AXFR, with some method of protecting the data integrity, such as TSIG, or ZONEMD.) 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 best practice for large providers will likely be to have glueless delegations for the domain(s) under which these NS names reside, and possibly having the nameserver names for the domains serving those names, themselves be glueless (indirectly glued). I.e. the intersection set of NS values used for the served domains of customers, and the NS values used for the domains used by the operators, under best practice should be the empty set, so no glue is needed for customer domains. But TL;DR: big providers will want to only use TLSA records for their NS names, not for their client's, and generally are very unlikely to offer the ability for clients to use "vanity" name server names for the IP addresses of their name servers. (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.) Unsigned NS records for the delegation are a huge problem in the architecture of DNSSEC, and consequently also for TLS (regardless of whether TLSA or WebPKI is used -- the problem is the name itself which is not cryptographically protected.) DoTA or AXFR (with TSIG or ZONEMD) or other ways of obtaining the unsigned NS values in such a way as to protect the data integrity are the only available fix currently. The long term ideal solution would be to fix the DNSSEC (and possibly DNS) design, but I don't see that as happening any time soon. Brian P.S. This is a general observation, not an assertion of a position of a particular operators' practice per se.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
