HN Reader

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.

> You can change which resolver you use in your network settings. I switched to 1.1.1.1 on my machines - it's noticeably faster than my ISP's default resolver.

Noticeably faster as in just loading a website? Or in some script where small differences add up? I thought typical DNS lookup was sub 100ms, but I've never tried switching my resolver so I'm curious

> Without DNS, you'd need to memorize IP addresses for every website.

This used to be true until virtual hosting came along, allowing for several domains to point to the same IP address, but only for non-HTTPS traffic. Then a bit later we got SNI (Server Name Indication) that did the same thing for HTTPS.

I remember having web servers with 10-12 public IP adresses when I started working. The number of IPv4 addresses needed has been greatly reduced since.

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

Cool, but the macOS commands being wrong irks me. You could at least check them before publishing. It seems like you used an LLM to write that part. And the table "quick reference" at the end is also a LLM tell.

> 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.

I really like Julia Evan's explainer on this as well: https://wizardzines.com/zines/dns/

well written

would really be happy to have had these explanations before I had to figure it out for myself.

then you have these guys who reached the next level

https://www.dns.toys/

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?

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!

DNS is an example of a globally distributed DB

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 article!

I love DNS!

https://www.instagram.com/p/DUTSLcjkfJn/