This is a technical report on a detailed exploration of the way the Internet’s Domain Name System (DNS) interacts with the network when the size of the application transactions exceeds the underlying packet size limitations of hosts and networks.
We're now using the Internet's address infrastructure in very different ways than the way we had envisaged in the 1980's. The Internet’s name infrastructure is subject to the same evolutionary pressures, and its these pressures I’d like to look at here. How is the DNS is responding?
Over the past few months I've had the opportunity at various network operator meetings to talk about BGP routing security. As usual, these presentations include an opportunity for questions from the audience. Here are a small collection of such questions and my efforts at trying to provide an answer.
The Internet was not the first communications system constructed as compound service, where the end-to-end service was built using the services provided by many individual service providers. International telephony was constructed in a similar manner, and predating the telephone was the international postal service. In this article I’d like to look at the Universal Postal Union's track record of trying to construct a fair and efficient way to allow each service provider to be compensated for their part in the construction of the delivered end-to-end service. As with the Internet, it all comes down to the choice of the framework for settlement and peering between providers.
The DNS is a remarkably simple system. You send it queries and you get back answers. Simple. However, the DNS is simple in the same way that Chess or Go are simple. They are all constrained environments governed by a small set of rigid rules, but they all possess astonishing complexity.
A year has passed since we first looked at the level of use of Query Name Minimisation in the DNS and at the time the results were not impressive. It's time to relook at this topic and see what has changed in the DNS resolution environment over the past 12 months.
These days the process of making an RFC involves extensive review. You might think that the result of this truly exhaustive document review process is some bright shiny truth that is stated with precision and clarity. But that is not necessarily so. Why not?
In the Internet’s name space the DNS OARC meetings are a case where a concentrated burst of DNS tests the proposition that you just can't have too much DNS! OARC held its latest meeting on the 11th August with four presentations. Here's my thoughts on the material presented at that meeting.
APAN (Asia Pacific Advanced Network) brings together national research and education networks in the Asia Pacific region. APAN holds meetings twice a year to talk about current activities in the regional NREN sector. I was invited to be on a panel at APAN 50 on the subject of Cyber Governance, and I’d like to share my perspective on this topic here.
These days it seems that whenever we start to talk about the DNS the conversation immediately swings around to the subject of DNS over HTTPS (DoH) and the various implications of this technology. But that's not my intention here. I'd like to look at a different, but still very familiar and somewhat related, topic relating to the DNS, namely how IPv6 is being used as a transport protocol for DNS queries.
How well are we doing with the adoption of Route Origin Validation in the Inter-Domain routing space? How many users can no longer reach a destination if the only available ROAs mark the destination announcement as invalid?
This week I participated in a workshop on measurement of IPv6, organised by the US Naval Postgraduate School's Centre for Measurement and Analysis of Network Data (CMAND) and the folk at UC San Diego's Center for Applied Internet Data Analysis (CAIDA). Here's my notes from that workshop and a few opinions about IPv6 thrown is as well.
I was on a panel at the recent Registration Operations Workshop on the topic of DNS Privacy and Encryption. The question I found myself asking was: "What has DNS privacy to do with registration operations?"
How are new technologies adopted in the Internet? What drives adoption? What impedes adoption? These were the questions posed at a panel session at the recent EuroDiG workshop in June.
For many years I have been a keenly interested participant in the meetings organised by the DNS Operations and Research Community, or DNS OARC. This time around its most recent meeting headed into the online space. Here's my impressions of the material presented at the online DNS OARC 32a meeting.
Over the past couple of decades, we've constructed two quite distinct online environments. There is the enterprise network which is commonly encountered at physical workplaces, and there is the consumer network which has been deployed across residential domains. The result is that many observed characteristics of the network have patterns that reflected the differences between these work and home environments. But what happened when the at-work workforce was sent home to work? What can the DNS tell us about the Lockdown?
A "New IP" framework was proposed to an ITU Study Group last year. This framework envisages a resurgence of a network-centric view of communications architectures where application behaviours are moderated by network-managed control mechanisms. It's not the first time that we’ve seen proposals to rethink the basic architecture of the Internet’s technology and it certainly won’t be the last. But is it going to really going to influence the evolution of the Internet? What can we observe about emerging technologies that will play a critical role in the coming years? Here’s my personal selection of recent technical innovations that I would add into the set of emerging technologies that will exercise a massive influence over the coming ten years.
I've been asked a number of times: "Why are we using as distributed trust framework where each of the RIRs are publishing a trust anchor that claims the entire Internet number space?"" I suspect that the question will arise again the future so it may be useful to record the design considerations here in the hope that this may be useful to those who stumble upon the same question in the future.
I'm constantly impressed by the rather complex intricacies that are associated with running your own web server these days. A recent source of these complexities has been the PKI, the security infrastructure used to maintain secure connections over the network, and I'd like to recount my experience here, in case any others encounter the same seemingly inexplicable behaviours in their secure web service configurations.
We need a secure and trustable infrastructure. We need to be able to provide assurance that the service we are contacting is genuine, that the transaction is secured from eavesdroppers and that we leave no useful traces behind us. Why has our public key certificate system failed the Internet so badly?
Potaroo blog