In the last post we talked about some common DNS records.  There’s more DNS records to talk about but we’re going to only talk about the common ones.  This is a good thing, because there’s 39 of them.  We could be talking about more DNS records for quite some time.

Suppose you have a domain, let’s call it rhodey.example.com.  We know that rhodey.example.com is always going to do what the domain tonystark.example.com does.  So if we change tonystark.example.com’s IP address, we have to and change the IP address for rhodey.example.com.

Rhodey and Tony Stark at work

We’re lazy though, we don’t want to have to do that every time.  Plus, fumble fingers me could get the IP address wrong for rhodey.example.com.   Instead, I’ll use the CNAME record.  That’s the record that let’s one domain say ‘hey, what that domain over there is doing, I want to do.’

There’s no rule that a CNAME record has to exist.  We can find them using:

Alpha:~ computerlamp$ host -t CNAME google.com
google.com has no CNAME record

There’s nothing there!  Well, I said there’s no rule that something had to be there, and nothing’s there.  You should try it with some of your favorite domains and see if they have a CNAME.

The next record we’re going to talk about (and the final one, for now) is the TXT record.   That’s read as ‘text’.  It was meant for human readable information to be stored in DNS, but these days it’s most often used for machine readable information.  Which is kind of boring.

Let’s try one out:

Alpha:~ computerlamp$ host -t TXT akamaihd.net
akamaihd.net descriptive text "This" "is" "not" "the" "nameserver" "you" "are" "looking" "for."

Aww, and I was looking for Artoo Detoo.

TXT records aren’t required either.  Look what happens when I try:

Alpha:~ computerlamp$ host -t TXT theavengers.com
theavengers.com has no TXT record

We know what MX records are, we know what SOA records are, so now we want to learn what other records are available. Every time you query DNS for something, you’re asking for a record and according to Wikipedia there are 39 record types.  Not all of these are commonly used, so let’s talk about the common ones.

When you ask a name server for an IP address for a domain, you’re asking for an A record.  The way to make this query is:

Alpha:~ computerlamp$ host -t A www.google.com
www.google.com has address 209.85.144.105
www.google.com has address 209.85.144.103
www.google.com has address 209.85.144.147
www.google.com has address 209.85.144.106
www.google.com has address 209.85.144.99
www.google.com has address 209.85.144.104

See that -t flag?  That tells the command host to look for the record type A.

We’ve discussed name servers before too.  How do I find out the name servers for google.com?  The DNS record to query for a name server is the NS record.  That means the query looks like:

Alpha:~ computerlamp$ host -t NS www.google.com
google.com name server ns1.google.com.
google.com name server ns2.google.com.
google.com name server ns3.google.com.
google.com name server ns4.google.com.

If you can ask for an IP address for a domain, can you ask for a domain if you have an IP address?  Well, yes, you can.  That’s a PTR record.  That’s pronounced pointer record, by the way.  It’s the reverse of an A record and is known as a reverse lookup.

And once again, you can look it up with the host command:

Alpha:~ computerlamp$ host -t PTR 209.85.144.105
105.144.85.209.in-addr.arpa domain name pointer qv-in-f105.1e100.net.

There’s a couple of weird things about that response.  First of all, I used an IP address from the responses for www.google.com, but I got a different domain back.  Which is actually just fine.  One IP address can have a lot of domains with A records for it, but only one reverse record.

Second, it reversed my domain!   You see that

105.144.85.209.in-addr.arpa

response?  That looks weird, doesn’t it?  Well, it’s one of the underpinnings of DNS that makes all things work nicely.  All PTR records are in the domain in-addr.arpa.  Remember, it’s the Domain Name System, so there has to be a domain. We take that IP address, reverse it so that instead of 209.85.144.105 we get 105.144.85.209 and stick it in front of that domain.  That’s what we’re actually querying for when we make a reverse lookup.

In the past two posts we talked about the SOA record.  In this post, we’ll finish it.  The last parts of the SOA record are refresh, retry, and expire.  These are all numbers that note the number of seconds.  Each one does a different thing, but they all work together.

Refresh is the number of seconds the secondary name servers wait before asking the primary name server ‘do you have any updates for me?’.  You don’t want the primary to be drowned in requests of ‘got anything got anything got anything?’.  It’s like the two year old younger brother asking you constantly.  That’s annoying.  So we set the refresh of a domain.

The next number is the Retry.  Now suppose I ask my Mom ‘Can I have a new Xbox?’ and I don’t get a response.  How long should I wait so I don’t annoy her?  For a domain, that’s the ‘I didn’t get an answer from my primary name server, how long do I wait before asking again?’  Asking Mom repeatedly for an Xbox (especially if she doesn’t respond) is just going to make her mad.  Overloading a name server with repeated requests can do the same thing.

The Retry time must be less than the Refresh time.  Otherwise, I’m waiting longer than I should to re-ask than when I’d actually be doing my asking to begin with.

Now if my Mom doesn’t respond to me about the Xbox, how long should I wait until I give up on her ever responding?  (With my Mom, that’s infinity.  She’ll just ignore what she calls silly questions.) With domains, that’s Expire.  That tells the secondary server when to give up.  It’s usually a long time and the number has to be bigger than refresh or retry.  If it’s less than retry, then the secondary server is going to go ‘eh, why bother retrying, he’s dead Jim’.  Same with Refresh.  If it’s less than Refresh, then the secondary server is never going to bother trying.

Now for the last number, the TTL.  TTL stands for Time To Live.  This doesn’t actually anything to do with zone transferring.  Surprise!

It has to do with people querying the domain.  When I query a domain and get an IP address, the TTL tells me how long do I believe that response.  If it’s set to 300, then I believe that response for 5 minutes, at which time I have to query again.

It took us three posts, but we covered the SOA record!  In the next post, we’ll talk about other records used in DNS.

In the last post we started talking about the SOA record in DNS and the serial number used in a zone file.  I promised that in this post we’d talk about why we use serial numbers.

Hint:  It’s to cut down on traffic.

Chaos in the Traffic

These days it seems you can stream anything, play games, play music, and there’s always enough bandwidth to go around.  What’s bandwidth?  That’s the size of your connection to the Internet and connections within the Internet.  In the old days, the amount of bandwidth was really small.  You could sit at a terminal and type things on a connection far away and hit a key, wait for it to appear, hit the next key, wait for it to appear.

Slow typing

In other words, there wasn’t much bandwidth available.

People came up with tricks to reduce bandwidth usage and one of those tricks was a serial number.

An operation name servers use to share zone files amongst themselves is called a zone transfer.  You can imagine that some of these files get really big.  If there isn’t a lot of bandwidth, then constantly passing those files back and forth is a bad thing.

Instead, you have the serial number and you ask the other side ‘excuse me, has your serial number increased from the value I have here?’ and if the answer is ‘yes’, then the zone transfer occurs.  Otherwise, the zone file stays where it is.

This means that when the administrator makes any change to the zone file, he has to update the serial number in order for the transfer to happen.

Now for the obvious question:  Can everyone do zone transfers?

Well, the answer is no.  It’s a security problem if we do let everyone transfer.

Who can do transfers?  Like we said before, there’s a master name server listed in the SOA record.  We also know that most domains have more than one name server. For example, Google has four:

• google.com name server ns3.google.com.
• google.com name server ns1.google.com.
• google.com name server ns2.google.com.
• google.com name server ns4.google.com.

Imagine having to update the zone file on each one of those.  No thank you!  That’s what the master name server is for, you update that name server and then the other three can zone transfer your zone file from it, assuming the serial number has increased.  Those other three name servers are called slaves to the master name server or secondaries to the primary name server.  We’ll call them secondary or secondaries.  It’s an older term, but I like it.

We talked about DNS before and we talked about MX records and mail and DNS but now we’re going to talk about what else DNS can do.  Email uses the MX record type but there are a lot more record types for DNS out there than just mail.  In this post, we’re going to talk about one particular record, the SOA record.

Every domain has an SOA record, also known as a Start of Authority record.  Isn’t that a spiffy name?  Sounds like the delegation of authority in a business.  I shall start your authority here and here only!

I am your Start of Authority!

Every domain has a zone file that’s created by the administrator.  The top of that zone file has the SOA record and the rest of the zone file has all the records for the domain.

The SOA record that defines information about the domain itself.  It includes the name for the master name server, that’s the names server that is the be-all and end-all of information for the domain. Think of it as the server that is always going to have the real and true information of the domain.

It also includes an email address for the administrator.  This looks like a domain.  Like:  hostmaster.example.com.  That doesn’t look like an email address, where’s the @ sign?  Well, the first information before the dot is the email address, everything after it is the domain where the email is sent to.  That means that hostmaster.example.com is the email address hostmaster@example.com.

It also has a serial number for the domain.  Every time you make a change in the zone file, you change the serial number.  In the next post, we’ll talk about why the creators of DNS used this.