Re:Statement on DNS Encryption [pdf]
by schoen on Wednesday April 21, 2021 @06:25PM
(#26896212)
To clarify a bit:
The root servers already use DNSSEC (which is not DNS query encryption). Try
$ dig rrsig . @c.root-servers.net
if you want to check this. (I chose c-root just for fun.)
DNS query encryption has become a more and more popular idea because of things like spy agencies conducting surveillance of DNS queries for espionage purposes, ISPs collecting them for commercial purposes, and network censors using them for site blocking. If you can query resolvers in an encrypted way that the network can't see, you can make it less likely that they will know what sites you visit or be able to block particular ones (especially in certain cases where an adversary is on-path for DNS queries but not for the resulting HTTP connection, which is not always true but is sometimes true).
This letter seems to respond to suggestions that the root servers ought to enable a query encryption mechanism of some sort so that you could query them without revealing (to the network) what the content of the query was. This is of varying interest and relevance depending on your threat model (and who and where your recursive resolver is), but it could be important in some threat models.
The letter basically argues that it isn't really necessary for the root servers to do this, because (1) in principle the information they serve isn't that sensitive (and even the fact that someone is interested in a particular part of it might not be that sensitive), (2) other people are in a position to mitigate the privacy issues, and (3) other people can reasonably do this right away without requiring the root servers to change anything.
The QNAME minimization thing in particular is like: if you want to look up the IP address of controversialsite.example.com, this might end up generating a query "IN A controversialsite.example.com." (and/or "IN NS controversialsite.example.com.", "IN SOA controversialsite.example.com.") that goes unencrypted from you/your network/your recursive resolver to the root servers. But this is unnecessary. Instead, this query could ask just for "IN NS com." to the root servers, and neither the root server operators, nor your ISP, nor governments tapping Internet backbones, will know that you were interested in com because of a lookup for controversialsite.example.com as opposed to google.com. (The TLD servers such as gtld-servers.net would still need to offer query encryption in this case.)
A further argument made by the root server operators is that recursive resolvers can do better caching to make it much less likely that they'll need to query the root servers directly for the huge majority of individual queries that are sent to the recursive resolver.
The root servers already use DNSSEC (which is not DNS query encryption). Try
$ dig rrsig . @c.root-servers.net
if you want to check this. (I chose c-root just for fun.)
DNS query encryption has become a more and more popular idea because of things like spy agencies conducting surveillance of DNS queries for espionage purposes, ISPs collecting them for commercial purposes, and network censors using them for site blocking. If you can query resolvers in an encrypted way that the network can't see, you can make it less likely that they will know what sites you visit or be able to block particular ones (especially in certain cases where an adversary is on-path for DNS queries but not for the resulting HTTP connection, which is not always true but is sometimes true).
This letter seems to respond to suggestions that the root servers ought to enable a query encryption mechanism of some sort so that you could query them without revealing (to the network) what the content of the query was. This is of varying interest and relevance depending on your threat model (and who and where your recursive resolver is), but it could be important in some threat models.
The letter basically argues that it isn't really necessary for the root servers to do this, because (1) in principle the information they serve isn't that sensitive (and even the fact that someone is interested in a particular part of it might not be that sensitive), (2) other people are in a position to mitigate the privacy issues, and (3) other people can reasonably do this right away without requiring the root servers to change anything.
The QNAME minimization thing in particular is like: if you want to look up the IP address of controversialsite.example.com, this might end up generating a query "IN A controversialsite.example.com." (and/or "IN NS controversialsite.example.com.", "IN SOA controversialsite.example.com.") that goes unencrypted from you/your network/your recursive resolver to the root servers. But this is unnecessary. Instead, this query could ask just for "IN NS com." to the root servers, and neither the root server operators, nor your ISP, nor governments tapping Internet backbones, will know that you were interested in com because of a lookup for controversialsite.example.com as opposed to google.com. (The TLD servers such as gtld-servers.net would still need to offer query encryption in this case.)
A further argument made by the root server operators is that recursive resolvers can do better caching to make it much less likely that they'll need to query the root servers directly for the huge majority of individual queries that are sent to the recursive resolver.