DNS privacy requires us to make two changes to the DNS protocol.
1) The resolver is acknowledged as being a trusted service
2) Some form of crypto is added between the transport and application layer in the client-resolver protocol.
So far we seem to have focused on the second issue. But that is the easy one. There is really nothing at all special or interesting in the way TLS or DTLS or my proposal add crypto to packets. That part of the spec can be implemented in an afternoon.
The hard part is the consequences of the first issue. Whether or not we want to trust the resolver to give us the right data (integrity), privacy demands that we trust the resolver not to disclose the data (confidentiality).
Question: Is anyone proposing that we can achieve DNS privacy while maintaining the current practice of the client defaulting to the DNS server advertised in DHCP?
I don't think that is the case. But I thought best to check.
Once we decide that the client is going to have a persistent relationship with a specific DNS service we face the problem of how to establish and secure that relationship.
The main difference between my proposal and the VeriSign/USC proposal is how we go about achieving that.
We are both proposing to use TLS as a basis for this interaction. The difference being that I am proposing to use the TLS infrastructure and PKI path math once to establish a long term credential and the VeriSign proposal is to use TLS on each client-resolver interaction.
Now before making a choice between one approach or the other, I strongly recommend people look at what is being proposed in ACME. While this looks like a completely different problem (PKI credential provisioning versus service discovery), it actually isn't.
In both cases we have a hard problem and an easy problem. The easy part being the bit that is different and the hard part being how to establish and maintain the binding between the client and a trusted service.
I think that if we could factor that part out and make it a reusable component, we would be doing the IETF a big favor.
The reason I don't want to use TLS for this is that neither TLS not PKIX is a good tool for this particular job. PKIX