10 ms·

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 abou

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 dig). It's always been a big surprise to me that my DNS expertise is what seems to be most memorable for a lot of folks I've worked with through my career, when I don't believe I know anything mystical or special. DNS is extremely well standardized, the most common server and client implementations rigorously follow the standard, and it's very easy to inspect with free tooling. It just takes some effort and time to learn, but it's not really hard.

jeroenhd 3y ago
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 think they'll have a much better time configuring a working DNS server. I don't know a good modern DNS client, so I've learned to deal with Dig instead. As a user of the "--color" flag for the `ip` command, I'd love to see tools like dig produce more modern output (I'll alias the command line flags, just add it to the command!) Seriously, "MSG SIZE rcvd: 71" did not need abbreviation. "flags: qr rd ra" could've been full words as well. I don't know what the semicolons before the lines are supposed to convey but they're only making things confusing. I find it no wonder people get confused learning DNS with the materials provided to them.
- knome 3y ago
  >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 shell script 20 years and more ago to grab a list of IPs to do some domain's health check or whatever Not that you would want to in any modern stack. obviously you'd just use dig's `+short` option :)
  - jeroenhd 3y ago
    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).
    - dclowd9901 3y ago
      Perhaps there is info that would normally be present and isn’t, hence stacked semicolons.
      - skrebbel 3y ago
        A precision engineering tool shouldn’t make its users guess like that.
        dclowd9901 3y ago
        Totally agree.
  - deleted 3y ago
    [deleted]
  - tux1968 3y ago
    > dig google.com | grep -v '^;' | grep . | awk '{ print $5 }'` It wasn't really your point, but hopefully you'll forgive me sharing an equivalent one-liner, without grep: dig google.com | awk '/./ && !/^;/ {print $5}'
    - redundantly 3y ago
      I believe both you and the parent meant to escape the dot, as to only return lines with a dot in them: dig example.com | awk '/\./ && !/^;/ {print $5}' If it isn't escaped it'll just match on everything. If matching everything was intended then you don't need it at all: dig example.com | awk '!/^;/ {print $5}' Will strip out the lines beginning with a semi-colon. However, parsing the output of `dig` this way is not needed. It can be ran to only return the answer, for example: dig +noall +answer example.com Or if you just want the IP for that record: dig +short example.com
- chefandy 3y ago
  I'd conservatively estimate 90% of the people who make core FOSS software interface decisions haven't had to learn anything technical in an entirely unfamiliar domain where there existing mental models didn't apply in decades. Beyond that, many consider having learned these arbitrary, terse interfaces as a badge of honor, and for some reason thinks that makes them better technologists. I'll bet they'd be even better had they been able to focus on the core concepts rather than trying to get into some systems engineer's head who worked at Berkley in 1984.
  - TheNewsIsHere 3y ago
    I think of this in the same way I think of documentation. I try to write documentation that is as clear as it is concise and well structured. But sometimes that’s just not realistically possible, and expressing information often _has_ to assume some level of familiarity with the underlying concepts. I’ve never considered DNS to be a complicated technology, and I’ve never considered that tools like dig and the abbreviations they use need to change much. If there’s something that isn’t clear, it’ll be in the man page, a mailing list, Internet based documentation, StackOverflow, etc. Personally, I value information density, and I don’t mind terseness at all. That doesn’t necessarily mean I would design some of this stuff the same way, but after more than a decade using it, I feel like changing it now is just an appeal to futility. A tool like dig more or less looks and works the same today as it did 15 years ago, and there’s value in that kind of stability.
    - chefandy 3y ago
      > but after more than a decade using it, I feel like changing it now is just an appeal to futility And that's why your learning to use these tools a decade ago was as painful as it was for me 20+ years ago, and so on. Nobody improves it because the only people with the clout to make the changes is too set in their ways to change it, and have come to believe the ridiculous notion that it's beneficial for people to learn it, despite not being related to the actual problem. I worked in technical roles for the better part of 25 years, including 10 as a back end developer. One of the reasons I got into design was to try and break chains like this, but talking to the FOSS community about design gets nearly zero traction and a whole lot of pushback from folks who think they know a lot more about design than they do. Nothing you do matches the information density of a train schedule in a large city, and those designs are so ubiquitous and intuitive that we take them for granted. That was not always the case— someone decided to lay things out like that at some point because they knew it works be easier and more intuitive for the majority even if it might take some adjustment for existing everyday users. And designers still work to make them better, to this day. I wrote a tutorial teaching non-technical folks to use a rest API. It required no knowledge beyond familiarity with using web browsers, and ended with people making useful queries with curl. It was short, visual, and effective- I learned that multiple non-profits at the time used it in their materials to teach folks technical literacy. Just because using a bunch of terse jargon is easier for developers to write and acceptable for other developers to read doesn't mean it's optimal... Or even good. Especially when the realm world be much more accessible to non-technical people if it was designed better.
- j16sdiz 3y ago
  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
  - jeroenhd 3y ago
    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.
    - bombcar 3y ago
      >I just don't mess with DNS often enough That's the root of all this, we only deal with DNS when something breaks, and it rarely breaks. If we did DNS all day every day it'd all be super clear and concise.
      - mst 3y ago
        I learned DNS a bit over 20 years ago running a BIND deployment that was authoritative for somewhere over 30k customer domains. I still tend to use nslookup over dig (yes, I know, bad mst) because I got sufficiently used to the former that I barely notice it's even there when using it - my fingers and brain are so used to it that the interface part of nslookup is mentally invisible (though I always teach other people 'dig' and 'host' instead). I'm not sure learning it that way was exactly easier, but being (somewhat, that was far from the only service I was responsible for) immersed in it meant I at least got through the initial mental scrabbling in a relatively compressed time frame, and once you've got a coherent model built in your head life is easier. I think this is really a very long way to say "based on doing DNS most days for a few years, I strongly suspect you're right."
        3y ago
- j16sdiz 3y ago
  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
  - jeroenhd 3y ago
    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.
    - alphager 3y ago
      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). However, there are multiple dig alternatives. You just have to install them.
      - mst 3y ago
        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).
- zehemer 3y ago
  > As a user of the "--color" flag for the `ip` command, I'd love to see tools like dig produce more modern output https://github.com/ogham/dog https://github.com/ogham/dog is pretty good in that regard
  - zhfliz 3y ago
    wow, didn't know about `ip --color`, that's awesome
- manuel_w 3y ago
  $ ip address --color Command "--color" is unknown, try "ip address help".
  - matteotom 3y ago
    try > ip --color address otherwise you might just have an old version
    - manuel_w 3y ago
      That helped, thanks!
    - synergy20 3y ago
      or: ip -c -br a which is: ip --color --brief address add -4 if only ipv4
  - mst 3y ago
    Some CLI apps with subcommands accept top level options anywhere in the arguments, some - like 'ip' - expect <command> <command options> <subcommand name> <subcommand options> <arguments> The advantage of that approach is that you don't have to worry about naming collisions between the command and subcommand option sets, which can be really handy - especially in applications with pluggable and/or user supplied subcommands, so you can add top level options without worrying about breaking somebody else's extensions. The disadvantage is, well, what just happened to you. (note that I personally really like the pedantic approach because it fits my brain, but I'm -not- trying to endorse it as better in general since it's very definitely a trade-off and one that often isn't a good one overall)
- dataflow 3y ago
  To the extent I learned DNS, it was via nslookup, definitely not dig.
- firexcy 3y ago
  I think old CLI tools are hard to use because they were designed to be machine- and human-readable at the same time. They are effectively APIs in some scenarios (e.g., scripting and as linked libraries) and in others handholds. As a result they are restricted to be barely viable as either.
neilk 3y ago
How did you learn DNS? And when?
- Terretta 3y ago
  > 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 http://www.username.isp.com all the time just by dropping an index.html file in your ~username/site directory. I learned both by spelunking BSD, reading man pages, and rapid prototyping in Perl. So I'm with tristor, it felt relatively straightforward. // I don't say I wrote the first because I don't know. I am not aware of any other regional or national commercial dialup ISP in the U.S. that offered this before we did.
  - j16sdiz 3y ago
    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
    - mst 3y ago
      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)
- tristor 3y ago
  I had a slow day at work in the beginning of my career (I was a help desk monkey then) and I wanted to learn more about how Active Directory actually worked. One of the things that I found out and became more curious about was why DNS was so critical for Active Directory, upon where I discovered the magic of SRV records. After that I decided I wanted to learn DNS in detail, so I read the RFCs, poked around with nslookup and dig, and then set up a local copy of BIND on a Linux VM to experiment with. In the numerous intervening years I've picked up more over time and been involved in numerous situations where I had to assist someone by doing DNS spelunking, often learning something in the process. I jumped from being a help desk monkey to being an L2 sysadmin in my very next job largely on the basis of my DNS and Active Directory knowledge, all of which was learned by reading documentation and poking at things, nothing particularly difficult about either. What always causes challenges is weird edge cases, but if you understand how things are supposed to work at a protocol level you have the basis of knowledge to troubleshoot the edge cases, which is how you learn about the more esoteric or implementation specific behaviors of things. I wouldn't expect anyone to particularly have deep knowledge of AD or DNS edge cases, but the basics of how they work aren't particularly hard knowledge to acquire and it's a constant surprise to me how few tech people understand DNS in particular, since it's a critical system for nearly every aspect of modern computing. As far as resources, when learning these things way back when I only used the official Microsoft documentation, the RFCs, man pages, and sites like nixCraft to learn about it. These same resources still exist (although Google sucks now and makes anything decent hard to find), and these protocols have changed very little in the intervening nearly 20 years, so I don't think it's any harder for folks to learn today than it was for me back then. This stuff is very literally not rocket science, DNS is an extremely basic protocol. In fact, nearly all its weird edge cases is because it's such a basic protocol that some behavior isn't clearly defined, however /most/ behavior is. It's very nearly all text on the wire, and all of the zone records, queries, and responses are human readable. As someone else mentioned, you can just use Wireshark and learn about DNS. It's inspectable on the wire, not just through tooling. FWIW, Active Directory is far more difficult to learn in detail than DNS, largely because Kerberos is deeply complex, and Active Directory has many unique complexities (like how FSMO roles work). DNS in comparison to most other things you are expected to know as even a semi-competent systems administrators / SRE is mindbogglingly simple.
Vaslo 3y ago
You have the curse of knowledge my friend. It’s hard to learn and way more complicated than it needs to be.
dogleash 3y ago
> I think DNS is something few people take the time to learn I kinda agree and think DNS one of those technologies where you can go an entire career without picking up more than bits and peices here and there. Those things gains a sense of mystique in industry as more complicated than it otherwise would if more people had to tackle it full on.
- WarOnPrivacy 3y ago
  > I kinda agree and think DNS one of those technologies where you can go an entire career without picking up more than bits and peices here and there. As far as that's true it's weird, because DNS basically does one straightforward thing. But then you get into all the places where that one thing has to be done in different ways. Where I wouldn't mind some more magic is with reverse DNS. Too many tables don't know a name pointing to an IP until something tries to resolve that name. Reliably historical rdns would be even more awesome but that's more of a service than a spec thing.
josho 3y ago
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?
- antonjs 3y ago
  And does your browser have settings which bypass or supplement the host's DNS configuration. Secure DNS (DoH etc) is great, but damn that's confusing when you first run across it. Not to mention how phones do it; you can't override a DoH DNS server when connecting to a VPN which offers internal DNS on Android, for instance.
  - TheNewsIsHere 3y ago
    Aren’t all of those concerns out of scope for DNS itself, though? DNS can only give you a TTL, for example, it cannot require you follow it. Ideally that’s what RFCs are for, but even organizations that pay smart people to come up with clever standards don’t always follow them. Implementations frequently disregard or guess about the things standards cover.
    - tikhonj 3y ago
      From the point of view of the standard, maybe, but not from the point of view of somebody learning or using DNS.
      - TheNewsIsHere 3y ago
        I don’t disagree, and I think that’s why we need to make it clear that there’s a difference between implementation and standard. My education is a mix of formal and autodidactic. One of the best things I got from formal education is the structured introduction to fundamentals like the OSI model. If you don’t have that kind of foundation, it can be much, much harder to understand the “why” of the endless differences between documented standards and in-the-wild implementations. It’s good to know where you are in the stack to help inform what you’re seeing.
f1shy 3y ago
Absolutely agree. Back in the days, I was very inexperienced, I was thrown to the task of administering DNS (with BIND) and Sendmail. I had 100+ servers. The first couple of month was a lot of reading, and understanding things, but relatively fast I got a good understanding of it. After 6 month I was teaching DNS to other teams in other countries for the same company. It was not at all hard. I'm a very average engineer, and from 0 to explaining to others in 6 month, is by no means a difficult topic.
- pessimizer 3y ago
  DNS isn't at all hard, it only takes two months to learn when you're being paid to, and after only 6 months you'll be knowledgeable enough to teach! > from 0 to explaining to others in 6 month, is by no means a difficult topic. You should have seen almost anything else. Many things can be learned within days.
jvns 3y ago
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 simple in many ways, and I've written about that a lot, for example in https://implement-dns.wizardzines.com https://implement-dns.wizardzines.com which shows you how to implement a toy DNS resolver from scratch in some pretty simple Python code. But over the years I've learned that "no, it's easy to learn!", instead of coming off as an encouraging comment ("you can do it!"), often gets received as "no, it's not hard, actually the problem is that you're dumb". Like, I've been confused about this for years, and you're telling me that, no, actually it's easy? Not that helpful! So I've stopped telling people that, and instead I put a huge amount of work into trying to understand _why_ people find certain things hard and work to help remove some of those barriers.
- anyfoo 3y ago
  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 learn" or "hard to get", I'm rather suspecting that that thing is full of unwieldy complexity and/or unintuitive aspects, and unless I'm either up for the challenge (definitely the case sometimes), or learning it is crucial for achieving a certain goal (in which case it may turn out to be fun after all, even if still hard), I might think twice if I want to put the time and energy into it. In the case of DNS, which I've learned in the nineties, I found the principle simple and elegant, the tools and software unwieldy and sometimes arcane, and a large multitude of little details that are not strictly necessary for understanding and using DNS in basic ways, but that can get important when either debugging or working at scale. So, in the case of DNS, I'd say the answer is "depends on how deep you want to go", but don't shy away from the simple and elegant principle, even if the arcane software (it has gotten better, though) stands in the way. I think that matches the content of your article overall?
acheron 3y ago
I wish I had jobs where people cared that I knew DNS.
Aeolun 3y ago
DNS itself is easy to learn. Trying to figure out why domain x doesn’t resolve to ip y is a hard problem. Like the article points out, there’s so many layers of potential caches in between you starting a lookup and that lookup being resolved.
temporallobe 3y ago
Likewise, a lot of people know (and use) me for my supposedly deep knowledge of Git, even though it took me years to fully understand and feel comfortable enough with it so that I’m no longer terrified when using the CLI — I can cherry-pick and rebase with the best of them. YET, I still feel it’s a bit intimidating and that there’s some mysteries behind the internals I don’t fully grasp. I suppose like DNS, it does take time and effort to learn, and when I really think about it, it’s actually not that hard, but for some reason, so many devs struggle with it, mostly (front what I’ve observed) because it’s intimidating due to o it’s somewhat odd terminology and unintuitive workflow, but also because there are so many GUI/IDE tools that hide a lot of the complexity, which simultaneously good and bad.
mekoka 3y ago
> I don't agree with this article. But you address none of the article's points. You're basically disagreeing with the title. And I'd say that your answer seems to conflate DNS is hard and DNS is hard to learn. > It just takes some effort and time to learn. How much effort, how much time? Many people in these threads say that they learned by implementing a server. Some mention that it only took them some months to grasp, but then just echo in unison that "once you understand it, it's actually pretty easy". So can we agree that for something as ubiquitous and conceptually simple, it's actually hard to learn?
kmoser 3y ago
> I think DNS is something few people take the time to learn, but it's not actually hard to learn. Hard disagree. For me, DNS is like doing taxes: I touch it once a year or so, find it Byzantine, know enough to be dangerous, but am always frustrated that I don't use it often enough to remember exactly how to configure things without having to consult poorly written and/or overly technical tutorials. I'd like to see a better version of web-based tools like mxtoolbox.com that will analyze DNS records, let you know what's wrong, and give you actual examples of what settings you need for things like DMARC/DKIM/SPF records. In my experience, online tutorials for setting them up come tantalizingly close to giving me what I need, but I often end up getting stuck with the last few details (usually the weird punctuation required) because, again, I touch this stuff so infrequently I just don't remember from one time to the next. Ideally I'd want a form-based tool that gives you drop-downs to select from and, when submitted, just gives you the actual record you need.
denton-scratch 3y ago
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.
lazyant 3y ago
DNS _protocol_ and _servers_ are conceptually easy. In practice, the implementations and what actually happens is not. When you type google.com in your browser, do you know exactly the workflow in your computer and the different caches it uses (browser, OS etc) and how they work? Do you know which Linux tools use gethostbyname vs getaddrinfo and why they could give different results?

jeroenhd 3y ago

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 think they'll have a much better time configuring a working DNS server. I don't know a good modern DNS client, so I've learned to deal with Dig instead. As a user of the "--color" flag for the `ip` command, I'd love to see tools like dig produce more modern output (I'll alias the command line flags, just add it to the command!) Seriously, "MSG SIZE rcvd: 71" did not need abbreviation. "flags: qr rd ra" could've been full words as well. I don't know what the semicolons before the lines are supposed to convey but they're only making things confusing. I find it no wonder people get confused learning DNS with the materials provided to them.

knome 3y ago
>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 shell script 20 years and more ago to grab a list of IPs to do some domain's health check or whatever Not that you would want to in any modern stack. obviously you'd just use dig's `+short` option :)
- jeroenhd 3y ago
  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).
  - dclowd9901 3y ago
    Perhaps there is info that would normally be present and isn’t, hence stacked semicolons.
    - skrebbel 3y ago
      A precision engineering tool shouldn’t make its users guess like that.
      - dclowd9901 3y ago
        Totally agree.
- deleted 3y ago
  [deleted]
- tux1968 3y ago
  > dig google.com | grep -v '^;' | grep . | awk '{ print $5 }'` It wasn't really your point, but hopefully you'll forgive me sharing an equivalent one-liner, without grep: dig google.com | awk '/./ && !/^;/ {print $5}'
  - redundantly 3y ago
    I believe both you and the parent meant to escape the dot, as to only return lines with a dot in them: dig example.com | awk '/\./ && !/^;/ {print $5}' If it isn't escaped it'll just match on everything. If matching everything was intended then you don't need it at all: dig example.com | awk '!/^;/ {print $5}' Will strip out the lines beginning with a semi-colon. However, parsing the output of `dig` this way is not needed. It can be ran to only return the answer, for example: dig +noall +answer example.com Or if you just want the IP for that record: dig +short example.com
chefandy 3y ago
I'd conservatively estimate 90% of the people who make core FOSS software interface decisions haven't had to learn anything technical in an entirely unfamiliar domain where there existing mental models didn't apply in decades. Beyond that, many consider having learned these arbitrary, terse interfaces as a badge of honor, and for some reason thinks that makes them better technologists. I'll bet they'd be even better had they been able to focus on the core concepts rather than trying to get into some systems engineer's head who worked at Berkley in 1984.
- TheNewsIsHere 3y ago
  I think of this in the same way I think of documentation. I try to write documentation that is as clear as it is concise and well structured. But sometimes that’s just not realistically possible, and expressing information often _has_ to assume some level of familiarity with the underlying concepts. I’ve never considered DNS to be a complicated technology, and I’ve never considered that tools like dig and the abbreviations they use need to change much. If there’s something that isn’t clear, it’ll be in the man page, a mailing list, Internet based documentation, StackOverflow, etc. Personally, I value information density, and I don’t mind terseness at all. That doesn’t necessarily mean I would design some of this stuff the same way, but after more than a decade using it, I feel like changing it now is just an appeal to futility. A tool like dig more or less looks and works the same today as it did 15 years ago, and there’s value in that kind of stability.
  - chefandy 3y ago
    > but after more than a decade using it, I feel like changing it now is just an appeal to futility And that's why your learning to use these tools a decade ago was as painful as it was for me 20+ years ago, and so on. Nobody improves it because the only people with the clout to make the changes is too set in their ways to change it, and have come to believe the ridiculous notion that it's beneficial for people to learn it, despite not being related to the actual problem. I worked in technical roles for the better part of 25 years, including 10 as a back end developer. One of the reasons I got into design was to try and break chains like this, but talking to the FOSS community about design gets nearly zero traction and a whole lot of pushback from folks who think they know a lot more about design than they do. Nothing you do matches the information density of a train schedule in a large city, and those designs are so ubiquitous and intuitive that we take them for granted. That was not always the case— someone decided to lay things out like that at some point because they knew it works be easier and more intuitive for the majority even if it might take some adjustment for existing everyday users. And designers still work to make them better, to this day. I wrote a tutorial teaching non-technical folks to use a rest API. It required no knowledge beyond familiarity with using web browsers, and ended with people making useful queries with curl. It was short, visual, and effective- I learned that multiple non-profits at the time used it in their materials to teach folks technical literacy. Just because using a bunch of terse jargon is easier for developers to write and acceptable for other developers to read doesn't mean it's optimal... Or even good. Especially when the realm world be much more accessible to non-technical people if it was designed better.
j16sdiz 3y ago
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
- jeroenhd 3y ago
  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.
  - bombcar 3y ago
    >I just don't mess with DNS often enough That's the root of all this, we only deal with DNS when something breaks, and it rarely breaks. If we did DNS all day every day it'd all be super clear and concise.
    - mst 3y ago
      I learned DNS a bit over 20 years ago running a BIND deployment that was authoritative for somewhere over 30k customer domains. I still tend to use nslookup over dig (yes, I know, bad mst) because I got sufficiently used to the former that I barely notice it's even there when using it - my fingers and brain are so used to it that the interface part of nslookup is mentally invisible (though I always teach other people 'dig' and 'host' instead). I'm not sure learning it that way was exactly easier, but being (somewhat, that was far from the only service I was responsible for) immersed in it meant I at least got through the initial mental scrabbling in a relatively compressed time frame, and once you've got a coherent model built in your head life is easier. I think this is really a very long way to say "based on doing DNS most days for a few years, I strongly suspect you're right."
      - 3y ago
j16sdiz 3y ago
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
- jeroenhd 3y ago
  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.
  - alphager 3y ago
    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). However, there are multiple dig alternatives. You just have to install them.
    - mst 3y ago
      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).
zehemer 3y ago
> As a user of the "--color" flag for the `ip` command, I'd love to see tools like dig produce more modern output https://github.com/ogham/dog https://github.com/ogham/dog is pretty good in that regard
- zhfliz 3y ago
  wow, didn't know about `ip --color`, that's awesome
manuel_w 3y ago
$ ip address --color Command "--color" is unknown, try "ip address help".
- matteotom 3y ago
  try > ip --color address otherwise you might just have an old version
  - manuel_w 3y ago
    That helped, thanks!
  - synergy20 3y ago
    or: ip -c -br a which is: ip --color --brief address add -4 if only ipv4
- mst 3y ago
  Some CLI apps with subcommands accept top level options anywhere in the arguments, some - like 'ip' - expect <command> <command options> <subcommand name> <subcommand options> <arguments> The advantage of that approach is that you don't have to worry about naming collisions between the command and subcommand option sets, which can be really handy - especially in applications with pluggable and/or user supplied subcommands, so you can add top level options without worrying about breaking somebody else's extensions. The disadvantage is, well, what just happened to you. (note that I personally really like the pedantic approach because it fits my brain, but I'm -not- trying to endorse it as better in general since it's very definitely a trade-off and one that often isn't a good one overall)
dataflow 3y ago
To the extent I learned DNS, it was via nslookup, definitely not dig.
firexcy 3y ago
I think old CLI tools are hard to use because they were designed to be machine- and human-readable at the same time. They are effectively APIs in some scenarios (e.g., scripting and as linked libraries) and in others handholds. As a result they are restricted to be barely viable as either.

neilk 3y ago

How did you learn DNS? And when?

Terretta 3y ago
> 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 http://www.username.isp.com all the time just by dropping an index.html file in your ~username/site directory. I learned both by spelunking BSD, reading man pages, and rapid prototyping in Perl. So I'm with tristor, it felt relatively straightforward. // I don't say I wrote the first because I don't know. I am not aware of any other regional or national commercial dialup ISP in the U.S. that offered this before we did.
- j16sdiz 3y ago
  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
  - mst 3y ago
    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)
tristor 3y ago
I had a slow day at work in the beginning of my career (I was a help desk monkey then) and I wanted to learn more about how Active Directory actually worked. One of the things that I found out and became more curious about was why DNS was so critical for Active Directory, upon where I discovered the magic of SRV records. After that I decided I wanted to learn DNS in detail, so I read the RFCs, poked around with nslookup and dig, and then set up a local copy of BIND on a Linux VM to experiment with. In the numerous intervening years I've picked up more over time and been involved in numerous situations where I had to assist someone by doing DNS spelunking, often learning something in the process. I jumped from being a help desk monkey to being an L2 sysadmin in my very next job largely on the basis of my DNS and Active Directory knowledge, all of which was learned by reading documentation and poking at things, nothing particularly difficult about either. What always causes challenges is weird edge cases, but if you understand how things are supposed to work at a protocol level you have the basis of knowledge to troubleshoot the edge cases, which is how you learn about the more esoteric or implementation specific behaviors of things. I wouldn't expect anyone to particularly have deep knowledge of AD or DNS edge cases, but the basics of how they work aren't particularly hard knowledge to acquire and it's a constant surprise to me how few tech people understand DNS in particular, since it's a critical system for nearly every aspect of modern computing. As far as resources, when learning these things way back when I only used the official Microsoft documentation, the RFCs, man pages, and sites like nixCraft to learn about it. These same resources still exist (although Google sucks now and makes anything decent hard to find), and these protocols have changed very little in the intervening nearly 20 years, so I don't think it's any harder for folks to learn today than it was for me back then. This stuff is very literally not rocket science, DNS is an extremely basic protocol. In fact, nearly all its weird edge cases is because it's such a basic protocol that some behavior isn't clearly defined, however /most/ behavior is. It's very nearly all text on the wire, and all of the zone records, queries, and responses are human readable. As someone else mentioned, you can just use Wireshark and learn about DNS. It's inspectable on the wire, not just through tooling. FWIW, Active Directory is far more difficult to learn in detail than DNS, largely because Kerberos is deeply complex, and Active Directory has many unique complexities (like how FSMO roles work). DNS in comparison to most other things you are expected to know as even a semi-competent systems administrators / SRE is mindbogglingly simple.

Vaslo 3y ago

You have the curse of knowledge my friend. It’s hard to learn and way more complicated than it needs to be.

dogleash 3y ago

> I think DNS is something few people take the time to learn I kinda agree and think DNS one of those technologies where you can go an entire career without picking up more than bits and peices here and there. Those things gains a sense of mystique in industry as more complicated than it otherwise would if more people had to tackle it full on.

WarOnPrivacy 3y ago
> I kinda agree and think DNS one of those technologies where you can go an entire career without picking up more than bits and peices here and there. As far as that's true it's weird, because DNS basically does one straightforward thing. But then you get into all the places where that one thing has to be done in different ways. Where I wouldn't mind some more magic is with reverse DNS. Too many tables don't know a name pointing to an IP until something tries to resolve that name. Reliably historical rdns would be even more awesome but that's more of a service than a spec thing.

josho 3y ago

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?

antonjs 3y ago
And does your browser have settings which bypass or supplement the host's DNS configuration. Secure DNS (DoH etc) is great, but damn that's confusing when you first run across it. Not to mention how phones do it; you can't override a DoH DNS server when connecting to a VPN which offers internal DNS on Android, for instance.
- TheNewsIsHere 3y ago
  Aren’t all of those concerns out of scope for DNS itself, though? DNS can only give you a TTL, for example, it cannot require you follow it. Ideally that’s what RFCs are for, but even organizations that pay smart people to come up with clever standards don’t always follow them. Implementations frequently disregard or guess about the things standards cover.
  - tikhonj 3y ago
    From the point of view of the standard, maybe, but not from the point of view of somebody learning or using DNS.
    - TheNewsIsHere 3y ago
      I don’t disagree, and I think that’s why we need to make it clear that there’s a difference between implementation and standard. My education is a mix of formal and autodidactic. One of the best things I got from formal education is the structured introduction to fundamentals like the OSI model. If you don’t have that kind of foundation, it can be much, much harder to understand the “why” of the endless differences between documented standards and in-the-wild implementations. It’s good to know where you are in the stack to help inform what you’re seeing.

f1shy 3y ago

Absolutely agree. Back in the days, I was very inexperienced, I was thrown to the task of administering DNS (with BIND) and Sendmail. I had 100+ servers. The first couple of month was a lot of reading, and understanding things, but relatively fast I got a good understanding of it. After 6 month I was teaching DNS to other teams in other countries for the same company. It was not at all hard. I'm a very average engineer, and from 0 to explaining to others in 6 month, is by no means a difficult topic.

pessimizer 3y ago
DNS isn't at all hard, it only takes two months to learn when you're being paid to, and after only 6 months you'll be knowledgeable enough to teach! > from 0 to explaining to others in 6 month, is by no means a difficult topic. You should have seen almost anything else. Many things can be learned within days.

jvns 3y ago

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 simple in many ways, and I've written about that a lot, for example in https://implement-dns.wizardzines.com https://implement-dns.wizardzines.com which shows you how to implement a toy DNS resolver from scratch in some pretty simple Python code. But over the years I've learned that "no, it's easy to learn!", instead of coming off as an encouraging comment ("you can do it!"), often gets received as "no, it's not hard, actually the problem is that you're dumb". Like, I've been confused about this for years, and you're telling me that, no, actually it's easy? Not that helpful! So I've stopped telling people that, and instead I put a huge amount of work into trying to understand _why_ people find certain things hard and work to help remove some of those barriers.

anyfoo 3y ago
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 learn" or "hard to get", I'm rather suspecting that that thing is full of unwieldy complexity and/or unintuitive aspects, and unless I'm either up for the challenge (definitely the case sometimes), or learning it is crucial for achieving a certain goal (in which case it may turn out to be fun after all, even if still hard), I might think twice if I want to put the time and energy into it. In the case of DNS, which I've learned in the nineties, I found the principle simple and elegant, the tools and software unwieldy and sometimes arcane, and a large multitude of little details that are not strictly necessary for understanding and using DNS in basic ways, but that can get important when either debugging or working at scale. So, in the case of DNS, I'd say the answer is "depends on how deep you want to go", but don't shy away from the simple and elegant principle, even if the arcane software (it has gotten better, though) stands in the way. I think that matches the content of your article overall?

acheron 3y ago

I wish I had jobs where people cared that I knew DNS.

Aeolun 3y ago

DNS itself is easy to learn. Trying to figure out why domain x doesn’t resolve to ip y is a hard problem. Like the article points out, there’s so many layers of potential caches in between you starting a lookup and that lookup being resolved.

temporallobe 3y ago

Likewise, a lot of people know (and use) me for my supposedly deep knowledge of Git, even though it took me years to fully understand and feel comfortable enough with it so that I’m no longer terrified when using the CLI — I can cherry-pick and rebase with the best of them. YET, I still feel it’s a bit intimidating and that there’s some mysteries behind the internals I don’t fully grasp. I suppose like DNS, it does take time and effort to learn, and when I really think about it, it’s actually not that hard, but for some reason, so many devs struggle with it, mostly (front what I’ve observed) because it’s intimidating due to o it’s somewhat odd terminology and unintuitive workflow, but also because there are so many GUI/IDE tools that hide a lot of the complexity, which simultaneously good and bad.

mekoka 3y ago

> I don't agree with this article. But you address none of the article's points. You're basically disagreeing with the title. And I'd say that your answer seems to conflate DNS is hard and DNS is hard to learn. > It just takes some effort and time to learn. How much effort, how much time? Many people in these threads say that they learned by implementing a server. Some mention that it only took them some months to grasp, but then just echo in unison that "once you understand it, it's actually pretty easy". So can we agree that for something as ubiquitous and conceptually simple, it's actually hard to learn?

kmoser 3y ago

> I think DNS is something few people take the time to learn, but it's not actually hard to learn. Hard disagree. For me, DNS is like doing taxes: I touch it once a year or so, find it Byzantine, know enough to be dangerous, but am always frustrated that I don't use it often enough to remember exactly how to configure things without having to consult poorly written and/or overly technical tutorials. I'd like to see a better version of web-based tools like mxtoolbox.com that will analyze DNS records, let you know what's wrong, and give you actual examples of what settings you need for things like DMARC/DKIM/SPF records. In my experience, online tutorials for setting them up come tantalizingly close to giving me what I need, but I often end up getting stuck with the last few details (usually the weird punctuation required) because, again, I touch this stuff so infrequently I just don't remember from one time to the next. Ideally I'd want a form-based tool that gives you drop-downs to select from and, when submitted, just gives you the actual record you need.

denton-scratch 3y ago

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.

lazyant 3y ago

DNS _protocol_ and _servers_ are conceptually easy. In practice, the implementations and what actually happens is not. When you type google.com in your browser, do you know exactly the workflow in your computer and the different caches it uses (browser, OS etc) and how they work? Do you know which Linux tools use gethostbyname vs getaddrinfo and why they could give different results?