16 ms·

Why is DNS still hard to learn?

• shon 3y ago
  It’s not. It’s one of the few things that hasn’t changed much and it’s operation is fairly straightforward. dig is a little confusing. It’s more capable but less straightforward than good old nslookup (which still works fine BTW). I think partly DNS and the core protocols may seem confusing to younger people in the industry because so much stuff “just works” now. For example, today wifi routers “just work” right out of the box. In the early 2000s it would have taken a network engineer with knowledge of DNS, IP, Ethernet, RFC1918, actual routing protocols and whole bunch of other stuff to set something like that up and they’d have well known how it worked and why it was configured the way it was. If you think DNS from a client can perspective is confusing, try configuring BIND ;-) /OldNeckBeardRant
  • KRAKRISMOTT 3y ago
    Many modern APIs are more ergonomic and easier to use due to the benefits of hindsight. A redesign and upgrade of DNS is long overdue.
  • Arcanum-XIII 3y ago
    Yeah, BIND is hard to configure. Unbound/nsd are so much easier to deal with (once you find the correct documentation which is an exercice in frustration) The principle behind DNS are not that hard, once you understand it's recursive. Now to configure it with security in mind, the proper infrastructure and the final details... lot of things to learn, but not that hard. Without BIND I mean.
  • mrits 3y ago
    A network engineer or a teenager motivated to communicate with his girlfriend when not at his dads office.
  • cduzz 3y ago
    These things you're talking about are a small fraction of DNS though. For instance, you lookup "thing.behind.cdn.it" and get one answer, someone else looks up the same thing and gets a different answer. Pretty obvious, but when someone asks the reasonable question "can you open a firewall hole for thing.behind.cdn.it" Some servers forward requests, some delegate, some will look stuff up for you others won't. And there's the magic with search domains on clients, and if clients or internal resolver libraries will honor TTLs or not. There's also the myriad different types of records, and sometimes the server will tell you to reconnect in TCP instead of UDP, etc. So -- DNS is pretty complex; it has the illusion of being simple because it works so well and most of the fiddly bits are abstracted away by stuff that mostly just works.
  • bityard 3y ago
    Pretty much what I came here to say. As a young system administrator, DNS was the second thing I learned after setting up my first Apache server and I didn't find it hard to learn at all. I will admit that it when you get to a certain point, you have to be careful not to shoot yourself in the foot when operating a production system but that is a slightly different concern which is more implementation dependent. Eg BIND.
  • hiAndrewQuinn 3y ago
    Re/ knowing older protocols, I recently took a few weeks to read _Networking for System Administrators_ and take+review copious Anki card notes. It's incredible just how much more confident I feel around understanding networking at a high level, including both DNS and all the stuff underneath it, like `ethtool` and Ethernet frames and stuff. I suppose this isn't surprising, since knowing things "from the ground up" is why I went for electrical engineering instead of CS in college.
    • gjvc 3y ago
      20 years after doing a CS degree, I wish I had done EE instead.
  • monksy 3y ago
    I just wanted to add on to what you're saying: > I think partly DNS and the core protocols may seem confusing to younger people in the industry because so much stuff “just works” now. I've noticed it's become much worse since universities have been teaching Python to start with and with the whole aggressive comodization of developers. To some extent the social justice polices inacted in our communities to exclude people*. ("unsavory" people) We no longer have the culture where we had kids in early ages get a desktop, learn the ins and outs, play video games, trying to pretend to be a hacker, etc. We're getting developers who barely can script in javascript, barely do html, ignore the edge cases, and generally don't have a lot of interest in the craft. It's pretty frustrating to see this.
    • NikolaNovak 3y ago
      I may agree with your point but don't understand the social justice aspect at all; makes it feel like it's something just added in. I think both our perspective as a society and thereforo educational goals have changed over decades, laterally to any social justice aspect. If nothing else, there are order of magnitude more developers of all sorts today than 25 years ago, both as absolute numbers and as relative percentage of population. Basically the enthusiastic nerds who geek out about anything and everything and want to be hands on are still there, but also a LOT of people who just want a paycheck or just have more limited / specific interests. And they do ok. And education system will provide for them. But I just don't see e.g. for-profit bootcamps with their simplified curriculum as any kind of social justice project.
      • Spivak 3y ago
        And when there is social justice or involved it's about getting more people involved in engineering. I can see where "hey, quit being gross to women" can be read as excluding the unsavory but that framing presumes that a world where that's an intrinsic immutable property of a person. I really don't buy the "some people just can't help being an asshole so having a rule against assholes is exclusionary." The most controversial CoC is by far the Contributor Covenant and rules are be kind and empathetic, show others respect, don't insult or demean others, don't be creepy or sexually harass others, don't doxx people, and behave like adults at work. Like the bar is so low.
  • alexjplant 3y ago
    When I was 14 I (poorly) administered an Active Directory environment with mail, web, and CIFS for a restaurant without understanding DNS or DHCP. Instead of setting the WRT54G's DHCP server to hand out the domain controller's static IP as the DNS server for proper name resolution I just used IP addresses and host file entries to make everything work. I also had the MX record for the domain set to the router's WAN IP and didn't have any PTR records set - the fact that e-mail delivery went as smoothly as it did is an absolute miracle in retrospect. A few years later I figured out how DNS actually worked and in my early 20s I inherited a corporate intranet where BIND was used as the nameserver for all external corporate domain zones. Moving this setup to VPSes for increased reliability taught me a _lot_ (mostly zone transfers, SOA, etc). I'm grateful for the experience but these days everything is pretty much done for you so this is a low-value activity... "IT" isn't valued the same way that "software engineering" is for better or worse.
    • bdavbdav 3y ago
      Same boat at a similar age. (Ab)using AD taught me a lot about DNS, largely after the fact. Lots of “so that’s why that didn’t work…” moments later down the line.
    • TheNewsIsHere 3y ago
      This is why I continue to maintain that ops and SE excel at remaining distinct fields, though I certainly don’t mind overlap. Most of my friends are software developers and/or software developers working on cloud-based stacks. Two of those friends lead the platform engineering groups at their respective companies. One of them has a very basic understanding of networking and could figure out how to do subnetting that didn’t come out of the box, but they’d need to stop and go learn that. That isn’t everyone by any stretch, but I see it more often than not these days. I agree fully with the idea that younger professionals aren’t as used to the infrastructure underneath the infrastructure being as complex as the higher layers of the OSI model that they’re frequently more experienced with. What I hope we don’t end up with is a future where all the data center people and all the network engineers (and so on) are almost exclusively employed by a small number of mega-corps. It’s important that knowledge and experience in the fundamentals of the networked world remain widely distributed and openly accessible.
  • donretag 3y ago
    That is what I assumed as well, until one day I got hit by a bug involving Extension Mechanisms for DNS (EDNS). Never knew it existed. All of a sudden DNS was failing and could not understand why. Took me a long time to fix the issue.
  • orangepurple 3y ago
    If that is the case why is the recommended way to use DNSSEC is to turn it off? https://www.fastmail.com/blog/dnssec-dane/ https://www.fastmail.com/blog/dnssec-dane/
  • redeeman 3y ago
    > In the early 2000s it would have taken a network engineer with knowledge of DNS, IP, Ethernet, RFC1918, actual routing protocols and whole bunch of other stuff to set something like that up You remember things differently than I
    • icedchai 3y ago
      Me too. Plug-and-play consumer wi-fi routers were common place by the early 2000's.
    • fps 3y ago
      in the very early 2000s, home routers weren't a thing. Cable modems hooked up to a single computer. If you were a business, you got a PIX, but home setups were frequently done with a computer that had 2 ethernet ports and either used Windows's "home internet sharing" or Linux's ipchains and NAT. This was typically fine, because very few houses had multiple computers. I knew many people who would get a separate cable modem for each computer in their house. By the mid 2000s, Linksys started coming out with their little WRT routers, which were affordable by home users and mostly just plug and play.
      • icedchai 3y ago
        What you describe is late 90's, not early 2000's. Broadband was rolling out across many areas of the US in the late 90's (@Home cable modems, DSL, etc.)
    • deathanatos 3y ago
      Yeah. It was a bit different from today, but not by much. Really if anything, stuff has regressed since then. Our setup in the early 2000s was the same as today, except the AP, router, and modem were separate devices. This was somewhat beneficial: today, my monopoly ISP forces me to use their all-in-one junk box. There's not even a possibility of competition, and lo and behold, I don't think the forced-box does anything more than the three pieces of equipment did. (Except, finally and only as of the last year, IPv6. But perhaps if there had been real competition, that'd happened a decade sooner, esp. since I first saw it in '07 on a non-ISP connection…) Combining the AP/router I can get behind. It's when it became ISP domain that it went south. The 90s were rougher, as the networking stack in Windows was a bit more terrible. I have vague nightmares about installing drivers for TCP … where the TCP driver was somehow specific to the network card. That sentence doesn't even make sense by today's standards. Stuff got better in the 2000s.
  • icedchai 3y ago
    I agree. I remember learning about DNS when I was a teenager. And I've been running my own authoritative DNS servers for almost 30 years now. Remember the O'Reilly book, "DNS and BIND" ? It's still out, those this would've been first edition, around 1993.
  • xtagon 3y ago
    The downside to things that "just work" is that they become magical black boxes where learning how they work isn't a requirement until things really go wrong.
  • yodsanklai 3y ago
    > I think partly DNS and the core protocols may seem confusing to younger people in the industry because so much stuff “just works” now. Younger people aren't dumber than old one, they build even more complex stuff on top of these old abstractions.
    • vichle 3y ago
      Because all great developers create More complexity (-:
    • shon 3y ago
      Agreed. Not dumber, just building higher level stuff. The value of deeply understanding all 7 layers has diminished because generally things are standardized and work well so it’s not required. This frees up some calories to work on higher level stuff like LLMs. That’s good. It’s also good to encourage some people to understand the wisdom of the ancients in case SHTF.
  • vel0city 3y ago
    Linksys was making home routers which were about as easy to deploy as any home router today starting in 1999. Their earliest Wireless G router came out in like 2002. The beloved WRT54GS came out in 2003. https://arstechnica.com/gadgets/2000/08/befsr41/ https://arstechnica.com/gadgets/2000/08/befsr41/
  • deltarholamda 3y ago
    >It’s one of the few things that hasn’t changed much and it’s operation is fairly straightforward. It's relatively straightforward, ignoring all of the potential ways that things can go wonky, e.g. random servers not respecting TTL. But I'll never forget when Firefox put out an update with DNS-over-HTTPS turned on by default. All of a sudden, I was inundated with "Email is gone! Everything is broken!" because we run an internal DNS server handed out to workstations by DHCP. We have internal webmail and intranet Web servers that were just gone. It took a lot longer than it should to figure out what was happening, partially because it's DNS! Why should things go blooey? But it's pretty clear that Mozilla did not anticipate this (easily forseen, IMO) sort of issue.
    • throw0101b 3y ago
      > But I'll never forget when Firefox put out an update with DNS-over-HTTPS turned on by default. Plenty of DNS old timers / neckbeards (e.g., Paul Vixie) warning that DoH was not a good idea; there was lively discussion on HN at the time. We used split-horizon DNS as well and I implemented the "disable DoH" canary where I was working at the time. * https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https https://support.mozilla.org/en-US/kb/configuring-networks-di... * https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
  • arjvik 3y ago
    Is configuring BIND hard just because it's got an obtuse zone and configuration format? Or because there are a lot of DNS-server-level decisions that need to be made?
    • creeble 3y ago
      See above. It's not only an obtuse configuration issue, but it has very little validation for issues that can get you in trouble, like CNAME s that also have A records.
  • dv_dt 3y ago
    DNS concepts are pretty straightforward, but I agree with the article that there are a lot of little holes to fall into. No mention in any thread on dig vs /etc/hosts. Or of ISPs with bad actor DNS behavior... etc..
  • haroldp 3y ago
    Can you help me find the mistake in my zone file? $ORIGIN example.net. $TTL 900 @ IN SOA ns1.example.com. hostmaster@example.com. ( 20230728001 1800 300 3600 172800 ) @ IN NS 8.8.8.8. @ IN NS 8.8.4.4. @ IN CNAME example.com. @ IN MX 10 172.253.124.27 www IN CNAME example.com
    • throw0101b 3y ago
      Off the top of my head (haven't had to do zone files for ~2 years): * hostmaster@example.com -> hostmaster.example.com * NS records are usually hostnames (not sure if IPs are even valid) * Ditto for MX records ; also add a period to the end, otherwise example.net will get appended * Also appending with the www record See also: * https://linux.die.net/man/8/named-checkzone https://linux.die.net/man/8/named-checkzone
      • TheNewsIsHere 3y ago
        To add — You can do delegated zones by specifying NS records for a subdomain within the parent zone. If you’re talking about NS for a second level domain (“example” in example.com) you would want glue records which are essentially a “lookaside” to prevent circular dependencies. Glue records are really just A records with clout, returned with the IP of your name server. This glue is maintained by the higher level authoritative zone. So you query for example.org and the nameserver for .org returns ns1.example.org as the name server for your zone, as well as the IP address for that server. This is why you could run a DNS server at ns1.example.org as your authoritative DNS.
      • haroldp 3y ago
        Pretty good! :) Besides what was mentioned by others, there are two more mistakes in the SOA and one in each NS.
        • throw0101b 3y ago
          > mistakes in the SOA I figured there was since (e.g.) the numbers looked 'off' (regular TTL vs. negative TTL), but couldn't be arsed to look up the exact SOA format.
  • WarOnPrivacy 3y ago
    > For example, today wifi routers “just work” right out of the box. In the early 2000s it would have taken a network engineer Or a nerd buying a WRT54v1 to install hyperwrt.
  • giobox 3y ago
    > For example, today wifi routers “just work” right out of the box. In the early 2000s it would have taken a network engineer with knowledge of DNS, IP, Ethernet, RFC1918, actual routing protocols and whole bunch of other stuff to set something like that up and they’d have well known how it worked and why it was configured the way it was. I think you are stretching how bad wifi was in early 2000s - sure its easier today, but in the actual year 2000 you could walk into a store and take home an Apple branded wifi base station (original AirPort unit) - 802.11b stuff of the era was largely as easy to connect new stuff to as today, generally with a passkey. It all largely worked with DHCP out of the box just like most routers today too, if anything the experience is much the same minus the faster speeds, slightly better range and encryption today. Oh and probably some kind of ipv6 support... You certainly did not need network engineer level knowledge - lots of smart professional folks installed wifi in the 2000s, and solutions like the AirPort base station and many others were about as "turnkey" as they came.
• mkeedlinger 3y ago
  I found out about https://www.nslookup.io/learning/ https://www.nslookup.io/learning/ recently, which greatly increased my knowledge of DNS. If you look at the list of DNS record types [0], you might be surprised at how many their are. Knowing how to use those can be a bit much. [0] https://www.nslookup.io/learning/dns-record-types/ https://www.nslookup.io/learning/dns-record-types/
  • teddyh 3y ago
    > the list of DNS record types Actually authoritative list: <https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 https://www.iana.org/assignments/dns-parameters/dns-paramete...> That list also has linked references for each entry, whereas the list you gave only has references for 9 of the 51 types it lists. If we exclude entries explictly marked as experimental, obsolete, deprecated, or reserved, the list you gave is still missing these: • AMTRELAY • ATMA • AVC • DOA • EID • GPOS • ISDN • L32 • L64 • LP • MINFO • NID • NIMLOC • NINFO • PX • RKEY • RT • SINK • SPF • TALINK • WKS • X25 (I know, many of these are de-facto deprecated: SPF is abandoned for TXT, GPOS was replaced by LOC, and the entire usage of WKS was obsoleted by the recommendation of RFC 1123. But they are not marked as such in the list from IANA, and I still often see SPF records in the wild.) Also incomplete, but often has better references: <https://en.wikipedia.org/wiki/List_of_DNS_record_types https://en.wikipedia.org/wiki/List_of_DNS_record_types> (Not to mention TYPE, which I have also occasionally encountered.)
    • labcomputer 3y ago
      These all seem to be super-niche or obsolete though? * ATMA, ISDN, NIMLOC, EID, X25, are all for relatively niche or obsolete physical layer protocols (I guess ATM isn't that niche, but most people never run into it). * WKS, PX, NID, LP, L64, L32 seem to be defined but unused in practice (I had never even heard of ILNP, which what NID, LP, L64 and L32 are for, until I googled it just now). * RKEY, NINFO, MINFO and several others are expired without adoption or never made it to an RFC * GPOS is an earlier version of LOC
      • 3y ago
• joshcafe 3y ago
  Shameless side project plug: they mention a "debug" mode for dns resolving being nice to have. ComfyDNS has this in its web UI :3 https://comfydns.com/ https://comfydns.com/ It's the picture that says "TRACE google.com A IN" at the top. ComfyDNS is partly scratching a personal itch - I was tired of hand modifying bind9 zone files. And also I was curious as to how DNS works - I knew surface level stuff but no details. So I implemented the RFC from "scratch" (I used netty but no DNS libs). It was a lot of fun. (Also if/when the site goes down from hugging, forgive me, it is a rails app running on the oracle cloud free tier lol)
• pgray 3y ago
  the joke i've always heard is DNS combines 2 of the hardest problems in CS: naming things and cache invalidation
  • fauria 3y ago
    you forgot the second, off-by-one errors.
  • Dylan16807 3y ago
    It comes with a validity counter in seconds, and you can be very very loose about counting those seconds. It's not the hard kind of cache invalidation. You don't really have to do "invalidation" at all. And on the server side, it's perfectly acceptable to send a mix of old and new versions for a while.
    • andrewaylett 3y ago
      That definitely helps things to work, but it makes it very much more difficult to work out why things might not be working. Not least because an unexpected cache can lead to things looking like they're working when they're actually broken at source, as well as things looking like they're still broken when you've actually fixed them at source already.
      • Dylan16807 3y ago
        "I didn't know that cache existed" isn't because of the difficulty of invalidating the right items, though. And the occasional cache that keeps things forever is so extra broken that it's not doing that because cache invalidation is hard, it's either a supreme misunderstanding or it's incompetence.
        • lanstin 3y ago
          Sadly reboot the VM is still a valid step in debugging DNS, while you google "clear cache for this type of client resolver" Also, the dreaded caching of negative results/authoritative no such domain just before you get the new domain working properly.
• TZubiri 3y ago
  Non-issue
• teunispeters 3y ago
  One of the gotchas I encountered is that DNS is asynchronous, with possibly a long delay before reply. C apis make it look synchronous - which I think makes it harder to work with. There's also the detail that order of replies can be any. (I found too many developers expected synchronous and instant replies)
  • lanstin 3y ago
    with the caching, it's a nice bimodal distribution, 99.99$ 0 ms response time, 0.01% 30 ms response time (with a small chance of having that query packet be dropped, with retries in the 1000s of ms). I've seen people write caches that use the old value and kick off a new query in the background to hopefully populate the cache again.
  • NoZebra120vClip 3y ago
    I remember the mid-90s when we were writing MUD servers and clients. You'd start the client, go "/world ZebraMUCK" and then the TUI would hang while the DNS name resolved. So then we figured out asynchronous DNS (this was in the days when you linked with "-lresolv" on SunOS) and it was like a breath of fresh air! You could go "/world ZebraMUCK", control was returned to the keyboard, and even if it took 120 seconds to resolve zebramuck.nozebra.example.com, you could go about your business, like in another world, or issue some other client commands. And client developers learned a little about select(3).
• bratgpttamer 3y ago
  I feel like DNS is one of the more straightforward protocols, especially on a practical level, and especially given that most interfaces are a dropdown and two text boxes. I have noticed a lot of developers shy away from it, probably because they don't use it much or it's not their job (rather than it being hard).
  • paulddraper 3y ago
    "Dropdown and two text boxes" undersells it. Here is the list of several dozen record types: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 https://www.iana.org/assignments/dns-parameters/dns-paramete...
    • bratgpttamer 3y ago
      Sure, but I'm talking about a day-to-day practical level. Most people will only ever need to modify A/CNAME, occasional MX and TXT, and maybe an SOA/PTR. Even the more arcane record types (as far as I've ever used them) are essentially key-value pairs with the record type analogous to a namespace.
      • paulddraper 3y ago
        AAAA Also NS is reasonably common.
    • naniwaduni 3y ago
      Yeah, that's the dropdown.
  • msie 3y ago
    Exactly. Why waste time learning something I will only use once or twice a year or 10 times in my career? Or that someone else (who is an expert) can fix for me?
    • dclowd9901 3y ago
      I guarantee the problem space that dns solves is something you will run into in your career. Best to have some knowledge of systems like that so you can design them.
• gjvc 3y ago
  I remember being stymied by the BIND zone files (which are plain text) being called .db files (they may actually be called anything -- some people used the .db extension). I had just learned about sendmail, and I knew it kept alias tables in Berkeley DB files (which are binary), which in sendmail parlance were also called .db files. As Alan Kay is fond of quoting Bob Barton... "Systems programmers are high priests of a low art."
• laserbeam 3y ago
  Here's what's cool about the article: - Presents some nice theories which make things hard to learn (infrequent use, poor tools...) - Describes how DNS tools could be improved. - Gives you a few gotchas for how one may shoot themselves in a foot with DNS. Here's what's a bit (not much) less cool: - I really have no clue if those things ACTUALLY make things hard to learn (because it's not a research paper on learning). - It's a plug for other content on the side which actually describes the DNS protocol. I'll admit the sold content looks cool. I haven't purchased and can't vouch for the actual quality.
  • dgb23 3y ago
    As for the last point: Check out the author’s blog. She’s a real hacker and can convey technical things in friendly and simple terms.
    • laserbeam 3y ago
      Yup, I have no problem with the author or the work they do. I think it's cool. And there's still value in the article. My only point is it slightly undermines this article per se. Claiming that something is hard to learn and immediately providing a thing that can teach it well is usually marketing. And that's all ok :).
• andrewfromx 3y ago
  sometimes it's hard to even know WHERE to change the settings. Last week a friend was trying to setup heroku with api.foo.com and he needed to add a CNAME to the domain so heroku would make the cert and turn it on. I used dig, i used host, I used whois, I got invited to their aws route 53 and saw all sorts of stuff in there but each change had no affect. Finally I noticed from whois that the name servers weren't even aws they were google. So they gave me access to the google account but no domains in there. Finally I asked, have the CEO log in to his personal google account and sure enough, that's where the change could be made.
  • shadowgovt 3y ago
    This. The protocol isn't hard, but the protocol isn't the service. The service of DNS is a decentralized, distributed, held-together-by-spit-bailing-wire-and-an-unprecedented-post-WWII-era-of-international-peace-and-collaboration hash-job of individually configurable nodes kind of agreeing on a shared worldview of the information the service contains, unless your local government hates piracy or pictures of Winnie the Pooh, YMMV. It's like saying "I don't know why people struggle with databases; SQL isn't hard" and then the database contains ten thousand tables, a thousand indices, a hundred functions and triggers, and all of it was documented by someone who built it and never had a neophyte review the docs. Oh, and the database operates on eventual-consistency guarantees out to 24 hours of "eventually."
• Spooky23 3y ago
  DNS is easy in the same way that chess is. The game mechanics are straightforward, and it gets more complex from there. DNS bears the burden of delivering you to complex IT systems. It’s abused in various ways to enforce geographic restrictions, service levels, etc. It generally works, so long as everyone upstream knows how to configure things so that downstream things they don’t know exist work well. When things don’t work… that’s not easy.
• gunapologist99 3y ago
  It's probably a good idea for all IT people to have a working knowledge of how to debug DNS issues. DNS has historically been a vector for significant security holes and it's likely that this will continue to be true for the indefinite future. These holes also lead to other vectors in nearly every other protocol like SMTP. Even the CA system used for HTTPS is highly dependent on a basically insecure protocol. (Would you notice if your bank bought a DV certificate instead of OV? likely not) So, perhaps it's not such a bad thing that it seems hard to learn to those who don't have enough interest, since even now we see people building DNS things without taking the time to really understand the history of things like port randomization, cache poisoning, AXFR, etc.
  • dgb23 3y ago
    It seems to me that everything which broadcasts/asserts routing decisions in a network (any layer) is deceptively simple and potentially dangerous.
    • chasd00 3y ago
      > deceptively simple and potentially dangerous Also, there's not a lot of people keeping the whole thing running. iirc there's only like 13 or 14 root DNS servers on earth.
      • gloria_mundi 3y ago
        There are 13 root name server addresses, but most (all?) of these use anycast, i.e. there are actually several servers with the same address, and your traffic will usually be routed to the one closest to you. There are over 1500 root name servers. https://wikipedia.org/wiki/Root_name_server https://wikipedia.org/wiki/Root_name_server
• tristor 3y ago
  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 :)
• mgaunard 3y ago
  DNS is hard because cloud/web companies insist on taxing you to do very basic things.
• andrethegiant 3y ago
  Julia also created this comic about DNS, which is helpful for learning: https://wizardzines.com/zines/dns/ https://wizardzines.com/zines/dns/
• roomey 3y ago
  There's an old saying: if someone tell's you they know how DNS works, they're lying
• 1bent 3y ago
  djbdns is simple, easy to understand, easy to configure; it embodies a clear understanding of how DNS works. Unlike BIND and dig, it was designed after DNS had been in use for a while. Like sendmail, BIND suffers from being designed before anyone knew what it would need to do.
  • fullstop 3y ago
    I still use tinydns, but I've moved on from dnscache to unbound. djbdns was a great tool, clearly built with security in mind, and it forced you to understand how the whole system worked. It struggled with things added later like txt and srv records but they could still be added. qmail was also well ahead of its time.
  • rconti 3y ago
    and logging in hex is awful and should be punished
• jesuspiece 3y ago
  +human flag is a sick idea, would love to see that PR. inb4: you do it
• iAm25626 3y ago
  I used to specialized in these service enable services. DHCP/DNS/AAA/LDAP and etc; low level stuff tend to get take for granted. It's not difficult but there are much nuances. Not typical visible to layer7/Front end development per se. Embrace the "and". If you are a FE/BE dev AND understand system/dns/network. You just set yourself apart from the next person.
• swayvil 3y ago
  Because complexity is easy. It practically generates itself. It has a natural economic advantage. Making sense of complexity, otoh, takes much diligent effort. So complexity tends to win and everybody tends to befuddlement.
• dap 3y ago
  I went through this a few years ago, deciding that I had only a piecemeal understanding of DNS based on the specific things I had run into. I knew about `dig(1)` and BIND and a CS101 idea of how recursive DNS resolution works, etc. But I was missing the working knowledge needed for designing and implementing anything non-trivial or for debugging non-working systems. So I read "DNS and BIND" (not quite cover-to-cover, but close, skipping over the details on some of the more exotic features). I set up a real BIND server for some unimportant personal web sites. None of it was hard, but it did involve a bunch of (time) investment. To be clear, BIND is not the right thing for many use cases, but a lot of DNS ideas and terminology still come from BIND and I found that stuff very valuable. I think books are underappreciated for learning stuff like this. Most resources you find on the web are high-level theory ("here's a block diagram of how recursive lookup works"), task-oriented ("how do I get `dig` to do a recursive lookup"), or otherwise low-level (e.g., reading the source of your local DNS client to understand its retry policy). To understand the pieces and how they fit together, from the theory (what they're trying to achieve) down to implementation (what caches exist where), I find there's no substitute for a holistic approach that you usually find in books, but rarely (not never) find on the web.
• magicmicah85 3y ago
  "(like, what if you could run dig +debug google.com and it gave you a bunch of extra debugging information?)" The flag they're looking for is +trace and it provides exactly what they're looking for which is a path of how resolution occurs from root nameservers all the way down to the domain.
• supportengineer 3y ago
  This was an outstanding writeup, and I have felt the same frustrations in many other contexts. I enjoy going the "make your own, friendlier tools" route.
• kabdib 3y ago
  DNS itself is pretty simple. Implementing a basic DNS server or client is not a big deal. The management software around it is what is generally terrible.
• jl6 3y ago
  It's one of those things where there is a mismatch between how easy it seems to be, and how hard it turns out to be. We all use DNS every day, and it seems really easy. The everyday language of DNS is: domain names, lookups, IP addresses. This language is exposed in browsers for all to see, and through this exposure we develop a mental model of how we think it works. But under the covers there is a whole new language: zones, resolvers, delegated authority, that weird dot after the top-level domain...
  • dclowd9901 3y ago
    It’s the distribution part that makes it hard right? There’s a shit ton of dark magic happening above the atomic level of an individual node that both introduces the majority of the complexity and also the majority of the obfuscation. DNS is easy. An organization agnostic distribution of information is _really_ tricky.
  • gerdesj 3y ago
    "that weird dot after the top-level domain" That weird dot is called root. Without it, a name is unqualified, with it the name is completely defined. That means that context is everything. Without the dot, a resolver might add the resolver's domain or parts of it, repeatedly. Now, you and I know exactly what: host.example.co.uk is supposed to mean but without the trailing dot a resolver could try to look up host.example.co.uk.example.co.uk Windows out of the box, if this happened would also try host.example.co.uk.example.co then host.example.co.uk.example and then host.example.co.uk.example, then host.example.co.uk. and get a result. However I never saw Windows actually try the first effort and I think the behaviour was designed to deal with large corp with DNS federated monstrosity Active Directories. Your browser is probably toddling off to a DNS over https (DoH) server these days without your say so and canoodling with all sorts of ne'er do wells. Your DNS lookups are basic data - your ISP used to love seeing where you go. Your OS vendor (if you buy your OS) obviously can pass back "telemetry". Mr Google, doesn't own the desktop but does own the browser, so by ensuring you use "safe" DNS servers for your browser instead of whatever you have configured, its all good. All these shenanigans does make IT troubleshooting far more exciting than it used to be. I shouldn't worry too much about trailing dots. You will almost certainly not be using the DNS servers you think you are. I get why DOH was invented and there is a good reason for some "civilians" to use it - ie a non IT specialist using a nasty wifi hotspot will be protected from some harm by their browser going home securely to do DNS lookups. However is it up to the browser vendor to trample all over the user's choice of Endpoint Security? DNS is way more complicated than simply looking up addresses. Its about money these days (actually it always has been since around 2000) and there are now a lot of very opinionated mega corps who want to decide who profits off you.
• hackboyfly 3y ago
  I actually tried to learn about sockets today. I gave it around 3 hours but I never reached the end of the rabbit hole which led me to give up.
• jstx1 3y ago
  People who use their DNS knowledge often - what is your job and problems do you solve with your DNS knowledge?
  • m3047 3y ago
    I use DNS to define topology and services (what you'd expect) and of late I'm using it for federating telemetry (the actual data; think of "tags" in the industrial control sense). I've used it as an observable for asset discovery and classification, as well as for characterizing infrastructure.
• m3047 3y ago
  In a kind of corrollary of Dunning-Kruger, there is often a chasm between what people think DNS is and all of the things it can be. The article points some of that out (stub resolvers, even different implementations of libc); recursive versus authoritative responses; the recursion process; recursive versus authoritative servers. A lot of deployment implementations are "bottom of the barrel" and aren't correct to begin with, although they work for the intended purpose. There is no checklist for server implementations which I am aware of (I've asked where people should know!). There's a lot of folklore which persists because if it works it's presumed correct. There's "DNS" and then there's "The DNS", the "one true root" with arbitrary restrictions on the contents of labels. There's political interference with implementations in terms of the "one true root" doctrine, which interferes with marrying a resolver which e.g. queries a control plane and serves an application plane (where they have different roots): there are e.g. notions of forwarded zones, but there is no notion I am aware of of a "always recurse and lie that you're authoritative" zone (you can hack source code to accomplish this of course). Even MITRE ATT&CK doesn't always get it right. They had it listed that DNSSEC "traffic" had to be examined with SSL tools, until I pointed it out (I didn't get credit). DNSSEC related records are ordinary DNS records, nothing is being encrypted. I could go on: the experts were wrong on (UDP) frags, anycast...
• neilv 3y ago
  At one point, I had to make and maintain my own DNS zone text file, knowing only a little. Today, cheap providers give me various Web forms interfaces, but that doesn't mean it will always "just work", so knowing a little can still help. I still had to break out `dig` the other day, when a DNS provider started answering records days past TTL, breaking email and Web. To know when if/when that happened again, I looked around for a monitoring service, but didn't quickly find one that did what I wanted (and was overwhelmed by SEO, and very aggressive robo-sales emails from one of them), so I wrote a script that essentially runs `dig` and `diff`: https://www.neilvandyke.org/check-my-dns/ https://www.neilvandyke.org/check-my-dns/ The monitoring script discovered one of a provider's DNS servers had ongoing problems, so I sent them a monitoring report, saying I wasn't a DNS expert, but perhaps, if there's a problem, the report would be helpful to their DNS experts. This seemed to immediately get past any "have you tried rebooting Windows" front-line flowchart response that I wouldn't have been surprised to hear, and they said they're working on it.
• echan00 3y ago
  I thought you talking about aws lol
• ertian 3y ago
  'Still'? There's a famous talk[1] in the network community about how DNS complexity is growing so fast that effectively nobody can keep up with it. There's so many competing, overlapping, and overriding RFCs that it's hard to make sense of it anymore. [1] https://blog.apnic.net/2018/03/29/the-dns-camel/ https://blog.apnic.net/2018/03/29/the-dns-camel/
• Joel_Mckay 3y ago
  DNS has been repurposed for everything from security validation to load balancing. DNS over HTTPS and DNSSEC attempted to address some longstanding issues, but in the end everyone still has a host they know is going to get hammered harder. Not too difficult to understand, but it is complicated given the number of sub-optimal use-cases that emerged. =)
• chasd00 3y ago
  i hate to be that guy but it's not hard to learn. The tools are just from a different era where expectations where... different. However, even in my day BIND was avoided in favor of other servers like that one by the qmail guy.. can't remember his name. this comment reminds me of one of my favorite Dilberts old guy watching Dilbert at his computer: you kids today and your fancy graphical user interfaces. Back in my day all we had were ones and zeros ...and sometimes we didn't even have ones. Dilbert: you had zeros? we had to use the letter 'o'
• egberts1 3y ago
  Doing: bastion named server Multizone Hidden Master Split-Horizon IXFR/AXFR firewalling DNSSEC and local network resolv.conf hijacking Remote admin security All of above would and should be hard.
• pavel_odintsov 3y ago
  Great article. Thank you! I used to develop and maintain one of the World largest DNS services and summarised my experience with DNS protocol in this blog post: https://pavel.network/please-stop-using-dns-protocol-for-your-application/ https://pavel.network/please-stop-using-dns-protocol-for-you...
• thunderbong 3y ago
  Because the only three hard problems in computer science are cache invalidation and naming things. And DNS is a caching system for names of things. https://reddit.com/comments/15c2ul2/comment/jtty9dy https://reddit.com/comments/15c2ul2/comment/jtty9dy
  • yard2010 3y ago
    Also, off by one errors, which is implied
  • pphysch 3y ago
    To be fair, DNS is one of the best examples of "naming things done right". It's globally-curated (IANA), hierarchical, federated, easy to modify.
• chaps 3y ago
  One of the best, but also strangest explanation of DNS I've seen is from "A Cat Explains DNS". It's wonderful. https://www.youtube.com/watch?v=4ZtFk2dtqv0 https://www.youtube.com/watch?v=4ZtFk2dtqv0
• mqus 3y ago
  For me, the issue isn't so much DNS itself, but more that there are more things that try to resolve names on your PC, like /etc/hosts and all the stuff you put into resolv.conf. Then you read online that you should try dig or so and those tools don't really match up with what your tools do(=resolving via libc), because dig really only does the DNS part.
• cafard 3y ago
  Some years ago, I had a miserable couple of days when an internal DNS server quit working. Eventually I traced it to a corrupted cache file. Once that was deleted, life returned to normal. Though unpleasant, it was an enlightening experience. I had never imagined how much of the internet ran on Amazon by then (2010?).
• nineteen999 3y ago
  Another one of these articles. We learnt very easily back in the 1990's when the Internet was smaller, and the computers were much much slower and less capable. DNS, LDAP, SMTP, IMAP etc were the bread and butter of ISP's back then and people actually referred to the official documentation (RFC's etc). You had to learn them if you wanted to run servers on the Internet at all, and with a bit of an investment of time (ie. your paid time on your job) you learned it. This generation of developers and devops people don't have the patience or initiative and expect to be spoon fed and just cut and paste crap from StackOverflow and various low value blogs. Rather than learn the infrastructure that the Internet is built on, they grab the latest fashionable wrapper tool of the week, follow some shitty blog instructions, and then cry foul when it all falls apart and they cost their company lots of money. Just because they didn't take the time to learn the foundations of how things actually work on the Internet. I've seen it time and time again. It's not actually that hard kids. You just need to do your homework.
  • lannisterstark 3y ago
    Ah another one of those "dese damn kids and millennials I tell ya hwat, back in my grandpappys days we used to mine our own copper before laying them lines!"
    • nineteen999 3y ago
      The "get off my lawn" vibe was totally intended. Doesn't change the fact that there are a bunch of "AWS architects" out there running Terraform and building future disasters because they don't properly understand the infrastructure that the whole thing sits upon. It's just like the morons who think that dynamic linking should be abolished for everyone, because they don't understand the use cases for distributors from a security standpoint, developers/users who require binary modules, or how to use their distributions packaging tools to avoid conflicts, and are too lazy to learn. But oh no, "ma DLL hell". Good grief.
      • goalieca 3y ago
        > are a bunch of "AWS architects" out there running Terraform and building future disasters because they don't properly understand the infrastructure that the whole thing sits upon Back in my day we had two servers handle more requests than your 1000 nodes.
• 1vuio0pswjnm7 3y ago
  I'm not a "developer" and I learned DNS without any problems. Therefore agree with other commenter that DNS is not actually difficult to learn. I like the output from DNS utilities such as BIND and tinydns format. DNS is worth learning for any internet user, IMHO. I've written primitive utilities that when used together can do stuff none of the popular DNS utilities can do. I use these every day. Here's DNS challenge for readers. Try to look up the domain "bootable.com". Use whatever is the preferred method. People writing about DNS often compare it to a telephone book. IMO the way most people use DNS is more like "directory assistance". IP addresses do change but by and large most stay the same for long periods. Old zone files, publicly available scans^1 and other bulk DNS data collected from web crawls and public DNS caches comprise the "phone book" for me. Absolutely essential. 1. Sadly, in recent some of these sources have changed to non-public. No phone book for you! Call directory assistance.
  • rconti 3y ago
    > DNS is not actually difficult to learn. > tinydns format. You earned my disagreement right there!
• hairui 3y ago
  TIL that `dig` does not have TLDR page https://github.com/tldr-pages/tldr https://github.com/tldr-pages/tldr
• Croftengea 3y ago
  DNSSEC was already mentioned, but yet another dark corner of DNS are wildcard records.
• derrickrburns 3y ago
  Use chatGPT to understand dig output: Explain this : dig +human +norecurse @8.8.8.8 google.com HEADER: opcode: QUERY status: NOERROR id: 11653 flags: qr ra records: QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 QUESTION SECTION: google.com. IN A ANSWER SECTION: google.com. 21 IN A 172.217.4.206 ADDITIONAL SECTION: EDNS: version: 0, flags:; udp: 512 ChatGPT This is a result from the "dig" command, a DNS (Domain Name System) tool used to query DNS servers and retrieve information about domain names. Let's break down the output: dig: This is the command being executed. +human: This flag is not a standard dig option. It is likely an extension that is meant to provide a more human-readable output, making it easier for people to understand the results. +norecurse: This flag tells the DNS server (in this case, the server at IP address 8.8.8.8, which is a public Google DNS server) not to perform recursive lookups. Recursive lookups involve the DNS server querying other DNS servers if it doesn't have the requested information in its cache. By using +norecurse, the server will only provide information if it has it directly available. @8.8.8.8: This indicates the DNS server being queried, which is the Google Public DNS server located at IP address 8.8.8.8. google.com: This is the domain name being queried. Now, let's look at the different sections of the response: HEADER: This section provides general information about the response. opcode: QUERY: Indicates that the query type is a standard query. status: NOERROR: Indicates that the query was successful, and there were no errors. id: 11653: This is a unique identifier for the query, used to match queries with their respective responses. flags: qr ra: The flags indicate that this is a response (qr) and that recursion is available and allowed (ra). QUESTION SECTION: This section shows the domain name and the type of record being queried. google.com. IN A: The domain name "google.com" is being queried for its IPv4 address (A record). ANSWER SECTION: This section provides the answer to the query. google.com. 21 IN A 172.217.4.206: This line shows the answer. It says that the IPv4 address of "google.com" is 172.217.4.206. The "21" is the time to live (TTL) value in seconds, which indicates how long the information can be cached by other DNS servers or clients before it should be refreshed. ADDITIONAL SECTION: This section provides additional information related to the query. EDNS: version: 0, flags:; udp: 512: This line indicates the use of EDNS (Extension Mechanisms for DNS), which is a set of extensions to the DNS protocol. The version is 0, and the flags are empty. "udp: 512" refers to the maximum payload size that can be used for UDP communication. In summary, the query asked for the IPv4 address (A record) of "google.com" from the Google Public DNS server at IP address 8.8.8.8. The response confirms that the IPv4 address is 172.217.4.206, and it is valid for 21 seconds.
• deleted 3y ago
  [deleted]
• ggm 3y ago
  DNS is complicated because it's old, and has been continuously revised in flight, to uplift to TCP, DoH, DoT, add DNSSEC, EDNS0, TSIG, notify, ECS, EDE. It continues in one ietf WG having outlasted another, it has cross area review. It's political, and technical, and has its black helicopter cabals. I predate the DNS, and I continue to befuddle myself about details of the DNS on a daily basis despite a life embedded in DNS. If you love DNS join DNS OARC.
• oneplane 3y ago
  I think the article hits the nail on the head. DNS itself isn't hard, but learning real-world DNS is, due to the (as described) hidden nature of many parts between intending to do a lookup and getting the expected result. Some of this also stems from the divergence of what used to be a 'default' way to be connected to the internet (one interface, one gateway, one DNS server provider) and what is now far more common like having to figure out how to actually do the lookup in the first place (connected to multiple WANs, sometimes concurrently like LTE and WiFi) and as a user, not actually being able to tell which resolving path was used (was it the browser? the standard interface in the system C lib? was it some local resolver or recursor that sits in between the lookup? do any of them have a local cache? do any of them add special options by default?). Even if everything works, you'd still not be able to blindly trust if the query and response used the same path in one application as it did in another. Three browsers might all use something different, and the OS itself might use something different yet again, only to have mDNS add a fifth option.
• rsync 3y ago
  The question I have is: Why isn't there a combined MTA/DKIM/DNS server ? Why am I installing and configuring and running and monitoring all of these different server software packages ? I'd like to have a single config file that handles everything required to run a mailserver. If I have more complex needs I can split things up make them modular ... but I don't.
  • quesera 3y ago
    > Why isn't there a combined MTA/DKIM/DNS server ? If the nameserver was part of the MTA, where would you configure a CNAME for your webserver? > I'd like to have a single config file that handles everything required to run a mailserver. I think the kids call that Ansible. :)
• mparnisari 3y ago
  I love the flamewar that this post has started There's the "it IS hard!" gang and the "it's not hard, you're just dumb" gang and the "it's not hard, you just haven't spent the time required to properly learn it" gang
• readonthegoapp 3y ago
  i had hella trouble with it, but not just it - all the related topics - reverse dns/proxy setups, 10 ways to configure it/them, cname flattening and the 15 ways to configure that, the 15 ways you can do it with cloudflare or not, dis/advantages of all those setups/combinations/permutations, etc. doubt a course could teach me half of what i would need to know in some reasonable amount of time - say, two or three months. but open to the idea.
• StillBored 3y ago
  As a nslookup user since before dig, i find the default dig output to be less than ideal. The top->bottom flow, the "important" information is always the third option on a line, etc. Basically how do I put this, uh, its obviously written by someone for themselves and people who use it everyday. So, for most things I continue to use nslookup, it gives me what I want 99% of the time, and for me its easier to parse. So, various other people have said something similar but it reminds me of a couple utilities in AIX that an office mate of mine wrote. The thing was a very sharp tool but the 3 cases that comprise pretty much 100% of its usage required three+ mode selection parameters, etc just to print the equivilant of "its working" or "its not working". The result was 50 characters of typing that quickly turned into a shell script with two parameters. I sorta have the same thing to say about the "ip" command which showed up at the same approx time as dig. Yup it can do everything, but its a terrible UI too for all the same reasons. The defaults are ugly/hard and the hard stuff still takes 10 mins reading the man page for the once every two years you need to do it. So worst of both worlds. PS: I sorta feel the same way about bind, its written for people who run big public DNS servers, the rest of us are better served with "unbound" or the half dozen other utilities that are more oriented towards users looking to run an in-house split dns/caching resolver setup.
• minusf 3y ago
  behold the dns camel: https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01 https://datatracker.ietf.org/meeting/101/materials/slides-10...
• pjungwir 3y ago
  Wow, her "human" output for dig is wonderful. I learned nslookup first, and to this day I still use it because dig's output is such a mess. If dig looked as she suggests, I would have switched years ago.
• ks2048 3y ago
  I find the syntax and formatting confusing. The article mentions a desired "+human" flag. How about DNS tools that output everything in JSON? I want to see the structs as key+value.
  • sigjuice 3y ago
    Wireshark
• mike31fr 3y ago
  DNS-noob here: For what use case is it useful to debug DNS like described in this article? I'm a programmer since 2001 and I never ever had to investigate what is going on behind name resolution, I never encountered any kind of DNS-related issue.
• lorenzotenti 3y ago
  https://isitdns.com/ https://isitdns.com/
• Ellentonnq 3y ago
  [dead]
• ChoHag 3y ago
  [dead]
• udev4096 3y ago
  A fun and colorful explanation of how DNS works. https://howdns.works/ https://howdns.works/
• eftychis 3y ago
  tl;dr: suggestion: DNS is really hard to unlearn. I do not agree with the implied sentiment of the article. And thus with some of the comments (from "both" sides) of the arguments presented here in the comments. Hard is not defined, but is implied to be "harder than you believe it is." That is a general characteristic of perhaps most topics worth pursuing in our field: computer science/engineering. (Defining it in this closed field space on purpose for brevity.) And especially in distributed systems, which DNS in some way falls under. Further you have business interests, which have affected and will affect DNS -- we like it or not. And have added on top of it. A number of individuals then use hard as "it is intractable" [to learn]. Is DNS harder to learn than BGP routing: I think not. Does one need to spend a decade focusing on using and debugging DNS. I would argue not. Does one need more time to dive into BGP than DNS to do state of the art work: I would argue yes. DNS is simply not the hard and hot scientific problem people go around tackling from a research perspective. It is a federated business (and political perhaps) problem at this point. I do agree there is a lot of caching involved, which creates a ton of coherence and invalidation issues. That does not make the topic hard, it makes DNS problematic. (The other word I would use, and that I think Ms. Evans [the author] implies perhaps.) I agree totally with that. I also think it is a point of approach the learning path to it for the average scientist here. A lot of people are introduced to DNS (or email to that extend) as: here is the sketch idea, we make sure it works, trusts us, and there is this single deified entity that makes sure it works, and it is not patched with other branches "constantly." All of the aforementioned sentence of course is a lie. But a lot of engineers learn that. (I was lucky to not have that introduction.) And then it comes time to debug a DNS issue -- when they actually realize it is a DNS issue. So I would recommend a revised blog title to: DNS is really hard to unlearn.
• deafpolygon 3y ago
  DNS is like Othello. Simple to understand, but takes a lifetime to master.