DNS is a quite well matured technology and it’s just as complex as it needs to be and not a bit more. It’s a very robust system which has been a big part of the backbone of the internet as we know it today for decades and it’s responsible for quite a large chunk of stuff working as intended globally for millions and billions of people all day every day.
It’s not hard to learn per se (it’s something you can explain on a basic level to every layman in 15 minutes or so), it’s just a complex system and understanding complex systems isn’t always easy nor fast. Running your own DNS-server/forwarder for a /24 private subnet is rather trivial thing to do, but doing it well requires that you understand at least some of the underlying tehcnology.
You really need to learn how to walk at first and build on that to run. It’s just a fundamental piece of technology and there’s no shortcuts with it due to nature of DNS services. You can throw whatever running on a container by following step-by-step instructinos and call it a day, but that alone doesn’t give you the knowledge to understand what’s going on under the hood. That’s just how the things are and should I have my way with things, that same principle should apply to everything, specially if it’s going to face the public internet.
Yeah, I don’t think I really agree with the author as to the difficulty with dig. Maybe it could be better, but as protocols and tools go, I’d say that dig and DNS is an example where a tool does a pretty good job of coverage. Maybe not DNSSEC, dunno about how dig does there, and knowing to use +norecurse is maybe not immediately obvious, but I can list a lot of network protocols for which I wish that there were the equivalent to dig.
However, a lot of what of what the author seems to be complaining about is not really stuff at the network level, but the stuff happening on the host level. And it is true that there are a lot of parts in there if one considers name resolution as a whole, not just DNS, and no one tool that can look at the whole process.
If I’m doing a resolution with Firefox, I’ve got a browser cache for name resolutions independently of the OS. I may be doing DNS over HTTP, and that may always happen or be a fallback. I may have a caching nameserver at my OS level. There’s the /etc/hosts file. There’s configuration in /etc/resolv.conf. There’s NIS/yp. Windows has its own name resolution stuff hooked into the Windows domains stuff and several mechanisms to do name resolution, whether via broadcasts without a domain controller or with a DC whether that’s present; Apple has Bonjour and more-generally there’s zeroconf. It’s not immediately clear to someone the order of this or a tool that can monitor the whole process end to end – these are indeed independent systems that kind of grew organically.
Maybe it’d be nice to have an API to let external software initiate name resolutions via the browser and get information about what’s going on, and then have a single “name resolution diagnostic” tool that could span multiple of these name resolution systems, describe what’s happening and help highlight problems. I can say that gethostbyname() could also use a diagnostic call to extract more information about what a resolution attempt attempted to do and why it failed; libc doesn’t expose a lot of useful diagnostic information to the application, though libc does know what it is doing in a resolution attempt.
DNS is a quite well matured technology and it’s just as complex as it needs to be and not a bit more. It’s a very robust system which has been a big part of the backbone of the internet as we know it today for decades and it’s responsible for quite a large chunk of stuff working as intended globally for millions and billions of people all day every day.
It’s not hard to learn per se (it’s something you can explain on a basic level to every layman in 15 minutes or so), it’s just a complex system and understanding complex systems isn’t always easy nor fast. Running your own DNS-server/forwarder for a /24 private subnet is rather trivial thing to do, but doing it well requires that you understand at least some of the underlying tehcnology.
You really need to learn how to walk at first and build on that to run. It’s just a fundamental piece of technology and there’s no shortcuts with it due to nature of DNS services. You can throw whatever running on a container by following step-by-step instructinos and call it a day, but that alone doesn’t give you the knowledge to understand what’s going on under the hood. That’s just how the things are and should I have my way with things, that same principle should apply to everything, specially if it’s going to face the public internet.
Yeah, I don’t think I really agree with the author as to the difficulty with
dig. Maybe it could be better, but as protocols and tools go, I’d say that dig and DNS is an example where a tool does a pretty good job of coverage. Maybe not DNSSEC, dunno about howdigdoes there, and knowing to use+norecurseis maybe not immediately obvious, but I can list a lot of network protocols for which I wish that there were the equivalent todig.However, a lot of what of what the author seems to be complaining about is not really stuff at the network level, but the stuff happening on the host level. And it is true that there are a lot of parts in there if one considers name resolution as a whole, not just DNS, and no one tool that can look at the whole process.
If I’m doing a resolution with Firefox, I’ve got a browser cache for name resolutions independently of the OS. I may be doing DNS over HTTP, and that may always happen or be a fallback. I may have a caching nameserver at my OS level. There’s the
/etc/hostsfile. There’s configuration in/etc/resolv.conf. There’s NIS/yp. Windows has its own name resolution stuff hooked into the Windows domains stuff and several mechanisms to do name resolution, whether via broadcasts without a domain controller or with a DC whether that’s present; Apple has Bonjour and more-generally there’s zeroconf. It’s not immediately clear to someone the order of this or a tool that can monitor the whole process end to end – these are indeed independent systems that kind of grew organically.Maybe it’d be nice to have an API to let external software initiate name resolutions via the browser and get information about what’s going on, and then have a single “name resolution diagnostic” tool that could span multiple of these name resolution systems, describe what’s happening and help highlight problems. I can say that
gethostbyname()could also use a diagnostic call to extract more information about what a resolution attempt attempted to do and why it failed; libc doesn’t expose a lot of useful diagnostic information to the application, though libc does know what it is doing in a resolution attempt.