> I agree that DNSCurve is the best solution. I didn't say that. I believe DNSCurve and DNS-over-(D)TLS are somewhat different, and which is best depends on what you appreciate. DNS-over-(D)TLS is to me clearly the best answer for stub resolvers talking to an iterative resolver, which appears to be the focus of this WG's charter.
I'll update my position on WG adoption a bit: I support adopting DNS-over-TLS but urges the WG to adopt DNS-over-DTLS at the same time, and make consistency between them a requirement. Having both with different TLS-related security semantics would be a disaster. In fact, I would suggest that these two documents are merged into one. There is (or, rather, should be) more in common between these documents than what separates them. Alternatively, adopt one of them and come to consensus that the other one should not move forward. > Many of the proponents of TLS based solution haven't adequately > considered how this affects anycast, DOS resistance, etc. By adopting something, hopefully the WG will perform that review. There seems to be implementation interest. > Confidential-DNS can only be fixed by essentially becoming DNSCurve. A variant of DNSCurve that had crypto algorithm agility would be nice. I don't think Confidential-DNS is there yet though. > It's clear that deployed, working solutions need to be adopted. When > people say it's easy to implement DNS-over-TCP/TLS, and haven't, I > think that's a warning sign. I wouldn't say it is easy (the complexity of TLS is significant both from a protocol and implementation point-of-view), however implementation seems to be in progress. /Simon
pgpc1unVZnqJI.pgp
Description: OpenPGP digital signatur
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
