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.

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 :)

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).

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}'

     dig example.com | awk '/\./ && !/^;/ {print $5}'

If matching everything was intended then you don't need it at all:

     dig example.com | awk '!/^;/ {print $5}'

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

     dig +short example.com

I could have combined `grep -v '^;'` and `grep .` as a nice simple `grep '^[^;]'`

However, it's still better to just have the `dig` command return only the necessary information via the +short or +noall +answer flags, rather than parsing the full output.

    The labels must follow the rules for ARPANET host names.  They must
    start with a letter, end with a letter or digit, and have as interior
    characters only letters, digits, and hyphen.  There are also some
    restrictions on the length.  Labels must be 63 characters or less.

it's more likely that in the late 90s they just made up their own argument parsing that they liked and the application has just used that ever since.

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.

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.

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 should favor power and productivity over handholding someone who doesn't want to Google a how-to.

Old-school FOSS nerds have a hard time admitting that they tend to be absolutely useless at considering user experience, because then that’s something On Computers that they’re not good at. The best they can do is shoo it away by claiming that the sort of UX concerns I’m talking about only apply to software used by Lesser Beings and not Smart Computer Boys such as themselves.

It’s such an outdated user-hostile boys club attitude fuelled by insecurity and misplaced and not even well-thought-out elitism, and I’ll never pull any punches when talking about it.

Yes it is. As an administrator being a CLI tool means that I can automate configs and deployment with ansible or Nix OS. I would argue doing these sorts of automation what are what “power-users” would do.

GUI’s often lack any sort of automation capability or have some half-cocked API that usually lacks features or endpoints that would be trivial if the thing was just a CLI tool with a config file.

Using sane labels and coherent layouts isn't dumbing anything down. You can make things easier for humans while having sane interfaces for scripting. Redirecting the output of `ls` and similar commands automatically change the layout to something easy for cli i/o manipulation.

We realized long long ago that the API and human-facing interfaces are often better when separated, which is why I don't browse the web with curl... or maybe telnet.

New-school FOSS nerds don't seem to understand that all poor user experience concerns are because we are trying to be productive. The new style of of reduced information density and easy-to-remember names isn't useful when you are paid to have production systems up and running. What I need are tools that give me the exact information I need quickly and get the fuck out of my way for everything else.

> It’s such an outdated user-hostile boys club attitude fuelled by insecurity and misplaced and not even well-thought-out elitism, and I’ll never pull any punches when talking about it.

Most people that complain about this put the minimal viable effort into actually learning what they are doing. Somehow I'm the idiot after spending hours of my life to learn this professionally and for wanting expert interfaces. You can call me elite all you like but when the whirlpool of disaster is pulling us both under, I'll be in my elite raft surfing the waves while you struggle.

> New-school FOSS nerds don't seem to understand that all poor user experience concerns are because we are trying to be productive. The new style of of reduced information density and easy-to-remember names isn't useful when you are paid to have production systems up and running.

The reason you find them more productive is because you already know how to use them. Needlessly reduced information density is usually a bandaid applied to a shitty, confusing interface by a non-designer because they don't know how to organize it to be easily parsable, but still dense. Maybe denser than before. You don't even realize when a good designer has done a good job because it just makes sense— it's so intuitive and useful to cite users that you don't have to think about it. If it it's a utilitarian tool that "looks designed," it was probably a non-designer trying to gussy it up, or "work on UX" without realizing that means a lot more than white space, colors, and fonts. A solid understanding of visual hierarchy would solve at list half of FOSS interface problems without changing anything other than layout. The problem is project maintainers who think any attempt to remediate their non-designed cobbled-together interface is an attack by the 'new school' or what have you and either dismiss it out of hand, or reflexively bikeshed any proposal into oblivion because they're defensive, and lack the design sophistication to knowledgeably engage. As a senior developer and someone who enrolled in art school as an adult, I know how much more defensive people get about work they're not confident in. When those people are in charge of a project AND have the misguided notion that their "design" (read as cobbled-together assembly of user-facing functionality) is more functional than an expert's design, just uglier, good luck pushing change through.

> Most people that complain about this put the minimal viable effort into actually learning what they are doing. Somehow I'm the idiot after spending hours of my life to learn this professionally and for wanting expert interfaces. You can call me elite all you like but when the whirlpool of disaster is pulling us both under, I'll be in my elite raft surfing the waves while you struggle.

And fraternities keep paddling pledges and making them drink gallons of grain alcohol because they all had to do it too, so everybody else should. Complaining that nobody wants to spend time studying something that they wouldn't have to if it was properly designed is an asinine argument against progress. The only people here who should be chastised for refusing to learn new things are the people who refuse to consider better approaches and insist everybody else learn the same inscrutable incantations they did, because it's easier for them... Because they already know them. Just because you can't imagine productive ways to update these tools to a post-teletype world doesn't mean that nobody can.

If you have trouble with tools like dig, you have wasted a lot of fucking time.

Measuring usability by your own comfort level is the reason user-facing "open source alternatives" that aren't foundation-backed with dedicated designers will remain "alternative" in perpetuity.

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.

RTFM is usually (not always) a way to gatekeep bad UX.

For instance, you look at the dash of your car every time you drive, and what little is labeled is abbreviated. The expectation is that when you understand how the vehicle operates, the gauges and lights will make sense. The information is encoded behind your knowledge. dig isn't really different.

Some people want the tools to teach them everything, but that's just not appropriate or necessary, whether you're talking about a hammer, a firearm, or a computer.

> Once you're past that hurdle, it's redundant.

Yeah, then multiply that hurdle times the thousand others someone has to memorize to work in *nix.

> Some people want the tools to teach them everything, but that's just not appropriate or necessary, whether you're talking about a hammer, a firearm, or a computer.

Textual output on a computer is a communication medium-- hammers and firearms are not.

dig output make sense after reading the RFC. It exposes every bit flag in the protocol level

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.

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.

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."

But that's only like 10% of DNS's surface area, there's tons of other things it can do and rarely does, but if you have to make that stuff work you can get deep in the weeds fast.

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

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.

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.

https://github.com/ogham/dog is pretty good in that regard

  $ ip address --color
  Command "--color" is unknown, try "ip address help".

> ip --color address

otherwise you might just have an old version

    <command> <command options> <subcommand name> <subcommand options> <arguments>

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)

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.

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 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.

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

(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)

I learned it like anything else. Googled it, read the docs, and trial & errord my way into a working setup. I was comfortable with all the technologies in a couple weeks (working part time).

So I installed tinydns, read the documentation, experimented with the subdomain we didn't use yet. Took a few tries, but not really difficult.

Later one we added more stuff, like zone transfers, all of it is pretty easy once everything is running.

One of the things that scare people away from running DNS servers is Bind and it's configuration language, it's not great. You just don't have to use Bind, or you can switch to it once you understand the concepts of DNS better.

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.

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.

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

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.

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.

True. I set my VPN server to force DNS thru the tunnel to an intercepting DNS server - and it replies as if it were the intended DNS server.

DNS server is setup this way in response to LAN devices that have their own DNS configured, but it handles Android's private DNS too.

> 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.

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 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.

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?

> 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 something lots of people have trouble understanding is "not hard" are doing so as a flex at least as often as they are trying to be helpful, so I'm surprised that a lot of people don't make the same hypothesis you do. When someone does so while also touting their status among their peers due to their knowledge and talking about how 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, regardless of whether that was the intended message. If the goal is to try to help people, it's more effective to communicate in a way that conveys understanding and not judgment; if someone doesn't care to improve their methodology of helping people, that's fine, but it does raise more doubts about whether they're being honest about their intentions.

The nature of what's being learnt. Some things require a continuity - to understand B, prior A is needed (or helps, to understand faster).

The method of learning. Book/theory-based, or practical? For either, what's the nature of scaffolding (self, or via resources) to help leap the chasm? If testing one's self, what's the complexity and can that complexity be broken down into simpler (or more discrete) parts, (perhaps testing working better in smaller parts)? Perhaps A isn't fully (or at all) required to 'know' B, depending on how it's learnt. Which goes on to -

The nature of the learner. Someone that's looking to solve a task, somewhat surface, or someone that's interested and will go deeper into edge cases or approach with greater curiosity?

[I'm skipping the nature of the learning/knowledge, since 'resolving DNS' is a pretty externally verifiable result. However it might be fruitful to consider the nature of the learning is not only 'resolving DNS', and even if 'resolving DNS' fails, learning always happens (intended/unintended, positive/negative, a can of worms there).]

You point out that 'easy' and 'hard' are motivators that might have unexpected, or the reverse, effects vs. intended, depending on the reader. When putting it into those 3 parts, perhaps this shows the usefulness of framing.

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.

Git is analogous - most uses of Git are formulaic, and the underlying concepts are simple enough - but actually accessing the right lever to pull when disaster strikes is unclear and hard to experiment with. I'm in this latter category with DNS: I get it at a high level, but it's like a student who has only done the simple example project.

I'm of the opinion that we're at a good moment to redo the things DNS does with better separation of concerns by going towards "put those records on a blockchain, streamline it for known applications, reframe the hard problem around bootstrapping access to on-chain data". It's already been explored in varying degrees(e.g. Ethereum Name Service, Symbol namespaces) but it's not really something that has to be the monopoly of any specific chain.

Would you mind sharing some examples of hard-to-recover git related disaster? I ask because I previously worked with applying hundreds of patches on top of chromium (yes, Opera). This resulted in __multiple__ merge‐conflicts. However not anything close to what I would call a git related disaster. Anything could be undone nicely.

What is important is that git is very verbose by default. It guides through not only a repo current state but also options user has.

I've met many developers not caring to read any of a git output and then claiming git is too complex and git broke their repo and it's "too complex to use". I'm sure it's not the case for you though.

So I'm just curious what kind of disaster was mentioned above.

This a hundred times over.

Of course if the solution is editing .git/config, that's even easier, but it probably takes more than that.

Would be very interesting to know the purpose of modifying .git/ manually.

In particular, pretty much nobody wants to trust DNS names that can cost hundreds of millions to blockchain. Because if you lose (or compromise) your private key, then that's it. The domain is gone.

With regular DNS this would be solved by a couple of irate phone calls to registrars. At worst, via a court case.

Just on the topic of git: git makes it extremely easy to experiment! But far too many people, including those writing tutorials and blog posts, don't understand this. Whenever you're in doubt, just commit your work and make a temporary branch and switch to it. Then you can mess about with merging and rebasing and dealing with the conflicts to your heart's content.

This should be among the very first things we teach to new git users.

It just takes practice. Training helps but nothing can replace practice.

We can't jus b gud

I think in general this level of "kid-gloves" is overall unhealthy for society. It encourages mental weakness.

At the same time, I understand that your aim is to reach as large an audience as possible so your educational material can have max impact. For this reason, I can justify you having this stance. That said, I don't think it applies globally.

My own response to "X is actually hard to learn" is ... compared to what?

   1. compared to your first impressions?
   2. compared to general opinions that you're aware of?
   3. are you talking about general principles or deep down stuff?
   4. are you talking about the learning curve?  Is it irregular? Steep? Shallow?

    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, whereas it fact
       means the opposite and is used to refer to the record, not the name.
    7. That DNS can use tcp/53.  The number of misconfigured firewalls I've
       dealt with argh.
    8. Split vs forwarding DNS.  e.g. impact on the .dev
       domain.
    9. The urge of some to put underscores in their names.
       I believe that some (early?) implementations allowed
       them.
    10. Someone putting in a lower 'serial' in named.conf and
        the struggle to restore sanity.

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

some things seem deceptively easy and you can get by for years on basic features. then it happens, you try something new you learned you can do with $THING , add to it and things start to break and you dig in and realize you never fundamentally understood how the basic features that got you here worked. and thats ok

DNS is simple, but it is not necessarily easy to understand.

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".

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 (client side issues, intermediate server(s) issues, final server issues), cache!, enterprise interests (from client to server side) and wild global (or local) enterprise positioning, government and agencies interests, ageing, all issues related to the main 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, clients that implement from the last century /etc/hosts to mdns and avahi, 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.

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.

I debated whether I should respond to you at all, however I feel that I must. You and I don't know each other, and based on the last sentence of your reply I suspect we agree with one another more than we disagree. Nonetheless, your reply seems to imply that my comment and my earlier disagreement were done out of malice or arrogance. A different commenter used the term "gatekeeping".

Fundamentally most of the building blocks of the Internet that people interact with regularly, including DNS, are well-defined and relatively easy to understand /relative to other technical things/. Protocols like DNS are effectively shoving text into packet. All of the hard stuff isn't in the bare protocol, it's in understanding the complete stack of abstractions the protocol relies on, the abstractions that allow the protocol to be simple but can sometimes not work in unexpected ways. If there is anything I've learned in my life, it's that integrations and scaling are what make technical things hard, the basic protocols are generally very simple and they are robust primarily because they are simple. They are simple primarily because they get to rely on all the underlying abstractions to be there. Technology now exists in a world of abstractions on top of abstractions, and understanding the basic building blocks is now rare since many technologists focus on mastering a particular layer of abstraction, yet if you understand the basic building blocks, even in an incomplete sense, it can greatly empower you to be more capable and comfortable with the abstractions.

"Hard" and "Easy" are relative terms, and I do believe that saying things are hard can lead people to avoid them altogether. I have spent a considerable portion of my life working diligently to mentor people in their technical careers, foster technical understanding, and bring people along with me on knowledge journeys. I have done this through extensive written documentation (internal to companies), teaching classes (internal to companies), public conference talks, guest lecturing at universities, and mentorship of people who are interested in learning technology but come from non-traditional backgrounds. I myself come from a non-traditional background. I've also worked hard to improve the UX and accessibility of every piece of software I touch, because I think that technology as a tool and the information about how it works should be accessible.

I really appreciated your article and I think you have a great writing style to explain things in an understandable way. Your Implement DNS project is really great, and I will be linking it to others in the future as they go through the process of learning DNS. In no way was my disagreement before or this reply meant to throw shade on you, your article, or otherwise. It's because I believe saying things are hard actually discourages people from learning them, leads to avoidance, and in particular I believe DNS is one of the more simple of the many possible things someone can learn about how the Internet works. I am /very much/ not trying to in any way disparage the intelligence of anyone who is struggling with learning any technology. I believe that learning technology is much like learning anything else, it requires interest and time. Saying that some of the simpler things are hard can discourage people from having the interest, and if people do not have the interest they will not invest the time.

Very specifically, I think for the audience here on HN, they've had to learn and use technologies that are far more difficult than DNS in their lives and careers with an almost certainty. In a relative sense, I do not believe DNS is difficult to learn. DNS has a /lot/ of edge cases though, which can be hard to troubleshoot, understand, and resolve, so from this perspective it is hard to master and I wouldn't claim to have fully mastered it myself. As an example of what I mean, another commenter mentioned Git. I have a pretty deep understanding of Git as well, yet I consider it significantly more difficult to learn and understand than DNS, largely because DNS is better documented, easier to inspect, and doesn't require the technologist to understand complex algorithms like merkle trees. Yet almost every tech worker in the world uses Git every day, often with many frustrations and weird edge cases, as in regular usage it fails far more often than simpler technologies like DNS. The entire strength of DNS from a robustness, adoption, and resilience perspective is largely its simplicity, which is why I think relative to the many other things that exist that it's not hard to learn.

Our opinions are always colored by our experiences, as is mine, which I stand by. One of those experiences I'll recount here, which is that I have known a woman for a little over 6 years now who is currently working in IT and finishing a bachelor's in IT through WGU. She's one of the top performer's on her team and has a gift with understanding and explaining abstract concepts to users, which has made her well-liked by all at her company. Not long after I met her she shared with me that she'd always wanted to go into IT, but felt like she couldn't do it because everyone she'd met along the way had told her it was too hard for her because she suffers from a learning disorder called dyscalculia which interferes in her ability to do math. For reasons I don't fully understand, math ability is used by many technical people as a determinant of your ability to learn and work with technology. I was one of the first people she'd met in her life that encouraged her to pursue her interest in technology and told her she could do it. I did so by pointing out that many of the things people were saying were hard were concepts she already understood in the abstract and offering to go on the journey with her. She had been so dejected by others telling her things were too hard for her she never pursued a college education. I invested significantly in learning with her and 3 years ago she finished an associates and multiple certifications and started her first IT job, and she's been excelling in it the entire way.

I've continued to mentor her, along with many others, because I legitimately do believe that much of the technology around us is much easier to learn and understand than people commonly believe, and that understanding how it works is a key to understanding how our world works now and is incredibly empowering even for people who don't work with technology every day. I am adamantly opposed to any sort of gatekeeping of technology knowledge, and in no way am advocating that gatekeeping or trying to disparage those who struggle to learn. If anything, one of my existential fears is that as a society we fall into a situation where so few people understand the technology we rely on every day that it creates a new and more dire social gap beyond the wealth gap, a knowledge gap that fundamentally separates those who can effectively participate in the levers of power (including democratically) from those who cannot. I am heavily invested in ensuring that knowledge is free, accessible, and that there is an open pathway for people to learn and it's one of my core optimisms about the Internet.

What is reasonably easy is a high-level understanding of e.g. "given this question, this is what one expects an authoritative DNS server to respond" in the human-friendly form, covering the basic kinds of questions (A/AAAA/MX/TXT/CNAME).

Like the article points out, there’s so many layers of potential caches in between you starting a lookup and that lookup being resolved.

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?

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.

> 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.

Do you know which Linux tools use gethostbyname vs getaddrinfo and why they could give different results?