14 posts tagged with "Educational"

When people say "dynamic DNS", they often mean two different things. One is the home broadband pattern where a firewall tells a public DNS provider that its internet address changed. The other is the enterprise pattern where a host gets a lease from DHCP and then its name shows up in internal DNS a few seconds later. This post is about the second one.

The short version is simple: DHCP doesn't magically write to DNS. A client or a DHCP server sends a normal DNS UPDATE message to the authoritative DNS server, and a set of RFCs decides who is allowed to do it, what gets written, and how collisions are handled. The clever bit is not the packet. It's the ownership model around the packet. RFC 2136 defines the DNS update opcode, RFC 4702 and RFC 4704 define how DHCP negotiates update responsibility, and RFC 4701 plus RFC 4703 define the ownership token that stops one client from trampling another.

I use the .github/copilot-instructions.md file to keep writing style steady across posts, docs, and code comments. It works well for voice, but it also shows why explicit inclusion rules matter. If you don't write them down, the assistant fills the gaps with its own defaults.

The CNAME (Canonical Name) record is one of the most straightforward DNS record types in concept: it creates an alias for a domain name. Yet the DNS specifications impose very rigid constraints on where and how CNAMEs can be used. These rules exist for good reasons: consistency, cache efficiency, and preventing resolver bugs. This post is about all the rules relating to CNAME usage, drawing directly from RFC 1034 (Domain Names - Concepts and Facilities) and RFC 1912 (Common DNS Operational and Configuration Errors). More importantly, it should explain some of the really annoying gotchas that have tripped me up at various points in my career, and that I want you to be better equipped to avoid.

There's a draft Internet-Draft floating around called "IPv8" by Jamie Thain. It was published in April 2026 and reads like a list of every networking buzzword bingo square you can imagine, stapled together with a straight face. I read it twice to make sure I wasn't missing the joke. I don't think I was. So either it's an April Fool that ran a couple of weeks late, or somebody is genuinely proposing it. Either way, it deserves a careful kicking.

Let me walk through why.

I'm enjoying reading "DNS: The Internet's Control Plane" by Enrique Somoza and one of the things it mentioned was that there are exactly 13 DNS root servers and this is a hangover from the early days of the internet. It also predates the anycast architecture that allows each root server IP to be served by multiple machines around the world. I thought it worth a little dig. Get it?

The book itself, and many of the search results I found, say that it is due to the 512-byte limit of a UDP DNS response. But I wanted to get into the detail that wasn't easily found and understand exactly what the response was and how the 13 is calculated.

In March 2026, Quad9 announced support for DNS over QUIC (DoQ) alongside DoH3 on their public resolver network. That's the same month Microsoft's DoH support for Windows Server DNS moved out of preview. Two announcements in the same month, both about encrypted DNS, and they point in different directions.

Microsoft's move continues the push toward DoH—encryption that hides in plain sight on port 443. Quad9's move adds DoQ, which offers better latency than DoT but keeps the port 853 visibility that enterprises actually want. Together they prompt a question I don't think the industry has properly answered yet: are we encrypting DNS for privacy, or for security? Because the answer changes everything about which protocol you should reach for. In this post I'll largely ignore DoH3, which is DoH over HTTP/3. It's HTTP/3 and that's about as exciting as it gets, otherwise it's the same story as DoH over HTTP/2.

This post builds on my earlier posts on encrypted DNS governance and SVCB/HTTPS records. I'm not going to re-cover the wire format or the DoT vs DoH comparison—read those first if you need the background. This is about DoQ specifically, what QUIC brings to DNS, and why I think the enterprise conversation about encrypted DNS is asking the wrong question.

I went down the rabbit hole of encrypted DNS a little while ago, mainly prompted by the recent preview of DNS over HTTPS (DoH) in Windows DNS Server, and that led me to the wonders of SVCB and HTTPS records in DNS which have some practical applications including DNS Discovery and Redirection (DDR).

First things first, a recap of what DDR is and the mechanism. DDR is a mechanism that allows a DNS resolver to discover and redirect to an alternative DNS resolver that supports encrypted DNS protocols like DoH or DoT. This is done through the use of SVCB (Service Binding) records in DNS, which can provide information about the capabilities of a DNS resolver and how to connect to it securely.

In my previous post on encrypted DNS, I mentioned SVCB and HTTPS records together. For encrypted DNS discovery specifically, it is SVCB, used with the DNS-server mapping in RFC 9461 and DDR in RFC 9462, that lets supporting clients discover encrypted resolver transports without a manually entered DoH URL. I got several follow-up questions asking what these records actually are, how they work, what problems they solve, and what new problems they create.

This is a deep dive into both. I'll explain the mechanics, show you how they work with real examples you can test, walk through their legitimate use cases, and then discuss the operational challenges they present, especially for organisations trying to maintain control over encrypted DNS at their perimeter.

I make no secret of the fact that I love DNS. I think it's one of the most fascinatingly simple yet powerful protocols in the internet stack. The strength of DNS is its flexibility to do things that the original designers never imagined, while its biggest weakness is its flexibility to do things that the original designers never imagined. SVCB and HTTPS records are a perfect example of both sides of that coin.

SVCB and HTTPS records are fundamentally different from the DNS records you're used to. They're not just another way to signpost from a domain to a server IP address. They're a service metadata layer that lets DNS tell clients which endpoints to use, which protocols those endpoints support, and how to connect to them. That flexibility is powerful. It's also why they've become a vector for unexpected behaviour in networks trying to enforce encrypted DNS policies.

Let's start with what they are and how they work.

I recently got drawn into a bit of LinkedIn rage bait: a post with a CCNA level question asking people to identify the broadcast domains in a given diagram. The diagram was simple enough and it was pretty clear what the question was trying to test, an understanding of what a broadcast domain is. The question did, however, elicit a lot of discussion. It left enough ambiguity that there was a valid answer for multiple interpretations.

The Mad Men of advertising had a knack for selling ideas, lifestyles, and products with flair and persuasion. But what if they turned their talents to selling networks? How might they approach the task of convincing businesses to invest in robust networking solutions?

The Arctic wind whipped across my face as I looked up at the entrance of what might be humanity's most important insurance policy. It has been a place that has fascinated me since I read a New Scientist article about it many years ago, and there I was, staring at the concrete wedge jutting from the mountainside, its façade glittering with an art installation that catches the summer Arctic sunlight.

I've already written a bit about various firewalls and their performance with FQDN filtering. I've also made the case for a 'less is more' approach to egress security where it makes sense. But the topic of FQDN filtering keeps coming up, so I thought I'd share a few more thoughts on it.

When you create a VNet in Azure or a VPC in AWS, you need to allocate a CIDR range for your subnets. There are key differences between these cloud providers when expanding networks, which can create challenges. Knowing these rules from the start helps you plan your CIDR ranges better. I'll start with what's similar across AWS and Azure, then look at the differences.

When packets travel through a cloud network, they face many decision points. Among these, one stands out as really important: the initial routing decision. At its heart is an algorithm that might seem strange at first - the Longest Prefix Match (LPM). Why do we prioritise longer prefix matches? Why not shorter ones, or why not simply use the first match we find? The answer lies in a fascinating mix of computing efficiency, network design, and how cloud computing has evolved.