Web Developer's Guide to DNS
rjzaworski.com
Web Developer's Guide to DNS
1–10 of 52 posts
Re: Web Developer's Guide to DNS
#2I've also found this guide to be really helpful: https://howdns.works/
Re: Web Developer's Guide to DNS
#3A few issues:
• The description is a bit vague, but the article seems to describe a model of a stack of resolvers, each resolver asking the next one in turn, the last resolver getting an answer, and the answer being then passed down the chain again. But this is not how it works. For a normal DNS query, there is ever only one resolver involved. This one resolver is the single thing asking many authoritative servers the same question, each time getting names of servers who might know the answer, and ultimately getting an actual answer. There is no stack of resolvers.
• The article completely conflates the process of a cached record expiring due to TTL expiration, with the process of an updated zone with a new serial number being transferred to slave servers. These two things have virtually nothing in common.
I also found the illustrations too detailed (i.e. confusing for non-experts). There are a lot of options to "dig" which could have been used to cut down on the extraneous output when illustrating a particular point.
The zone file was especially confusing, in that none of it was explained, and the nature of the DNS data model would have been much better illustrated with an object diagram of some kind.
Re: Web Developer's Guide to DNS
#4nice!
Re: Web Developer's Guide to DNS
#5A few issues: • The description is a bit vague, but the article seems to describe a model of a stack of resolvers, each resolver asking the next one in turn, the last resolver getting an answer, and the answer being then passed down the chain again. But this is not how it works. For a normal DNS query, there is ever only one resolver involved. This one resolver is the single thing asking many authoritative servers th…
"the article seems to describe a model of a stack of resolvers, each resolver asking the next one in turn, the last resolver getting an answer, and the answer being then passed down the chain again. But this is not how it works."
There may be some semantics that aren't right, but say I have a Linux box, a home router, pointed at 8.8.8.8, and ask it for something not in anyone's cache. There is a "stack" of sorts when the answer isn't cached anywhere. Various caches in either resolver libraries and real DNS servers...forwarding ones, root ones, authoritative ones, etc.
And the depth of the stack is different depending on my setup.
Re: Web Developer's Guide to DNS
#6I've recently found that DNS is surprisingly simple protocol, you can implement simple query/response with very few lines of code. So if you want to better understand it, you might want to code a simple client, may be even recursive one.
Re: Web Developer's Guide to DNS
#7A few issues: • The description is a bit vague, but the article seems to describe a model of a stack of resolvers, each resolver asking the next one in turn, the last resolver getting an answer, and the answer being then passed down the chain again. But this is not how it works. For a normal DNS query, there is ever only one resolver involved. This one resolver is the single thing asking many authoritative servers th…
"the article seems to describe a model of a stack of resolvers, each resolver asking the next one in turn, the last resolver getting an answer, and the answer being then passed down the chain again. But this is not how it works." There may be some semantics that aren't right, but say I have a Linux box, a home router, pointed at 8.8.8.8, and ask it for something not in anyone's cache. There is a "stack" of sorts when…
So where’s the stack?
The Linux box presumably uses the resolver as announced by the DHCP server on the router, which I would guess is 8.8.8.8. Therefore, the chain goes linux-box → 8.8.8.8 → auth servers, 8.8.8.8 being the resolver.
Or perhaps the router announces itself as the resolver, and proxies all requests to 8.8.8.8. This would not be necessary, but I guess it would be useful for the router to do proxying instead of NAT whenever the protocol (DNS in this case) makes it possible. There is still no reason to call the router a “resolver”, or even assume that the DNS proxy software on the router even has a cache.
Describing DNS as a stack of resolvers is like describing HTTP as always having a chain of caching proxies. It is not normally true, and even when it is close to true, it’s made to not look that way – i.e. it’s not useful to think of it that way, especially when explaining it to someone else.
Re: Web Developer's Guide to DNS
#8Earlier quoted context omitted.
"the article seems to describe a model of a stack of resolvers, each resolver asking the next one in turn, the last resolver getting an answer, and the answer being then passed down the chain again. But this is not how it works." There may be some semantics that aren't right, but say I have a Linux box, a home router, pointed at 8.8.8.8, and ask it for something not in anyone's cache. There is a "stack" of sorts when…
So where’s the stack? The Linux box presumably uses the resolver as announced by the DHCP server on the router, which I would guess is 8.8.8.8. Therefore, the chain goes linux-box → 8.8.8.8 → auth servers, 8.8.8.8 being the resolver. Or perhaps the router announces itself as the resolver, and proxies all requests to 8.8.8.8. This would not be necessary, but I guess it would be useful for the router to do proxying ins…
The Linux box could have a caching forwarder, as could the router. There are many routers with a local cache that put their own IP in the DCHP nameserver spot.
And 8.8.8.8 may not know the answer, and may have to query for it, that's a very common "stack". A non recursive client letting a recursive server do the trawling is probably the most common home use case.
You could put a recursive resolver on your Linux desktop, and that would be different. Not common for a home PC though.
Re: Web Developer's Guide to DNS
#9A special shout out to Lennart Poettering for recently breaking dig +trace!
Re: Web Developer's Guide to DNS
#10Earlier quoted context omitted.
So where’s the stack? The Linux box presumably uses the resolver as announced by the DHCP server on the router, which I would guess is 8.8.8.8. Therefore, the chain goes linux-box → 8.8.8.8 → auth servers, 8.8.8.8 being the resolver. Or perhaps the router announces itself as the resolver, and proxies all requests to 8.8.8.8. This would not be necessary, but I guess it would be useful for the router to do proxying ins…
The Linux box could have a caching forwarder, as could the router. There are many routers with a local cache that put their own IP in the DCHP nameserver spot. And 8.8.8.8 may not know the answer, and may have to query for it, that's a very common "stack". A non recursive client letting a recursive server do the trawling is probably the most common home use case. You could put a recursive resolver on your Linux deskt…
Everything is possible in theory, of course, but all of these theoretical possibilities are relatively uncommon, and, more importantly, made to not look like the aforementioned chain-of-resolvers. The normal DNS procedure is client→resolver→authoritative_server, and any deviation from this is deliberately hidden by the components which alter it.