It's common folklore in the Domain Name System that a delegated domain name must be served by 2 or more nameservers. This guidance raises a couple of questions. Firstly, when presented with a list of nameservers for a domain how do recursive resolvers respond? Do they send queries to all of the nameservers at once? Or do they serialise their actions in looking for a responsive nameserver? Secondly, if these queries are serialised, then how can a domain administrator organise the zone’s nameservers to maximise both DNS resolution performance and service resilience?
If we ever get to the point of being able to build capable quantum computers when much of the security infrastructure of today's digital world is at risk. For some its not "if" but "when" and if that's the case then its already time to prepare.
The DNS Operations, Analysis, and Research Center (DNS-OARC) brings together DNS service operators, DNS software implementors, and researchers together to share concerns, information and learn together about the operation and evolution of the DNS. The most recent DNS OARC workshop was held in Prague, October 2024. Here are my thoughts on some of the material that was presented and discussed at this workshop.
At APNIC Labs we generate, on a daily ongoing basis, our estimate of the number of users per ISP for every ISP that we see on the Internet through the ad-based measurement platform. This report is published at the URL: https://stats.labs.apnic.net/aspop. As far as we are aware this is the only such public data set that encompasses the entirety of the public Internet. Here I would like to explain how we calculate this data, and provide some responses to a recent presentation at the RIPE 89 meeting on this data set.
Ethernet has been the mainstay of much of the networking environment for almost 50 years now, but that doesn't mean that it’s remained unchanged over that period. The evolution of this technology has featured continual increases in the scale of Ethernet networks, increasing in capacity, reach and connections. I’d like to report on a couple of Ether-related presentations that took place at the recent NANOG 92 meeting, held in Toronto in October 2024 that described some recent developments in Ethernet.
I wrote an article in May 2022, asking “Are we there yet?” about the transition to IPv6. At the time I concluded the article on an optimistic note, observing that we may not be ending the transition just yet, but we are closing in. I thought at the time that we won’t reach the end of this transition to IPv6 with a bang, but with a whimper. A couple of years later, I’d like to revise these conclusions with some different thoughts about where we are heading and why.
We’ve now been running packet-switched networks for many decades, and these days it’s packets and not virtual circuits lie behind most of the world’s digital communications service. But some very fundamental questions remain unanswered in this packet-switched world. Perhaps the most basic question is: “How big should a packet be?” And, surprisingly enough, there is no clear answer!
The evolution of wired access networks for suburban reticulation has been driven by a special set of economic and technical circumstances. Infrastructure assets are in this sector need to have an extended service life in order to by financially viable. While optical technology continues to evolve rapidly the challenge is to map this changing technology on to a fixed fibre cable plant.
In the IANA IPv4 Address registry a block of addresses, 240.0.0.0/4 is marked as reserved for "Future Use"". If we have run out of available IPv4 addresses, then why are some quarter of a billion IPv4 addresses still sitting idle in an IANA registry waiting for an undefined Future Use?
There was, as usual, a lot of work in the area of Inter-Domain Routing at IETF 120. There were a few routing-related topics that at IETF 120 that caught my attention.
It has been an enduring fascination to see how we could use packet networking in the context of digital communications in space. Why can't we just use the IP protocol suite and declare success? The tricky issue with space is that it is really very big!
As usual, the recent IETF meeting contained a large set of topics related to the Domain Name Systems and its operation. Here's a quick rundown on some DNS topics that caught my eye.
On the topic of TCP performance optimisation I’d like to dwell on one particular presentation from the ACM/IRTF Applied Networking Research Workshop held at IETF 120, "BBRv3 in the public Internet: a boon or a bane?"
>To ensure service consistency in a Content Distribution Network (CDN) replicated instances of the content are named with the same DNS name, and the DNS conventionally offers the same resolution outcome to each user when they query for the IP address of the content server. How can the CDN "steer" each user to the closest instance of the desired content to optimise the subsequent content transaction? At the same time the user is revealing their location within the network to inform this steering decision. To what extent is such a steering function compromising the privacy expectations of users with respect to the location and their online actions?
The choice of UDP as the default transport for the DNS was not a completely unqualified success. On the positive side, the stateless query/response model of UDP has been a good fit to the stateless query/response model of DNS transactions between a client and a server. On the other hand, these same minimal overheads imply that DNS over UDP cannot perform prompt detection of packet loss and cannot efficiently defend itself against various approaches to tampering with the DNS, such as source address spoofing, payload alteration and third-party packet injection. Perhaps most importantly, the way UDP handles large payloads is a problem.
The DNS is a crucial part of the Internet's architecture. However, the DNS is not a rigid and unchanging technology. It has changed considerably over the lifetime of the Internet and here I’d like to look at what’s changed and what’s remained the same.
RIPE 88 was held in May 2024 at Krakow, Poland. Here’s as summary of some of the routing topics that were presented at that meeting that I found to be of interest.
RIPE 88 was held in May 2024 at Krakow, Poland. Here’s as summary of some of the DNS topics that were presented at that meeting that I found to be of interest.
Through the lack of clear signals of general adoption of DNSSEC over three decades, then is it time to acknowledge that DNSSEC is just not going anywhere? Is it time to call it a day for DNSSEC and just move on?
Let's look at the Starlink at a protocol level, and how TCP, the workhorse transport protocol of the Internet, interacts with the somewhat unique characteristics of Starlink's service.
Potaroo blog