Leverage DNSSEC for resolver validation

[simonclausen]

So I've had this floating around my mind for quite some time, but have never gotten around to thinking it through or doing a design suggestion. And probably won't for some time, so here's a bunch of notes to get started.

This starts with something you can't really get around, when you want to add a secure layer on anything:

• It is more complex to start using a DNSCrypt enabled resolver than a traditional DNS server, because you need more info than an IP to validate
• Distribution of the DNSCrypt resolver credentials needs to be done in a trusted and secure way

Right now this is, in part, solved by having an authoritative list of DNSCrypt resolvers on GitHub, with changes happening through pull requests.

Users are also free to use servers outside this list by supplying the needed info to the DNSCrypt client manually. In this case it is entirely up to the user to figure out to make sure the info they got has not been altered during transport.

This issue is also widely solved by using PKI and CA's, which the authoritative is self bases it self upon (GitHub has been validated by a CA, etc, etc).

Perceived issues:

• The GitHub list is centralized, which causes us to rely on e.g. GitHub being up, @jedisct1 being alive, having time to process pull requests, and alike
• As the list grows it can become quite a big job to keep track of pull request for changes being valid
• Clients require a mechanism to pull changes from the list, this with a built in lag depending on the frequency of polling: it shouldn't happen often, but what if a provider key needs to be changed out due for whatever reason?
• If you don't want to use the list you have to trust the e.g. the HTTPS transport of "some site", an email, be able to validate GPG signatures, etc, to get information on resolvers

So what if we could get around all of this?

The rough idea:

• The client is supplied with the IP of the DNSCrypt resolver
• Client send a regular DNS request for the PTR record of the resolver
• The resolver replies with it's service name, "resolver.service.com" for instance
• The client then constructs and sends regular DNS requests for A and TXT records for relevant info, and this time does DNSSEC validation of the replies
  • resolver.service.com A
  • pubkey.resolver.service.com TXT
  • name.resolver.service.com TXT
  • and any other info wanted and defined in the protocol
• Client now has all the needed info, has validated it via DNS/DNSSEC and can start using the resolver via DNSCrypt

What do you think?

[simonclausen]

Forgot a couple of points:

• The resolver would be able to only reply on queries relevant to it self and blocking everything else,
• alternatively it can operate in hybrid mode allowing both regular DNS and DNSCrypt
• The client can detect if a resolver is dnscrypt capable by looking for a DNS record on the resolver name, i.e. dnscrypt.resolver.service.com TXT: this could make a OS implementation capable of opportunistic DNS security based on the capability of the resolver it gets handed to it, also making migration to DNSCrypt and backwards compatibility less of an issue