21–30 of 54 posts
> 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 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.
And checkout their Mess with DNS playgound!
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.
It’s accurate to say that a user is waiting for the change to propagate if they are sitting there clicking re-try as they wait for the cascading cache expirations to do their thing.
> 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.
why you need DNS for at server? just use hosts file. why your server would need to resolve domains on the internet? client yeah, server no.
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…
For round-robin, I've actually had it work reasonably well for API usage. Of course it's not ideal, but when I wanted to roll out new things slowly over several days and could not use a load balancer or reverse proxy, it kind of worked. I think most API users are just running with a reasonable resolver and not residential ISP ones.
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!
Thanks! That was exactly what I was going for - making DNS approachable for everyone, not just sysadmins. Glad it helped!
One nitpick I had was that the subdomain examples are more likely to be hosts. They could be either, but was not mentioned. Perhaps I missed.
> 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.
why you need DNS for at server? just use hosts file. why your server would need to resolve domains on the internet? client yeah, server no.
But it's not an issue at all, and it provides a convenience that can be depended on by a lot of your dependencies.
Code may use domains instead of ip addresses (which provides resiliency), package managers like apt depend on domains. And so on.
> 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.
why you need DNS for at server? just use hosts file. why your server would need to resolve domains on the internet? client yeah, server no.
IP's can change without warning.