5 ms·

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 le

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

by shon 3y ago

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.