DNS |
Sponsored by |
Unlike most new IETF standards, DNS over HTTPS has been a magnet for controversy since the DoH working group was chartered on 2017. The proposed standard was intended to improve the performance of address resolutions while also improving their privacy and integrity, but it's unclear that it accomplishes these goals. On the performance front, testing indicates DoH is faster than one of the alternatives, DNS over TLS (DoT).
The design of DNS included an important architectural decision: the transport protocol used is user datagram protocol (UDP). Unlike transmission control protocol (TCP), UDP is connectionless, stateless, and lightweight. In contrast, TCP needs to establish connections between end systems and guarantees packet ordering and delivery. DNS handles the packet delivery reliability aspect internally and avoids all of the overhead of TCP. There are two problems this introduces.
As part of a larger effort to make the internet more private, the IETF defined two protocols to encrypt DNS queries between clients (stub resolvers) and resolvers: DNS over TLS in RFC 7858 (DoT) and DNS over HTTPS in RFC 8484 (DoH). As with all new internet protocols, DoT and DoH will continue to evolve as deployment experience is gained, and they're applied to more use cases.
DNSSEC is increasingly adopted by organizations to protect DNS data and prevent DNS attacks like DNS spoofing and DNS cache poisoning. At the same time, more DNS deployments are using proprietary DNS features like geo-routing or load balancing, which require special configuration to support using DNSSEC. When these requirements intersect with multiple DNS providers, the system breaks down.
Privacy problems are an area of wide concern for individual users of the Internet -- but what about network operators? Geoff Huston wrote an article earlier this year concerning privacy in DNS and the various attempts to make DNS private on the part of the IETF -- the result can be summarized with this long, but entertaining, quote.
At the Internet Engineering Task Force (IETF) it is time we accept the wide range of drivers behind (and implications of) standards and for stakeholders to start listening to each other. A protocol recently released by the IETF, DNS over HTTPS (DoH), is at the centre of an increasingly polarised debate. This is because DoH uses encryption in the name of security and privacy and re-locates DNS resolution to the application layer of the Internet.
Wikipedia defines a Mexican standoff as "a confrontation in which no strategy exists that allows any party to achieve victory. As a result, all participants need to maintain the strategic tension, which remains unresolved until some outside event makes it possible to resolve it." This would be an apt way to describe what may be possibly occurring presently between the Internet Corporation for Assigned Names and Numbers (ICANN) and its largest ratepayer, VeriSign.
It wasn't that long ago that, during a visit home, my brother asked me, "Why are you so stuck on this Internet thing?" His direct question caused me to realize that I had never actually stopped and considered why I was investing so much time – and in such a highly visible manner – into Internet governance when I wasn't being compensated for doing so and, in fact, was – not putting too fine of a point on it – flat broke.
The ICANN Security and Stability Advisory Committee (SSAC) has recently published SAC105, a report on the interplay between the DNS and the Internet of Things (IoT). Unlike typical SSAC publications, SAC105 does not provide particular recommendations to the ICANN Board, but instead is informative in nature and intends to trigger and facilitate dialogue in the broader ICANN community.
This past Monday, as ICANN65 was beginning in Marrakesh, the technical review blog Review Signal published a detailed expose, "The Case for Regulatory Capture of ICANN" authored by site founder and "geek-in-charge" Kevin Ohashi. The post was clearly the product of extensive investigative reporting – and what it reveals is deeply disturbing.