Live data from Hacker News

Why is DNS still hard to learn?

jvns.ca

71–80 of 261 posts

Re: Why is DNS still hard to learn?

#71
post #51

Earlier quoted context omitted.

I think it is hard to learn... using the tools people used to learn DNS with. BIND is great at what it does, but its configuration files suck and its manual is long, terse, and unnecessarily complex sometimes. Dig is powerful, but abbreviates everything like we're on an 80 column terminal. At times Wireshark was a better tool debugging DNS issues than Dig was. Give someone PowerDNS or another modern DNS server and I…

>I don't know what the semicolons before the lines are supposed to convey but they're only making things confusing all of the lines that aren't part of the query answer are prefixed with semicolons. so it's basically a comment character. presumably to ease processing of the data it spits out. You know. So you can `dig google.com | grep -v '^;' | grep . | awk '{ print $5 }'` easily. I can imagine people using it in a…

Now I just wonder what the double semicolons mean and why they're different from single semicolons :) It's fine, I can Google the answer, I just wished I didn't need to.

I already know to use +short when I just want the result(s). I use it in a script to detect and resolve my Pihole's random freezes (by timing the lookup and rebooting the VM every time a lookup fails or takes longer than 200ms, janky but it works).

Re: Why is DNS still hard to learn?

#72

Earlier quoted context omitted.

That definitely helps things to work , but it makes it very much more difficult to work out why things might not be working. Not least because an unexpected cache can lead to things looking like they're working when they're actually broken at source, as well as things looking like they're still broken when you've actually fixed them at source already.

"I didn't know that cache existed" isn't because of the difficulty of invalidating the right items, though. And the occasional cache that keeps things forever is so extra broken that it's not doing that because cache invalidation is hard , it's either a supreme misunderstanding or it's incompetence.

> And the occasional cache that keeps things forever is so extra broken that it's not doing that because cache invalidation is hard, it's either a supreme misunderstanding or it's incompetence.

Working in phone technical support in the early 2000s, I encountered first in CF6 and then at least one J2EE implementation (Websphere, maybe?) where the $^&#ing default was to cache DNS results forever.

The behavior was borderline undocumented, and the setting to fix it was even less well documented. It's like they wanted DNS to not be a thing.

Re: Why is DNS still hard to learn?

#73
post #30

I don't agree with this article. I think DNS is something few people take the time to learn, but it's not actually hard to learn. One of the great things about DNS is that the system itself will tell you about it's internal state in response to queries. It's very easy to inspect a DNS server for a known zone and understand how it works, and there's very good tooling that's free and widely available to do this (like d…

If you read the article the author points out why it's hard to learn. The concept is easy, but when teaching the concepts we don't include all the details of the modern internet.

As an example what are the rules that your browser uses to cache and expire DNS entries? Are those rules consistent between browsers?

Re: Why is DNS still hard to learn?

#74
post #61

Earlier quoted context omitted.

I think it is hard to learn... using the tools people used to learn DNS with. BIND is great at what it does, but its configuration files suck and its manual is long, terse, and unnecessarily complex sometimes. Dig is powerful, but abbreviates everything like we're on an 80 column terminal. At times Wireshark was a better tool debugging DNS issues than Dig was. Give someone PowerDNS or another modern DNS server and I…

BIND expose (almost) every details of DNS. That's why learning their config would teach you 90% of the DNS system. dig output make sense after reading the RFC. It exposes every bit flag in the protocol level

I have read the RFC. I just don't mess with DNS often enough that I know all the RFC definitions from the top of my head, and I don't want to need to find the appropriate RFC(s) every time I want to debug an issue.

It's not as if tools like wget bother you with http/3 spec fields every time you download something from the internet unless you explicitly ask for them, and even if they do, they're more descriptive than just the shortcode coming from a diagram in the RFC.

Re: Why is DNS still hard to learn?

#75
post #2

It’s not. It’s one of the few things that hasn’t changed much and it’s operation is fairly straightforward. dig is a little confusing. It’s more capable but less straightforward than good old nslookup (which still works fine BTW). I think partly DNS and the core protocols may seem confusing to younger people in the industry because so much stuff “just works” now. For example, today wifi routers “just work” right out…

>It’s one of the few things that hasn’t changed much and it’s operation is fairly straightforward.

It's relatively straightforward, ignoring all of the potential ways that things can go wonky, e.g. random servers not respecting TTL.

But I'll never forget when Firefox put out an update with DNS-over-HTTPS turned on by default. All of a sudden, I was inundated with "Email is gone! Everything is broken!" because we run an internal DNS server handed out to workstations by DHCP. We have internal webmail and intranet Web servers that were just gone.

It took a lot longer than it should to figure out what was happening, partially because it's DNS! Why should things go blooey? But it's pretty clear that Mozilla did not anticipate this (easily forseen, IMO) sort of issue.

Re: Why is DNS still hard to learn?

#78
It's one of those things where there is a mismatch between how easy it seems to be, and how hard it turns out to be.

We all use DNS every day, and it seems really easy. The everyday language of DNS is: domain names, lookups, IP addresses. This language is exposed in browsers for all to see, and through this exposure we develop a mental model of how we think it works.

But under the covers there is a whole new language: zones, resolvers, delegated authority, that weird dot after the top-level domain...

Re: Why is DNS still hard to learn?

#79

One of the gotchas I encountered is that DNS is asynchronous, with possibly a long delay before reply. C apis make it look synchronous - which I think makes it harder to work with. There's also the detail that order of replies can be any. (I found too many developers expected synchronous and instant replies)

I remember the mid-90s when we were writing MUD servers and clients. You'd start the client, go "/world ZebraMUCK" and then the TUI would hang while the DNS name resolved.

So then we figured out asynchronous DNS (this was in the days when you linked with "-lresolv" on SunOS) and it was like a breath of fresh air! You could go "/world ZebraMUCK", control was returned to the keyboard, and even if it took 120 seconds to resolve zebramuck.nozebra.example.com, you could go about your business, like in another world, or issue some other client commands.

And client developers learned a little about select(3).

Re: Why is DNS still hard to learn?

#80
post #64

Earlier quoted context omitted.

I think it is hard to learn... using the tools people used to learn DNS with. BIND is great at what it does, but its configuration files suck and its manual is long, terse, and unnecessarily complex sometimes. Dig is powerful, but abbreviates everything like we're on an 80 column terminal. At times Wireshark was a better tool debugging DNS issues than Dig was. Give someone PowerDNS or another modern DNS server and I…

rcvd, qr, rd, ra are defined in the RFC. It need the abbreviation to fit in the ASCII art in RFC text. back in those days, dig users are those who read rfc

I can see that they were truncated in the block diagram, but they were also explained with one or two words just lines below that. RFC1035 calls them "query"/"response", "authoritative answer", "Truncation", "Recursion Desired", "Recursion Available", and CD/AD become "Checking Disabled" and "Authentic Data".

dig already translates things like record types from integers to strings, why not use the full, descriptive names for these flags as well? Why shouldn't I be able to dig +pretty domain.example?

I suppose dig is mostly maintenance mode these days, but it's quite annoying to see so many tools rely on it when it's so... 90s.

Post reply on HN