5 ms·

How did you learn DNS? And when?

by neilk 3y ago

Terretta 3y ago
> How did you learn DNS? And when? I wrote one of the world's first dynamic DNS servers for our dialup modem customers in the early 90s, so when connected to our Livingston Portmasters with an assigned IP address you could be username.isp.com while online. Later updated this so you could also be http://www.username.isp.com http://www.username.isp.com all the time just by dropping an index.html file in your ~username/site directory. I learned both by spelunking BSD, reading man pages, and rapid prototyping in Perl. So I'm with tristor, it felt relatively straightforward. // I don't say I wrote the first because I don't know. I am not aware of any other regional or national commercial dialup ISP in the U.S. that offered this before we did.
- j16sdiz 3y ago
  Same here. I implemented some dynamic dns system. I still remember how to handcraft a RRUPDATE request. After reading the RFC, every bit in dig output makes sense
  - mst 3y ago
    It would, however, be nice if there was a tool (or, as jvns proposes, a +human option to dig) that provided output oriented to somebody who's just trying to -use- the thing rather than reading the RFC first. (I'm very much a "read the RFC first by default" sort of person because that approach fits my brain, but I don't think everybody should have to do that for relatively simple day to day stuff)
tristor 3y ago
I had a slow day at work in the beginning of my career (I was a help desk monkey then) and I wanted to learn more about how Active Directory actually worked. One of the things that I found out and became more curious about was why DNS was so critical for Active Directory, upon where I discovered the magic of SRV records. After that I decided I wanted to learn DNS in detail, so I read the RFCs, poked around with nslookup and dig, and then set up a local copy of BIND on a Linux VM to experiment with. In the numerous intervening years I've picked up more over time and been involved in numerous situations where I had to assist someone by doing DNS spelunking, often learning something in the process. I jumped from being a help desk monkey to being an L2 sysadmin in my very next job largely on the basis of my DNS and Active Directory knowledge, all of which was learned by reading documentation and poking at things, nothing particularly difficult about either. What always causes challenges is weird edge cases, but if you understand how things are supposed to work at a protocol level you have the basis of knowledge to troubleshoot the edge cases, which is how you learn about the more esoteric or implementation specific behaviors of things. I wouldn't expect anyone to particularly have deep knowledge of AD or DNS edge cases, but the basics of how they work aren't particularly hard knowledge to acquire and it's a constant surprise to me how few tech people understand DNS in particular, since it's a critical system for nearly every aspect of modern computing. As far as resources, when learning these things way back when I only used the official Microsoft documentation, the RFCs, man pages, and sites like nixCraft to learn about it. These same resources still exist (although Google sucks now and makes anything decent hard to find), and these protocols have changed very little in the intervening nearly 20 years, so I don't think it's any harder for folks to learn today than it was for me back then. This stuff is very literally not rocket science, DNS is an extremely basic protocol. In fact, nearly all its weird edge cases is because it's such a basic protocol that some behavior isn't clearly defined, however /most/ behavior is. It's very nearly all text on the wire, and all of the zone records, queries, and responses are human readable. As someone else mentioned, you can just use Wireshark and learn about DNS. It's inspectable on the wire, not just through tooling. FWIW, Active Directory is far more difficult to learn in detail than DNS, largely because Kerberos is deeply complex, and Active Directory has many unique complexities (like how FSMO roles work). DNS in comparison to most other things you are expected to know as even a semi-competent systems administrators / SRE is mindbogglingly simple.
dahfizz 3y ago
I was tasked with setting up & maintaining a dnsmasq server in college, which handled DNS, DHCP, and pxe booting. I learned it like anything else. Googled it, read the docs, and trial & errord my way into a working setup. I was comfortable with all the technologies in a couple weeks (working part time).
WarOnPrivacy 3y ago
Setup an in-house server to sinkhole malware requests.
mrweasel 3y ago
For me: Volunteer systems administration for a student organization. We had a subdomain under the domain of the university and wanted to add another one. We already had Bind configured with an A and MX record. No one really wanted to deal with it, so I asked some people I knew, who recommended that given we already ran qmail, then maybe tinydns would be the best option. So I installed tinydns, read the documentation, experimented with the subdomain we didn't use yet. Took a few tries, but not really difficult. Later one we added more stuff, like zone transfers, all of it is pretty easy once everything is running. One of the things that scare people away from running DNS servers is Bind and it's configuration language, it's not great. You just don't have to use Bind, or you can switch to it once you understand the concepts of DNS better.

How did you learn DNS? And when?

by neilk 3y ago

How did you learn DNS? And when?

> How did you learn DNS? And when? I wrote one of the world's first dynamic DNS servers for our dialup modem customers in the early 90s, so when connected to our Livingston Portmasters with an assigned IP address you could be username.isp.com while online. Later updated this so you could also be http://www.username.isp.com http://www.username.isp.com all the time just by dropping an index.html file in your ~username/site directory. I learned both by spelunking BSD, reading man pages, and rapid prototyping in Perl. So I'm with tristor, it felt relatively straightforward. // I don't say I wrote the first because I don't know. I am not aware of any other regional or national commercial dialup ISP in the U.S. that offered this before we did.

j16sdiz 3y ago
Same here. I implemented some dynamic dns system. I still remember how to handcraft a RRUPDATE request. After reading the RFC, every bit in dig output makes sense
- mst 3y ago
  It would, however, be nice if there was a tool (or, as jvns proposes, a +human option to dig) that provided output oriented to somebody who's just trying to -use- the thing rather than reading the RFC first. (I'm very much a "read the RFC first by default" sort of person because that approach fits my brain, but I don't think everybody should have to do that for relatively simple day to day stuff)

tristor 3y ago

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

dahfizz 3y ago

I was tasked with setting up & maintaining a dnsmasq server in college, which handled DNS, DHCP, and pxe booting. I learned it like anything else. Googled it, read the docs, and trial & errord my way into a working setup. I was comfortable with all the technologies in a couple weeks (working part time).

WarOnPrivacy 3y ago

Setup an in-house server to sinkhole malware requests.

mrweasel 3y ago

For me: Volunteer systems administration for a student organization. We had a subdomain under the domain of the university and wanted to add another one. We already had Bind configured with an A and MX record. No one really wanted to deal with it, so I asked some people I knew, who recommended that given we already ran qmail, then maybe tinydns would be the best option. So I installed tinydns, read the documentation, experimented with the subdomain we didn't use yet. Took a few tries, but not really difficult. Later one we added more stuff, like zone transfers, all of it is pretty easy once everything is running. One of the things that scare people away from running DNS servers is Bind and it's configuration language, it's not great. You just don't have to use Bind, or you can switch to it once you understand the concepts of DNS better.