Besides DNSSEC there are also those who are still pushing DNS over SSL/TLS for www domainnames.
Forgive my obtuseness but I still do not understand.
With the availability of high speed encryption for individual DNS packets between stub resolver and authoritative nameservers with DNSCurve[FN1] why would I want to encrypt "connections" to caches with TLS? (Names in a shared cache will be deemed pseudo-authoritative because of DNSSEC? And third parties get the ability to censor any name?)
FN1. Some still doubt DNSCurve. Elsewhere in this thread someone posted a pointer to ianix.com. That site runs DNSCurve. For the doubters, here is what end-to-end encryption of DNS looks like:
# already have root.zone from ftp.internic.net so we already have addresses for tld's such as com
# resolution of ianix.com takes 2 queries (nonrecursive, RD bit unset)
# com servers are not running DNSCurve (yet) so first query is unencrypted
# however com.zone is public data that anyone can request from verisign
# thus there are ways to get ianix's authoritative nameservers w/o using DNS
DNSSEC is primarily, like TLS, about message integrity. TLS adds encryption of content so that sniffers can't read along. With DNSSEC everybody still reads along.
DNSCurve is not really deployed, thus there will always be alternatives springing up.
DNSCurve is also not end-to-end, until all authoritative servers support it.
Google has their DNS over HTTPS thing btw, which is scary but is another alternative if you want to hide what your doing (except to the server you ask questions to, but you can do that from Tor ;) ).
The best alternative you currently and for a long time will have is VPN/Tor though: get a tunnel to a host/net you trust to not betray the content of your connections (be that logging or network analysis).
Passive DNS will always exist (as it happens in the recursor, hence dnscurve does not help). And due to the caching and scalability properties of DNS it will never internally be encrypted, otherwise those two properties will be gone. The moment they are gone it won't be DNS anymore, and maybe that is a good thing and also possible in the world of today where bandwidth is less of an issue and most people use google to search for things.
Heck, google could just include the IP addresses of the servers in the HTTPS response, that way, one only needs to know where Google lives, the rest will be transported over HTTPS....
Long live that the web is not only web though. And I think there is a great future ahead for .onion-alike sites when their usability and accessibility rises as currently it is mostly BBS days: you need to know the correct number, and DNS is human readable, and Google is what most people use to find sites.
TLS is not "primarily about message integrity". To see why this isn't true, observe the targets of most (all?) of the recent TLS attacks: recovery of session tokens.
You do trust the origin site to send you to the correct next site right? :)
The big problem here is that you'll always still need DNS in a lot of cases, as webpages have long not been single-origin resources; most have to load all those tracking pages; also this would require all webpages to include that method, and also only works for web, the Internet is more than that.
I am looking forward to "DNS" pointing to more than just IPv4 and IPv6 though like in the above silly example ;)
Forgive my obtuseness but I still do not understand.
With the availability of high speed encryption for individual DNS packets between stub resolver and authoritative nameservers with DNSCurve[FN1] why would I want to encrypt "connections" to caches with TLS? (Names in a shared cache will be deemed pseudo-authoritative because of DNSSEC? And third parties get the ability to censor any name?)
https://dnsprivacy.org/wiki/x/E4AT
https://dnsprivacy.org/wiki/download/attachments/1277971/dns...
FN1. Some still doubt DNSCurve. Elsewhere in this thread someone posted a pointer to ianix.com. That site runs DNSCurve. For the doubters, here is what end-to-end encryption of DNS looks like:
# already have root.zone from ftp.internic.net so we already have addresses for tld's such as com
# resolution of ianix.com takes 2 queries (nonrecursive, RD bit unset)
# com servers are not running DNSCurve (yet) so first query is unencrypted
# however com.zone is public data that anyone can request from verisign
# thus there are ways to get ianix's authoritative nameservers w/o using DNS
# ianix.com authoritative nameservers are running DNSCurve# 2nd query is end-to-end encrypted, no third parties needed