[HN Gopher] Statement on DNS Encryption [pdf]
___________________________________________________________________
Statement on DNS Encryption [pdf]
Author : moviuro
Score : 59 points
Date : 2021-04-21 16:55 UTC (6 hours ago)
(HTM) web link (root-servers.org)
(TXT) w3m dump (root-servers.org)
| Panino wrote:
| In case it isn't clear from reading the article PDF or this HN
| thread, DNSSEC doesn't encrypt DNS. If you want encrypted DNS,
| DNSSEC isn't the answer, because DNSSEC doesn't encrypt DNS. The
| main thing DNSSEC does is create outages.
| schoen wrote:
| 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.
| throwaway823882 wrote:
| It would be great if we could solve the problem by backing up and
| addressing a few preliminary things first. Like, DNS is a very
| old protocol, and it's a good protocol. But will we keep using it
| this way 100 years from now? It may be counter-productive to only
| focus on backwards-compatible fixes.
|
| Domain registration and name serving are pretty similar, yet we
| treat them very differently. For both security reasons and
| functional reasons, it would be nice if we had one unified way to
| manage them both.
|
| Other services depend greatly on DNS names, like PKI. It would be
| very advantageous, again for security and functional reasons, if
| there were better (not necessarily tighter, but better)
| integration between the two.
|
| Secure connections all pretty much share the same properties.
| Virtually every system you can think of can be thought of as one
| that (at some point) requires authentication, authorization,
| encryption, and data integrity. So, perhaps there is a unified
| way we can provide all of this, the same way TCP and UDP provide
| a unified way of transporting either streams or datagrams. Maybe
| even making them OS primitives the way the TCP/IP stack is today
| [didn't used to be!].
|
| If we step back and start from first principles, and design
| protocols that provide all the functionality we know we need (now
| and in the future), we could start getting ready for computing in
| the next century and beyond. It doesn't have to be a pipe dream,
| especially if we start building support for experimental
| protocols into devices today.
| bombcar wrote:
| Given the amount of crap traffic the root servers get I can see
| why they'd be hesitant to just turn on DNSSEC. "Let's see you all
| stop sending us stupid shit queries first" sounds entirely
| reasonable.
| _-david-_ wrote:
| The PDF is about DNS Encryption not DNSSEC. Some (all?) of the
| root servers already support DNSSEC.
| _wldu wrote:
| Stub resolver = your client device.
| xoa wrote:
| I know DNSSEC has a ton of flaws and has received a lot of
| justified criticism. But I'd still desperately love to be able to
| have good standards in place such that my possession of a given
| domain also allows me to operate a generally recognized private
| CA off of that for said domain (as well as elimination of a
| variety of DNS attacks of course). There shouldn't need for 3rd
| parties there in principle, it should be enough to just be able
| to put up a CA root public cert up in DNS and have everything
| automagically work from there. It'd make a host of things like
| RADIUS and future enhanced distributed auth email-likes a lot
| more convenient and less fragile. I love Let's Encrypt, but it's
| a bandaid for the fundamental issues with DNS. I hope increasing
| recognition of the centrality of DNS and need for improvements
| there will ultimately result in something modern and better than
| DNSSEC that can move a lot of stuff forward.
___________________________________________________________________
(page generated 2021-04-21 23:01 UTC)