Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is DNS still hard to learn?

jvns.ca

Post reply on HN
Print view View original

221–230 of 261 posts

Re: Why is DNS still hard to learn?

#221

Post by mst »

alphager wrote: post #174
jeroenhd wrote: post #80

Earlier quoted context omitted.

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 n…

You've gut the nail on the head: dig was designed with the needs of the 90s in mind, where terseness was a virtue (if your ram can be usefully conveyed in kilobytes, you need terse tools). Due to backwards compatibility, the output won't be changed. Due to backwards compatibility, stuff is the tool that's installed by default. Both can't be changed (it would break too many assumptions many scripts and programs have).…

I liked jvns' suggestion to add a +human option - plenty of tools have a -h output option which is nicer for quick interactive use, and I value their existence (e.g. I use both 'du -h' and 'du -k' semi regularly depending on if I want to read the results or throw it through an analysis script).

Re: Why is DNS still hard to learn?

#222

Post by mst »

j16sdiz wrote: post #66
Terretta wrote: post #58

Earlier quoted context omitted.

> How did you learn DNS? And when? I wrote one of the world's first dynamic DNS servers for our dialup modem customers in the early 90s, so when connected to our Livingston Portmasters with an assigned IP address you could be username.isp.com while online. Later updated this so you could also be http://www.username.isp.com all the time just by dropping an index.html file in your ~username/site directory. I learned bo…

Same here. I implemented some dynamic dns system. I still remember how to handcraft a RRUPDATE request. After reading the RFC, every bit in dig output makes sense

It would, however, be nice if there was a tool (or, as jvns proposes, a +human option to dig) that provided output oriented to somebody who's just trying to -use- the thing rather than reading the RFC first.

(I'm very much a "read the RFC first by default" sort of person because that approach fits my brain, but I don't think everybody should have to do that for relatively simple day to day stuff)

Re: Why is DNS still hard to learn?

#224

Post by denton-scratch »

tristor wrote: 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…

I also don't agree with the article. Many aspects of sysadmin are far more difficult than DNS.

> the most common server and client implementations rigorously follow the standard

Not servers! in particular, many servers mess with the TTL (as author notes). It's not that these servers are defective; it's that the hostmaster has interfered with the configuration, presumably to reduce the load.

Re: Why is DNS still hard to learn?

#226

Post by txutxu »

jvns wrote: post #159
tristor wrote: 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…

Hello! I wrote this post and I have a couple of things to say about this "DNS is not actually hard" take. It took me many years to feel totally comfortable debugging DNS problems, and I wrote this post to explain why I think it was hard for me. I also used to think that "no, actually, it's easy!" was an encouraging response to "this is hard to learn". And I kind of get it! I love DNS! I think it is surprisingly simpl…

As always, thanks for the article (and the debate).

DNS itself, as an internet protocol, is "easy" in principle.

I did implement and maintain DNS services at the beginning of my career, for more than 200 customers, without any title and without help, except "the internet".

Everybody understands "you ask for a name, you get an address to connect as response", or "you can have more than one MX entry and play with the weight", "what is a TTL", etc.

But as every internet protocol... as soon as you add to the recipe: historical changes and more than one RFC, upgrades to the protocol, cryptography, different client and server implementations, vendors, operative systems and libraries (and versions), levels of compliance, software applications, misconfiguration, bugs, layers and more layers (inside client, reaching intermediate server(s), final server issues), cache!, enterprise interests (from client to server side) with a wild global (or local) positioning, government and agencies interests, ageing, innovation, all issues related to the long running opensource projects related to the protocol, all issues related to the "new is better" opensource projects (client and server) related to the protocol, user/developers/customers/managers asking (or assuming) impossible things or that there are no limitations, a long history (and a future one) of known attacks and known defenses or mitigations, response ordering (/etc/gai.conf), clients that implement from the last century /etc/hosts to mdns and avahi to nsswitch and ncsd, clients that act as servers (developed by enterprise bug creators)... you know... not easy anymore... things gonna be wild.

If there are complementary protocols, let's multiply the complexity: for DNS issues, there is also domain registration issues, whois, DHCP, VPNs, intermediate firewalls, rate limits, anycast, replication, IP, ARP...

With any internet protocol, or anything related to computers:

1) While it works, it's fine (and everybody is happy)

2) While we get an issue previously seen, understood and fixed, it's still calm

3) While we get an issue that we can quickly search by symptoms and fix, maybe ok

The "not easy" comes after that.

When we get a new and unknown problem, a weird issue, unexpected things, and there are 20 or 30 possibly failing actors around the protocol, or XX involved parts.

Recently I did a written breakdown of all things related to DNS in the "strace -y -yy -fq -v nc -vz google.com 80" in a linux laptop, and many people at work was surprised of all the things that happen there, inside the "give me the IP" step locally.

We could say exactly the same against any issue related to any internet protocol:

HTTP? it's easy or hard

Depends. It's easy to explain in a sentence what it does.

But you don't want to be the guy fixing issues against a float of load balancers used by all the customers, with a legacy (non compliant) device from a high priority customer at 4 A.M. oncall.

Re: Why is DNS still hard to learn?

#227

Post by vasco »

saghm wrote: post #175
anyfoo wrote: post #166

Earlier quoted context omitted.

Maybe everyone sees this differently? Or maybe is more than one viewpoint to it. For example, if someone tells me that something is "actually really simple", and I did not get it yet, I tend to think that I likely (not certainly, but likely) have not found the right approach to that something yet, and once I found that way to look at it, things will resolve itself. But if people assure me that something is "hard to l…

> Maybe everyone sees this differently? Or maybe is more than one viewpoint to it. > For example, if someone tells me that something is "actually really simple", and I did not get it yet, I tend to think that I likely (not certainly, but likely) have not found the right approach to that something yet, and once I found that way to look at it, things will resolve itself. At least in my experience, people asserting that…

> anyone could do it by just putting in the work, it's not surprising that people might interpret that as implying that people who don't have the same knowledge are either too lazy to put in the effort or not capable of it

Not spending time on something doesn't mean you're lazy or stupid, that seems like your own leap. If you choose to interpret in a charitable way it just says: "if you haven't looked here don't worry, it's not that hard, you'll just need to spend some time".

I haven't looked under many rocks I've walked by, talked to everyone, read every book I encountered, doesn't mean I'm stupid or lazy, I just haven't done it.

Re: Why is DNS still hard to learn?

#228

Post by maccard »

emmelaich wrote: post #198
jvns wrote: post #159

Earlier quoted context omitted.

Hello! I wrote this post and I have a couple of things to say about this "DNS is not actually hard" take. It took me many years to feel totally comfortable debugging DNS problems, and I wrote this post to explain why I think it was hard for me. I also used to think that "no, actually, it's easy!" was an encouraging response to "this is hard to learn". And I kind of get it! I love DNS! I think it is surprisingly simpl…

My own hassles with DNS, some of which are mentioned. 1. windows and apache httpd and others cache things for a long time, seemingly forever. 2. The 'A' record is used in case of missing MX records. Who knew that? 3. (in the olden days) confusion with winbios and other naming schemes 4. The defn of 'authoritative' 5. the misleading semantics of 'domain' in resolv.conf 6. (minor) the casual use of CNAME to mean alias,…

DNS's caching behaviour in the wild is incredibly infuriating. We have one team member at my company who is stuck with a stale DNS record for one of our internal services in our application, but their browser works just fine. I've absolutely no idea how to actually fix it, so for that one persons benefit we bought a whole new domain and ported everything to that.

Split DNS has let us do some cool things, and simultaneously caused no end of headaches. See above for the sorts of headaches.

Re: Why is DNS still hard to learn?

#229

Post by chefandy »

chefandy wrote: post #206
dahfizz wrote: post #133

Earlier quoted context omitted.

I disagree. The CLI is inherently a super-user oriented interface. The CLI needs to let an experienced user be as productive as possible. If you need a pretty UI with everything spelled out, you should go on GitHub and find a GUI that someone built on top of the core tool. But dumbing down the core tool is not the way to go. The --help message should be good, and the man page needs to be good, but the tool itself sho…

A) dumbed-down interfaces are bad design; Most you see were made by developees trying to be designy. No shade— it's a different profession with relevant degrees and career paths, and most designers would make terrible code if they tried. B) Good interface design absolutely does not require a gui. I've been professionally using (and loving) these tips for decades, but many cross the border from negligent to user hosti…

*Loving these tools for decades

Re: Why is DNS still hard to learn?

#230

Post by chefandy »

sdf4j wrote: post #151
dahfizz wrote: post #133

Earlier quoted context omitted.

I disagree. The CLI is inherently a super-user oriented interface. The CLI needs to let an experienced user be as productive as possible. If you need a pretty UI with everything spelled out, you should go on GitHub and find a GUI that someone built on top of the core tool. But dumbing down the core tool is not the way to go. The --help message should be good, and the man page needs to be good, but the tool itself sho…

I disagree. I'm a super-user and as such I have to use hundreds of tools to GTD. What you call “pretty UI” I call ergonomics. So I appreciate when the tooling is respectful of my time and don’t require me to visit the man page just because the developer was so situational myopic that thought sparing a few characters was a good idea. It all smells like unconscious gatekeeping.

Right. There USED to be good reasons to have that be the way classic CLI utilities worked— your terminal had 80 character lines, you might be working over a 300 baud modem, you might be using a teletype terminal and you didn't want to waste paper, having machine-focused output and human-focused output was too resource Intensive... All of that is gone now.
Post reply on HN