|
I don’t normally make an effort to attend the Internet Governance Forum gatherings these days. It seems to me that this forum continues to struggle for relevance. In my view, it has never been able to realize an effective engagement with the set of actors who make up the supply side of the Internet environment, and it has never pretended to take on the role of advocacy for consumers and end users. At the same time, it hasn’t been able to engage in the broader geopolitical issues that lurk just below the surface. If you are looking for answers to the question of how we can resolve the issue of today’s digital behemoths and their overarching control of much of the digital ecosystem, then the IGF really is not all that helpful for your quest.
I wrote about this back in 2018 when musing on the topic: “Has Internet Governance become Irrelevant?” and, if anything, the slightly hopeful tone at the end of that article has been proved to be unwarranted over the ensuing four years.
In any case, I was invited to participate in a session at IGF 2022 that was devoted to the workings of the DNS. I’d like to share my contribution to this session with my thoughts on where the DNS is headed.
The session brief reads: “The DNS is receiving increased attention from policy-makers and standards-setting bodies for its central role in the functioning of the Internet. From the DNS4EU proposal, which seeks to create an EU-based recursive DNS service, to local and regional conversations about the potential impacts of DNS encryption, domain name infrastructure and governance have become new sources of contention. But what does the data say on these issues? And perhaps as importantly, what data is missing to develop evidence-based policies around the DNS that protect users’ trust on the Internet?”
The DNS lies in a relatively obscure part of the Internet. Unlike browsers, the World Wide Web, or social network applications, DNS is not exactly prominent or even visible to users. The operation of DNS name resolution protocol operates in a manner that confounds even the end client. It is extremely challenging to trace where and why DNS queries are propagated through the DNS infrastructure and where DNS answers come from and why. The simple question of who gets to see your online activity, in the guise of you and your DNS queries, is often very challenging to answer. Yet, even though its inner workings are obscure to the point of impenetrability, as a protocol, its task is simple: the DNS resolution system takes names and translates them into network addresses. All this might seem innocuous enough, but there are a few aspects of this function that have been used and abused by many over the years, and this lies at the heart of today’s issues with the DNS.
This particular protocol can trace a history back to the 1970s. The initial specification of the protocol was published in the RFC series some 35 years ago in 1987 as RFC 1034 and RFC 1035, based on earlier work on the specification of data objects used to query name servers that were initially published in 1978 with Internet Experimental Note 61. The DNS followed the pattern used by many other network protocols of the time in that it was open. That is to say, its payload, who is asking and what name they are asking about, was not encrypted. It was also trustful in that it did not bother to authenticate whom it was talking to, and a client simply believed in whatever answers were elicited from its query. In defense of what today would be considered an obvious shortcoming, at that time, we weren’t constructing the final version of a future global communications infrastructure. This was just a small-scale experiment in packet networking. As it emerged 35 years ago, the DNS protocol was, in retrospect, overly trustful to the point of being naively gullible, and any determined adversary intruding upon the DNS query traffic could observe and tamper. But this was a research project. Why would they ever want to do this in any case?
When the Internet started to assume a more central role in the public communications realm, DNS came along with it and quickly became a point of vulnerability. If I could see your DNS queries and tamper with DNS answers, then I could misdirect you, or I could claim that sites and servers did not exist when in fact, they did. I could poison your cache with gratuitous information in DNS responses that you were prepared to believe. In all this, you would be none the wiser because, as we have already noted, the inner workings of the DNS are totally opaque to its users.
However, tampering with the DNS is not just a tool for bad actors and bad actions. Many national regimes have used their regulatory and judicial powers to compel Internet Service Providers to actively censor the DNS by intercepting queries for certain DNS names and synthesizing a DNS response that claims that the name does not exist or misdirects the end user to a different service point. This is very widespread today. But perhaps more disturbing, at least for some members of the technical community (RFC 7258) that form the core of the IETF was the Snowden revelations of 2013 which showed that the Internet was being used by a number of national agencies, including some US agencies, to perform mass surveillance. Everything that happens online starts with a call to the DNS. Everything. If I was able to observe your DNS query stream, then there are no secrets left for you. I really do know everything you are doing online and with whom!
The technologists’ response to the Snowden papers has been to erect a new set of protections around the DNS. DNS messages are encrypted, sources of DNS information are authenticated, DNS queries are trimmed of all extraneous information, and DNS content is verifiable. Tampered DNS responses can be recognized as such and discarded. These days we are looking at perhaps the most complete measures with two-layer obfuscation, such that no single party can correlate who is asking and the name they are asking about. It’s not that such information is well hidden—it’s that it does not exist in any such form anymore once it leaves the application on the user’s device. What exactly is “DNS Data” begin referred to in the session brief in this obfuscated world? Where might we find it? The answer is that there is none!
The result is that DNS is going dark. Very dark.
It’s unclear what this means in the long run. Do bad actions and actors go undetected? Do we lose our visibility into network management? What is a “secure” network, and how do we secure it using traditional techniques of network perimeter traffic inspection when all the network traffic is opaque? If we can’t see inside the DNS anymore, then how can we tell if (or when) the DNS has been captured by one or two digital behemoths? How can public policy-makers, market regulators and market actors assess the competitive “health” of the DNS as an open and efficient market for providers and consumers where the market itself heads into deliberately dimmed obscurity?
There is much to think about here about whether the reaction to the initially perceived abuse is causing its own set of issues commensurate with the original trigger issues that started us down this path.
Already, DNS query data is incredibly hard to find. It’s easy to talk about the provisioning part of the DNS, but extraordinarily hard to find out how the DNS is being used. I know this only too well as a researcher in this space. The privacy implications are just too great to make this data available, and obfuscating it makes it largely useless! Our efforts have had some limited success in exposing query patterns and behaviors, but it’s a window that is shutting down bit by bit, day by day.
Where we are heading is an outcome that there will be nothing left to see in the DNS—no data, nothing! And in my view, no policy or regulation can materially alter this trajectory. What we are talking about here is the actions and behavior of applications. Trying to exercise some regulatory impost on how the DNS protocol behaves is about the same in my mind as attempting to regulate the fine-grained behavior of Microsoft Word or the Chrome browser.
In many ways, it has been a convenient coincidence of motives for both the large operators in today’s Internet (Google, Apple, etc.) and their perception of user preference that there is an apparent newfound regard for user privacy. With the ascendency of the application level as the dominant factor in the Internet ecosystem, there is a strong aversion by applications to allow the network or the platform to gain any insight at all into the behavior of the application or the content of the application’s transactions. The QUIC protocol is a good example of loading the entire function of transport and content drivers into the application and hiding absolutely everything from the platform and the network.
The DNS is heading in the same direction, where with tools such as resolverless DNS over HTTPS and DNSSEC, we can remove end-user DNS queries entirely and have the server pre-provision DNS information via server push. If you had thought of the DNS as a common piece of network-level infrastructure, then that view is being superseded by the view of the DNS as an application artifact.
The implications of this combination of increased opacity in the DNS and a shift of the DNS from common infrastructure to application artifact inevitably head into consideration of areas of splintering and fragmentation as applications customize their view of the space of names for their individual purposes. There is the prospect, admittedly a distant one at the moment, of declining residual value in a common general-purpose namespace. As all this operates behind a veil of encrypted and obscured DNS traffic, it will be highly challenging to try and prevent such market forces of destructive entropy from forcing an inevitable outcome here on the Internet as a whole.
To try and provide a response to the question as to what data is missing to develop evidence-based policies around the DNS that protect users’ trust on the Internet, then for me, the answer is not exactly encouraging. We really have no generally available data to use for this purpose today, and the pressures for ever-increasing diligence in the handling of such collected data and the shift to more effective encryption and obfuscation in DNS queries provide more than ample disincentives to collect and disseminate such data to policy-makers in any case in the future.
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byCSC
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byDNIB.com
DoH is the most pernicious in terms of its usurpation of DNS to benefit the web platform monopolies. With DoT, you have a dedicated port number, 853, to block its traffic. QUIC traffic “looks” identical to UDP traffic and uses UDP port 443, so it can and should be blocked too. That leaves DoH, which uses HTTPS port 443. DoH appears to be trailing DoT in terms of “popularity,” but the web platform monopolies like Google and Apple are strong supporters of DoH, so it won’t go away. Is the only choice to find a web browser that DoH has not contaminated?
What data source are you using for the assertion that: "DoH appears to be trailing DoT in terms of popularity" ? DNS query data that we analyse suggests that precisely the opposite is the case. https://stats.labs.apnic.net/edns/XA)
An article published in the February 6th, 2020 issue titled Disappearing DNS: DoT and DoH, Where one Letter Makes a Great Difference has the following quote: "At NETSCOUT, we decided to look at adoption of both protocols by monitoring aggregated DoH and DoT traffic in a few large networks. Over one month, looking at statistics such as total number of requests and responses, sources of requests (Internet users) and sources of responses (DoT or DoH servers) we found that on average there are seven times more DoT requests than DoH. The vast majority of requests over both protocols were served by Google and Cloudflare. Other notable DoT services that we have observed were offered by AdGuard and Clean Browsing. When it comes to DoH, Quad9 and SecureDNS were also among the leaders." The author is Darren Anstee is Chief Technology Officer, SBO International, NETSCOUT. Anstee has 20 years of experience in pre-sales, consultancy and support for telecom and security solutions. As Chief Technology Officer, SBO International, at NETSCOUT, Darren works across the research, strategy, and pre-sales aspects of Arbor's traffic monitoring, threat detection and mitigation solutions for service providers and enterprises around the world. He is an integral part of Arbor's Security Engineering & Response Team (ASERT).