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 upstre…
DNS Explained – How Domain Names Get Resolved
11–20 of 54 posts
Re: DNS Explained – How Domain Names Get Resolved
#12Only 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 upstre…
Re: DNS Explained – How Domain Names Get Resolved
#13The 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!
Re: DNS Explained – How Domain Names Get Resolved
#14Propagation might be a useful way to visualise it, but doesn't match reality unless every cache is a warm cache.
Re: DNS Explained – How Domain Names Get Resolved
#15I 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.
Re: DNS Explained – How Domain Names Get Resolved
#16What 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?
Re: DNS Explained – How Domain Names Get Resolved
#17Only 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 upstre…
I think this is probably quite dependent on what’s normal for ISPs in the region. In the UK for example, every ISP router I’ve had runs a DNS server and it’s that which is given out via DHCP. It then forwards onto the ISPs DNS platform.
Nowadays I'm in Finland and definitely the router runs no DNS service, the DHCP service advertises the ISP resolvers.
Probably depends on the region/ISP I guess, but I had no expectation that it would be the more common option.
Re: DNS Explained – How Domain Names Get Resolved
#18Only 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 upstre…
dnsmasq is the defacto tool on these embedded devices for dhcp+dns. probably a billion deployments. it's up there with sqlite for most used tech.
Re: DNS Explained – How Domain Names Get Resolved
#19Earlier quoted context omitted.
I think this is probably quite dependent on what’s normal for ISPs in the region. In the UK for example, every ISP router I’ve had runs a DNS server and it’s that which is given out via DHCP. It then forwards onto the ISPs DNS platform.
In Scotland I was with Telewest, then Virgin, and my memory is always that the DHCP pushed out the external IP of the ISP's DNS servers. Nowadays I'm in Finland and definitely the router runs no DNS service, the DHCP service advertises the ISP resolvers. Probably depends on the region/ISP I guess, but I had no expectation that it would be the more common option.
Re: DNS Explained – How Domain Names Get Resolved
#20The 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".