13 posts tagged with "Educational"

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.

Microsoft lights the fuse​

In February 2026, Microsoft quietly dropped a public preview of DNS over HTTPS (DoH) support in the Windows Server DNS service. It's available in Windows Server 2025 with the KB5075899 update, and the announcement was understated: a few PowerShell commands, a certificate requirement, and an event ID to watch for in the DNS Server logs. The implications for enterprise network architects are anything but quiet, though.

Yesterday I saw a post, now removed, on Reddit that revealed that ESET uses DNS queries to do MAC address OUI lookups. This is quite smart because it allows a client to avoid maintaining a local copy of the OUI database and also means that the databases can be queried without having to have direct or proxied http access to an external API endpoint.

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?

More than just an interview question​

I've sat on both sides of countless technical interviews over my years in networking. There's this familiar dance that happens when discussing OSPF: the candidate confidently states "OSPF uses Dijkstra's algorithm for route calculation," and I'll nod approvingly. But here's the thing - in hundreds of these exchanges, I've never once asked a candidate to explain what that actually means, and no one's ever asked me to explain it either.

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.

Introduction: Beyond the Basics​

FizzBuzz has long been a staple of programming interviews. The problem is deceptively simple: print numbers from 1 to n, but replace multiples of 3 with "Fizz", multiples of 5 with "Buzz", and multiples of both with "FizzBuzz". It's not meant to be a challenging algorithmic puzzle; most candidates with basic programming knowledge should solve it without difficulty.

So why does this trivial problem persist in the interview landscape? Because I believe FizzBuzz's true value isn't in filtering out candidates who can't code—it's in opening discussions about complexity, language characteristics, optimisation, and the subtle costs of different operations. The best interviewers don't just ask candidates to solve FizzBuzz; they use it as a starting point for a deeper technical conversation.

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.

Introduction​

I've been asked to explain networks to people with no experience several times and it's hard to know where to start. There's so much history and so many computer science concepts that have led us to where we are today. I've always believed that to truly understand something, you need to be able to explain it to someone else. My goal here isn't just to explain the bits that make the internet work, but also to organise my own understanding and explore areas where I've taken things on faith instead of questioning why they exist. I'll start from nothing and rebuild the internet from scratch, solving the same problems that got us where we are today.

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.