The biggest issue with DNS is not the protocol, or even the reference implementation. It's the people who think they are clever and try to make things better by making them worse.

The most egregious of course is ISPs rewriting TTLs (or resolvers that just ignore them). But there are other implementation issues too, like caching things that shouldn't be or doing it wrong. I've seen resolvers that cache a CNAME and the A record it resolves to with the TTL of the CNAME (which is wrong).

I'm also very concerned about the "WHY DNS MATTERS FOR SYSTEM DESIGN" section. While everything there is correct enough, it doesn't dive into the implication of each and how things go wrong.

For example, using DNS for round robin balancing is an awful idea in practice. Because Comcast will cache one IP of three, and all of a sudden 60% of your traffic is going to one IP. Similar issue with regional IPs. There are so many ways for the wrong IP to get into a cache.

There is a reason we say "it's always DNS".

I have to admit - I still grind my teeth every time I see "dns propagation" used without a direct follow-up that it's a myth, you're looking at cascading cache expiry.

Propagation might be a useful way to visualise it, but doesn't match reality unless every cache is a warm cache.

This is not a bad overview of DNS from a theoretical perspective. It’s also pretty well written and has good examples and figures.

What I think is missing is a bit more of the “in practice” side. If the author was surprised about TTL values, I doubt they have much experience with some of the other pitfalls, so I’m not surprised (not a knock on the author). But there is a reason why the phrase “It’s always DNS” exists.

As an example, it could be helpful to mention that ISP DNS resolvers (or any caching resolver in the path) could decide to ignore the TTL. In this case, your 360 sec TTL might not get updated for an hour or a day or longer. This can be infuriating to troubleshoot.

A section on troubleshooting might also be beneficial. But this mainly consists of checking results from different resolvers in your path - does it work with a local resolver? Your ISPs DNS? The authoritative server?

> DNS broke my site for three hours. But now I actually understand it

I have been broken for three decades and I still don't understand DNS. It is a simple protocol but people use it in complicated manners.

Only oddity was the reference to the "router cache". I agree if your browser tried to lookup example.com the local cache would be used, but then it would be the system's configured DNS server - and that would most likely be an ISP, rather than your local router.

(Assuming a typical home connection, your router is _probably_ not a DNS server with local cache, it probably is a DHCP server which will hand out the upstream/ISPs' nameservers.)

Honestly, I guess it's a fine article for someone who isn't very technical, but it provides very little real detail, and this wasn't an example of DNS breaking anything - it worked as designed.

The biggest pain of DNS for most people is if someone has set the TTL to an absurdly large number, or if a resolver isn't respecting TTL. And once you get into advanced configurations, SOAs and delegation certainly create their own headaches!

This might be the easiest-to-understand breakdown of DNS that I've seen to date. I've owned a domain since the late 90s, but never really understood everything the acronyms or concepts involved in making it work. Well done!

Well written! Is so easy to understand and read that I can easily share it even with non-tech people c:

Well written article!