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 ;-)
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.
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.
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.
>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.
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.
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.
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.
> 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.
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.
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.
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.
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.
Also the CNAME if you have a cname you don't want any other records with the same name. It ends up being a confusing and ambiguous situation to be if. You are supposed to use the cname to jump the the actual record. but now there is also a MX record here are we supposed to do anything with it?
> 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.
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.
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.
This is kind of where I was going with that, but I don't agree with the way its being described. I 100% agree with cracking down on individuals who are hostile based on identity, that was unreasonable and should continue to be excluded from projects.
The history of the developer circles is that we've been a bit rough with the language. (mount, finger, touch, zip, etc are perfectly acceptable things for linux commmands.. theres even a joke about it). Unsavory jokes in mailing list/code bases, etc. However, we've come upon a bunch of people who take the aggressively negative view on the words and interactions used and have taken it upon themselves to rename things and force changes. (Master/main, master/slave, whitelist/blacklist, [theres a whole list of these "undesirable" language things] etc ).
On top of that the CoC has implemented toxic positivity rules on projects. Implementers overlook the fact that they have been used as a weapon to be put in the project it's self. (There have been examples of racial, and gender based discrimination in the enforcement of the rules)
All of this brings in people who do not contribute in a UX, DX, engineering, management sort of way. Even when these things are abused/enforced poorly it still has a significant silencing effect and distancing effect from those who would be a positive contributor but is reluctant to participate.
> But I just don't see e.g. for-profit bootcamps with their simplified curriculum as any kind of social justice project.
And you're right not seeing them that way!
While I'm sure there are now good-faith bootcamps that have the goal of improving the career options of people who may otherwise never get those, the first time I saw the programming/sysadmin bootcamp concept implemented was around 2002, where a company was recruiting kids still in high school to train them for their openings.
They did that because there were not enough skilled IT workers back then.
Right, what that really meant is, they did that because there were not enough skilled IT workers they could afford back then. Someone did the math and estimated that for some openings, it would be more profitable to train first-time-job-seekers (in a lot of cases, not-yet-job-seekers) than to offer a better deal. They're still in business so I guess it worked!
The SJ part I gave more context in a reply to: Spivak
But to address the level of statements: I see SJ as one part of it, not the only or major part.
> enthusiastic nerds
Maybe it's the spaces I'm in but I'm not seeing that these days. I'm not hearing about personal projects people have made anymore. I'm not seeing a lot of enthusiastic young presenters at conferences etc. I'm just seeing younger people trying to stand out in the rat race and they aren't similar to when I was growing up. (I.e. lan parties, identifying as nerdy people and grouping together, etc).
The last young person I recall being like that was a guy who did a presentation on using Joycons at Scaladays 2017? This was a kid that did have experience in the us first robotics group. But f me.. a high schooler pretty good at Scala.. that's awesome!
I don't know, I would be curious to meet out of school dev from 20 years ago. Those I meet at my current job are... young. The lack of experience shows.
I guess at the time I was not better. Different, because using C I could still destroy hardware. Hard to program a CGA card from Python :D Maybe with MicroPython on an arduino now?
> I don't know, I would be curious to meet out of school dev from 20 years ago. Those I meet at my current job are... young. The lack of experience shows.
I was a stil-at-school dev/sysadmin/multi-purpose nerd 23 years ago, if that works, nice to meet you!
I had more experience than average on some tasks because I was lucky enough that, against my own will, when I was a little kid my parents bought a computer and not a videogame console. I still spent most of my time in front of it playing games, of course, but I also learned to program a little bit, and by the time we had our first PC at home, I also learned troubleshooting because every time I broke it I had to get it working before one of my parents needed it.
Other than that, I think school prepared me well in terms of foundations (perhaps better than what some kids see today, at least I'm surprised how few people who went through formal CS/SWE university training recently know enough about the reasons the relational model was introduced, or how operating systems work).
On the other hand, practical skills taught at school were not immediately useful to me. In particular, the software stack most used at school (Pascal, then Delphi, we did have some courses using C, Prolog, ASM, COBOL, and SQL, but most of my programming hours in school were spent in Pascal/Delphi) was not used in any of the jobs I've had, with the exception of COBOL), so I did a lot of learning on the job.
I make a living working on databases now, and I sometimes like to tell the story of how I got into them: while working at a bank, the web banking application had an SQL Server backend database for its frontend (actual banking happened in another network, on a mainframe, I don't know which DB it used but it was some IBM thing and it was not DB/2). There was a settings table that was basically a key/value store controlling different config options of the app. One of them was a maintenance flag which, if set to whatever the value for true was, would show a "we're under maintenance" page when serving any user request. One day they asked me to go put the site on maintenance ("go put the site" because I had to go walk upstairs and enter the datacenter to do this back then), so I went to the console, opened the query editor, and entered something like:
update settings set value = 1;
Notice the lack of a where clause. When I saw the number of rows affected, I panicked, ran downstairs, explained what I had done, and a colleague (who was also young but I think at his second job after school, and way more experienced than me) calmed me down, walked up with me again, showed me where the backups where, and helped me restore one.
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.
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..
> 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
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.
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.
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.)
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?
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.
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.
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.
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