Why is DNS still hard to learn?
Open link in next tab
Why is DNS still hard to learn?
https://jvns.ca/blog/2023/07/28/why-is-dns-still-hard-to-learn/
Why is DNS still hard to learn?
https://jvns.ca/blog/2023/07/28/why-is-dns-still-hard-to-learn/
Why is DNS still hard to learn?
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.
I think your assessment is pretty accurate as for me it wasn't difficult to learn or understand, but I have a technical background and did when I was learning it. I learned how it does thins and why. I think most people who encounter it just want it to work, and like a lot of tech it's just magic to them once it starts working
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.
In the words of Dylan Beattie. "There are only two had problems in software programming. Cache invalidation and naming things. So let's talk about DNS…"
I don't get it. DNS is easy if you actually learn it and study the thing instead of simply trying to "make it work".
make dig’s output a little more friendly. If I were better at C programming, I might try to write a dig pull request that adds a +human flag to dig that formats the long form output in a more structured and readable way, maybe something like this:
Okay, fair enough.
One quick note on dig: newer versions of dig do have a +yaml output format which feels a little clearer to me, though it’s too verbose for my taste (a pretty simple DNS response doesn’t fit on my screen)
Man, that is like the opposite approach to what you want. If YAML output is easier to read, that's incidental; that's intended to be machine-readable, a stable output format.
just use host or dog.
❯ host www.google.com
www.google.com has address 142.250.204.4
www.google.com has IPv6 address 2404:6800:4006:814::2004
❯ dog reddit.com TXT
TXT reddit.com. 1h00m00s "614ac4be-8664-4cea-8e29-f84d08ad875c"
TXT reddit.com. 1h00m00s "MS=ms71041902"
...
What's hard? Set up a server so you can create your own local domains and see what works and what breaks. There are a number of resources out there like the bind9 documents, and plenty of examples from places like stack exchange. Setting up basic domain records with NS and MX records is well documented, and even subdomains are straighforward. Once you have that much working then you can try adding more informational stuff like TXT and PTR records.
Don't forget to update your serial every time you make an update. The format isn't important as long as it makes sense to you, but you are limited to a maximum of 10 digits. You can do a straightforward date stamp like 20230729xx (leaving the last two digits for daily changes), you could do a unix timestamp, or you might have your own idea. However if you go backwards in your numbering then you have to wait for the expire time to run out before other servers will pick up your new record.
There's a huge amount of things you can do with dns records. My own setup involves two ISP connections and a custom root zone down to signed dnssec records. I literally have everything in place to run the whole internet using free software.
I've found DNS actually to be one of the easier services to setup. Unbound and NSD take a lot of the hard work away.
I feel like the protocol itself is very straightforward and it doesn't spend you much time to grab the basic, it's also easy to debug using tools like host and dig. The really pain in ass part for me is configuring those software and handle security stuff. It seems to me every old protocols are easy to understand but tedious to config.
I really don't know why. There are a plethora of good articles and tutorials out there. Perhaps it would be helpful to understand what In particular makes it challenging for many so I could write a targeted article