Episode 13, DNS

PodCast Feed


Links:

DNS
Types of DNS Records
BINDS
DJBDNS
DJBDNSRocks
DNS Poisoning

RYOS. Episode 13 - DNS

Thud: The RunYourOwnServer podcast for January the 25th, 2007.


[music, "I Like Caffeine" by Tom Cote]

Thud: In this episode : DNS. What is DNS? DNS records, how DNS works, some DNS software, a moment of sec, and squirrel sushi.

Thud: This episode's reverse sponsor is the runyourownserver.org forums. Come join the discussion at forums.runyourownserver.org.


[music trails off]
Thud: OK, so let's jump right into this episode. Gek, why is DNS important?

Gek: DNS is the way that computers resolve IP addresses to names and vice versa. It's really helpful for humans when you're trying to go a system to remember the name is www.google.com instead of one of the 50 IP addresses that Google uses for their main site.


The easiest way to set that up is to have a server whose only job is to answer queries from other servers about, "Someone is giving me this name, what is this IP address?" or, "I want to go find this IP address, what is that name friendly to?"

Thud: Let's start with some of the basics of DNS, the DNS records. Seg, tell me about some of the record types.

Seg: Record types of DNS consist of things like PTR, A, MX, and there's the A record for IPv6 which, I think, is AAAA, it's four As if I remember correctly. There are also text records, TXTs. A records are used to resolve hostnames into IP addresses. The record itself doesn't resolve it, but an A record contains a hostname that's used to be referenced by and it contains the IP address that goes with that hostname. So an A record for google.com would be -- google.com was what you would reference and then you would get back the IP address.


Now PTR works reverse. When you reference a PTR record, the DNS server is expecting an IP address, not a hostname. So you give a DNS server an IP address and say, "This is an IP address, I've got to get the PTR for this, " and so, "This IP address goes to google.com or runyourownserver.org or whatever."


MX records consist of the referencing part, which is a hostname, and then the result, which is usually an A name or CNAME. It's recommended to be an A name because if it's a CNAME then you have to do another lookup, and I'll talk more about CNAMEs in just a second.


An MX record tells a mail client or a mail server what other server is responsible for the mail that that server is trying to send. So my mail client is going to send an email to somebody at runyourownserver.org. My email client is going to get the MX record from the DNS server. The DNS server is going to say, "This server over here is responsible for mail for runyourownserver.org." And so my mail client will connect to what the DNS server tells to.


MX records can have priorities. You can set them to anything from, I think, 0 to 99. I usually set them to 10, 20, and 30. The idea behind the priority is -- the mail client will get the list of MX records for any domain, say runyourownserver.org, and if the first one on the list isn't reachable or doesn't work, it'll try the next one on the list. If that doesn't work, the third and so on and so forth.


To interject a little spam trick, which has been going around for years and was not my idea, a lot of spam programs, a little old spam programs albeit and stuff that was written a long time ago, will try the highest number priority on an MX record. So if you have a priority 10, which is one mail server, and a priority 20, which is another mail server, it will try 20. The idea is, if it tries the least favorable MX record, the least favorable mail server, it will get one that doesn't have spam filters or anti-virus protection.


This used to work really well a long time ago for the spammers, but doesn't work for the spammers very well nowadays. A lot of admins, myself included, will make bogus MX records in the higher numbers. They'll set up three legitimate mail servers that work just fine -- you have nice fail-over, something goes wrong and you are still covered -- but then you make another MX record, like 70 or 80 or whatever, that is nothing, i.e. there are no mail servers running at all on that box.


A lot of spam that comes at that domain will be automatically routed, because of the spam program, to the highest number, which is the lowest-priority MX record. So if it hits the 70, it dies out, doesn't know what to do, and you never get the spam. So anyway, that's how priorities in MX records work. Remember, the lower the number, the higher the priority, the higher the number, the lower the priority. A priority of 0 is the first one to go to all the time.


Talking about CNAMEs. CNAMEs are a little bit different from A records and PTR records in that you call the CNAME by a hostname and you get back another hostname. Now if I'm doing an MX lookup on a domain and get back a CNAME as a result, then I have to do another DNS lookup on that CNAME to get the A record.


I go for runyourownserver.org, let's say it gives me back a CNAME and so right now I have another hostname and I have to go back to the DNS server and say, "What is the IP address for this hostname?" I get that IP address back, and then I go to the IP address. Remember, computers can't route by name, they only route by IP address. It can't do anything until it has that IP address.


It's not recommended to use CNAMEs at all, especially in MX records, because of the extra overhead. It's always better to use A records whenever you can. A lot of people that I know -- and GoDaddy, I know from first hand -- does this automatically when you set up an account with them and use their DNS.


They'll create CNAMEs for sub-domains like www.whateveryourdomainis, or mail.whateveryourdomainis. And that's actually, again, a bad idea because you force the connecting client to do an additional DNS lookup to finally get that IP address.


So I've covered PTRs, A records, MX records, CNAMEs, on to TXT records. TXT records can hold pretty much anything. It's just a record where you can put some text. Nowadays, one of the more popular uses of TXT records are making SPF records.


An SPF record is used to combat spam in the sense of, if I'm going to be sending an email from my domain, I run my own mail server, I'm going to be sending email from my domain which is this IP, I know that all the email that I'm ever going to send from me is always going to come out of this mail server. Then I make an SPF record saying that if you get an email that looks like it's from my domain and it didn't connect to you from my mail server, then it's bogus. It's a way of combating a lot of anonymous, spoofed spam that's going on. If you get spammed from Hotmail or from any domain out there and the connecting mail server is not the actual mail server that's responsible for that mail, then the SPF record adds a level of protection. If your mail client or your mail service uses SPF records -- Hotmail does -- then you are going to have better spam protection. If they don't then it's not going to count and you're not going to get any added protection.

Thud: Hey Gek, why don't you tell us about NS records ?

Gek: NS records are basically just the records that point to your nameservers saying that, "For this domain, if you can't resolve it already, then this is where you will get
the information about that host, or where you need to query for whatever that domain is that you are looking up."

Thud: So one of the other things that we want to cover is actually not a record, it's a field in a record, you could say, which is TTL. Gek, tell me about TTL.

Gek: TTL is the time to live. It basically helps another server understand how long it's supposed to keep a record if it's caching the results. So if you wanted to tell another server, "This record should exist for the next four days, minimum," then you would set the TTL to -- I think it's done in seconds or minutes -- you just set the number for however long that is.


It's an important thing to make sure to set it low enough that when you go to switch, you won't have to wait a week for changes to catch up because other servers are hanging on to your records for that long.

Seg: It's also important to understand that not all DNS servers on the internet respect the TTL, although most of them do, some of them don't. So if you set the TTL to five minutes -- 300 seconds, it is set in seconds -- if you set it to five minutes, not all DNS servers will actually respect that. Some DNS servers on the internet are configured to either ignore what you put and substitute their own TTL which the admin has set, or just ignore it completely and use some other arbitrary value. That's why DNS propagation can take so long. When you go register a domain, it should be instantaneous; it really doesn't take that long for a couple of packets to make it across the world a couple of times. But because there are a lot of TTLs involved, if you are switching the IP address on a domain if you are moving service providers, it can take a while. The DNS servers that take the change could take five minutes to change, whatever the TTL was set. And then as that information propagates through the internet by users requesting that information, the TTL makes a bit factor in what information they get during that migration.

Thud: Yeah, this actually brings up a really good point that caching DNS servers are very important to the internet infrastructure. Again, going back to what I said earlier about how a DNS session takes place, you can see with the number of transaction that if you can cache the original request, you just do it the one time and then you know what the response is for however long the TTL is. Then if you get future requests for it, you can just respond to it with that and not have to go through the whole dance to get the record again.


I have a feeling that the internet would be a much slower place if DNS caching was not allowed and the technology wasn't there, because if you had to make ten DNS requests to send one email every time you send an email, think about how many billions of emails are sent in a day. That's a lot of traffic to have to deal with, and you can also pummel other people's little old DNS servers if they're doing a little handful of domains and don't have a robust enough system. So DNS caching is very, very important. This goes into our next topic, which is how DNS requests actually get done as far as the transactions that happen.


So the way the request works, you bring up your browser, you type in www.google.com, your machine makes a request to whatever you have configured for your DNS servers in your network setup. Let's just assume it's a local DNS server somewhere. So that request goes to that server, that DNS server doesn't have a record for it, and it knows it's not authoritative for it. So then the request gets made from that DNS server out to the root DNS servers, which are a whole bunch of servers all around the world that store the basic DNS information for all the domains. So the request goes from that DNS server to the root servers saying, "Hey, I'm trying to get a record for this domain, google.com, and I don't know where to go." It has an internal list of where to go to get a .com, so it asks one of those root servers. The root server replies back, "OK, here's the SOA record, the start of authority, of which DNS server is responsible for that domain." Then, the DNS server that originally made the request goes to the DNS server listed in the SOA record and requests an NS record saying, "OK, I'm told that you're responsible for this domain, now I need a list of the domain servers for it." Once it gets that NS record, it then makes another request to the DNS server listed in the NS record and says, "OK, I need to know the A record for www.google.com." Then that DNS server that was in the NS record replies back with the IP, the DNS server replies back to your computer with the IP that your system now uses to go and make the connection.


It sounds really complicated and there are a lot of steps to it, but I'd have to say that DNS is probably one of the most efficient systems ever designed as far as the number of transactions that happen and how they're compressed to be as small a packet as possible so that they can happen quickly.


OK, now that we've covered some of the basics and with that last little bit some of the more complicated parts of DNS, let's go on to DNS software. There are a bunch of different companies that make software, lots of open-source stuff that we're going to concentrate on, too. The first one we're going to cover is BIND, which is probably the most popular DNS server around the world because it was basically the first one. Gek, what can you tell me about BIND ?

Gek: BIND is the DNS server that is put out by the Internet Systems Consortium. It is the oldest DNS server, I believe, certainly the oldest one that is still in use. It is extremely powerful and does very well in performance under high loads, but it's also very prone to break if you make mistakes in the configuration files. It's a little weird if you've never used it before. Whenever you make a change to one of the config files for a domain, you have to make sure that you increment the serial number properly, otherwise when you try and reload the configuration files, BIND will just stop serving for that domain. It does really well as long as you understand the nuances of using it, and it's basically what most of the internet uses. I think it's pretty much the standard.

Seg: Thud, you've got a pretty good background with BIND. Can you tell us what the good points to BIND are ?

Thud: I think the best thing about BIND is that it is the de-facto DNS server. So if there is a DNS feature you're looking for, it's going to work with BIND. There are some DNS features that don't work with most of the other DNS packages out there. IPv6 is a good one. There are still some DNS servers that don't have support for IPv6 records, and if they have support for the records, they may not have support for talking IPv6 across the network.


So BIND being the de-facto, if you have some weird off-the-wall DNS requirements, for certain types of records or certain types of interactions -- like DNSSEC for example, which is supposed to be a higher-security DNS query mechanism -- BIND supports that, a lot of the other guys don't.


Let me go a little bit about why BIND is bad. My main issue with BIND is that if you screw up a record, you can bring down your DNS servers very quickly, because BIND isn't robust enough to ignore records it doesn't understand. I'm trying to think of a specific example. If you do a typo and you get a semicolon in the wrong place or your system screws up the configuration file -- because I have had some people write automated scripts that didn't work properly and would, under certain circumstances, cut a configuration file in half and just drop off the last half of it -- if something like that were to happen, BIND just chokes and its default error mechanism is, "I'm not going to run because I don't understand the configuration file." Some of the other DNS servers that are out there are a little bit more robust.

Seg: What other kind of options do we have for using DNS, other than BIND ?

Thud: Well my favorite is djbdns, which is also known as tinydns. It's written by Dan Bernstein and because of that, a lot of people have some issue with it. There are certain licensing issues that some people in the open-source community have with Dan's software. djbdns is the same thing. But it's good software, and it's very easy to configure. It's not some horribly hard-to-read configuration file, it's pretty straightforward, it's easy to read once you understand the record language that it uses, and it's also easy to write software to deal with the language. Literally every line in the configuration file is a type of record, and it's just a matter of separating it out properly.


One of the good things is that this isn't one of those DNS softwares that if there's something it doesn't understand in the configuration file, it just ignores that line and goes on to the next one. So there is very little chance that having a typo in a DNS record is going to bring down your DNS system. Of course, that record is not going to work properly because it doesn't understand it, but all of your other DNS things are still going to function.

Seg: Well like you were saying, I really just like the way that the configuration files work. It was easy to understand. It was kind of tricky to configure just because of the way that they recommend setting up an actual DNS server. Specifically, when I was doing it, I was behind a firewall and the DNS server was running on my firewall, so I had to open up ports. You don't set up users to go directly to your DNS server on djbdns, you usually set up a caching server and then that's what people connect to. And that's just to cut down on the number of DNS queries that actually go out and poll the internet.


So that was a little tricky to set up whereas BIND is just one thing and you're not talking between two different BIND servers to make a DNS request. So really it was just how easy it is to read a configuration file. You don't necessarily have to understand all of DNS to look at a djbdns config file and understand what's going on, whereas with BIND each line is a separate part of one statement in the BIND configuration file, so it's a little more complicated and it's not quite intuitive when it comes to putting in new entries.

Thud: Yeah, and getting back to the separation of DNS serving and being a DNS cache, basically a DNS resolver, that is one thing that I really do like about djbdns, that it's separated out. They are two separate functions and there are actually some security implications of having both functions running on the same box in the same configuration, the way that BIND defaults to. But there are also some issues. As far as setting it up, I'd like to point out a really good site with documentation that hasn't been updated at all recently, but it's still very good documentation for setting up djbdns, and it's djbdnsrocks.org. They have different setups for single-server solutions or multi-server, and they even talk about vegaDNS which is a web interface for doing DNS updates with tinydns or djbdns, however you want to call it.


OK, since we talked about some of the bad things with BIND, let's talk about some of the bad things with djbdns. Gek, do you know any really bad things with it ?

Gek: It can be confusing for somebody who's used to most daemons where you go make a change to the configuration file and you restart the daemon and nothing happens because you forgot to recompile it. The fact that you have to run a make on your config file to recompile them so that you can actually use them, I think, is probably the only gotcha that I found.

Thud: Yeah, the only one that I've ever run into gets back into what I was saying before as a plus for BIND, is that djbdns was designed to be a DNS server to meet the requirements for the RFC for DNS. So some of the optional records, things like DNSSEC and a couple of others, you really can't do them with djbdns. It's not designed for it. As a matter of fact, Dan Bernstein has on his site a number of comments on DNSSEC and some of the other records. So BIND can do them, but djbdns can not. So if you need them, you can't use djbdns. But for common every-day stuff, MX, A records, PTRs, djbdns works just fine. And since that's mostly what I've run into, I try to use it wherever I can, because it can handle those things, and there is no point in having this huge behemoth of a software that has 10,000 options when I need five of them.

Seg: Hey Thud, what's the difference between tinydns and djbdns ? Why is there a different name for it ?

Thud: Dan Bernstein refers to it in both ways. He calls the package, all of the different pieces of tinydns, djbdns. But when you're actually setting it up and if you follow his directions, the binaries and everything are called tinydns. That's probably the main source of the confusion.


[jingle "And now for a moment of sec"]


For this episodes's moment of sec, we're going to talk about DNS poisoning. Basically the way DNS poisoning works is if a DNS server has a particular flaw in it, an attacker can make that DNS server get the wrong information for a DNS query. So if, again going back to google.com, if you put in www.google.com and an attacker can poison your DNS server, it could actually end up pointing you to yahoo.com or anything else they wanted.


It's a flaw that's actually been around for a long time, but it has come into more use for malware and hackers and things like that because it's something that a lot of older DNS servers are vulnerable to. As we all know, people don't keep their systems updated as much as they should.

Seg: So, DNS poisoning is basically taking over a DNS server, at least to some extent, and saying, "Instead of giving the right IP address for this domain, give it the wrong IP address." An example, as you said, would be instead of going to google.com, I might poison someone's DNS servers and then it would direct them to a copycat site, this IP address I have somewhere else on the internet that looks like google.com but is designed to not give the results the user is expecting, maybe steal pertinent information.


Something very serious would be something like paypal.com or any kind of real banking site. If you poison DNS and you give it any kind of IP address you wanted, then you could redirect all the legitimate traffic to your own IP address and then capture usernames and passwords, social security numbers, and whatever you can get out of that site.


It all relies on the idea that the DNS server is somehow flawed or under-patched or there is some other kind of security hole, be it within the DNS daemon itself or with SSH or terminal services or any other kind of service running on that server. DNS servers that are used by ISPs, if you're using Comcast or Adelphia or Verizon or something, if you were to break into one of the DNS servers for those people, then you have the opportunity to do a whole lot of damage.

Gek: Exactly. There's actually recently been a very crafty way of doing DNS poisoning where instead of poisoning for A records, you actually poison for NS records for a particular domain. From that point on, the DNS server that has been poisoned, instead of going to the main DNS server for that domain it can go to another one. So that way you haven't poisoned just a single record, you can poison an entire domain worth of records.


That's actually pretty crafty, and that is generally the way that most people set up phisher-site. They poison for bank.com and as far as you can see in your browser when you go to login.bank.com or billpay.bank.com, all of that stuff just works from that point on and goes to the servers they want you to go to instead of the real ones. It would be very difficult for you to just notice that something was going on.


If you had something like that going on, you could even fake the SSL certs so you would get your nice little lock down in the corner of the browser and you would think you were on your main site and you wouldn't really know.

Seg: I also want to point out that it doesn't necessarily have to be that your DNS software is old or not patched. If it's misconfigured, that can allow DNS poisoning also.

Thud: Absolutely. There is also DNS forgery which I want to talk a little bit about because it's related. The way that that works is, I'm a DNS server and I make a request to another DNS server for, let's go back to google.com. So I have Google's DNS server for the record. If somebody can reply back to me with a DNS reply packet that looks right but it gets to me before the right packet does, I'm going to trust the first packet that hits me.


So I make the request and the hacker sees me make the request across the network and simply replies back as if they were the Google nameserver with the record that they want to point me to, whether it's for an IP or a MX or whatever the particular attack is. By the time that Google's DNS server gets back to me, I think I've already gotten a reply and I just ignore that packet.


So that's another way that DNS servers, even if they're set up correctly and even if they're using really secure software, you can still do DNS forgery unless there are things built in to the DNS servers software to verify that it is the packet that I was expecting, it did really come from where I expected it to come from.

Seg: Now, as far as I understand, DNS runs on both protocols TCP and UDP, but mostly it's used on UDP port 53. Is there a benefit to using TCP to prevent forgery? Does it create a lot of overhead? Too much overhead to use in production environments? What are your thoughts on that, Thud?

Thud: Well the main issue with TCP and UDP, again going back to my description of how a DNS session takes place, there are a lot of packets in there, so they want them to move as quickly as possible. That's why, by default, DNS is done on UDP. It's port 53, for those of you that don't know. It's port 53 for UDP or TCP. So that's the main reason for doing UDP, because it can be a faster packet and it's a fire-and-forget, so the server doesn't have to worry; it sent the reply, it doesn't have to check if it got there, which is part of the reason why DNS forgery works.


The main reason why TCP is used is one, for zone transfers, which is a way of doing DNS record propagation so you have multiple DNS servers, you can zone-transfer off of one server if the permissions are set up right, so you basically get all of the records for a particular domain.

Seg: Like one customer has 50 domains and instead of individually transferring each domain, they do a zone, which is all of their domains in one package, they do it in one shot.

Thud: Right, and because that is so much data, it really needs to be TCP to make sure the data comes across properly. The other thing that TCP is used for for DNS is if UDP fails for some reason, and the most likely reason is that UDP, especially DNS UDP, has a particular maximum size for packets. If the records you've requested, say, there's somebody out there who's an idiot and puts in 30 mail servers in their MX record, that can be a very big packets.


So UDP would fail for the request, it would try it again with TCP. Because it's a bigger record, TCP would do the negotiation back and forth and reassemble the multiple packets. So for the most part in average everyday life, you don't need DNS to do anything with TCP. UDP is good enough because you're just doing MX records, A records, and SOAs.


[music / outro, "Down the Road" by Rob Costlow]
Thud: For show notes or other details, please visit our website at runyourownserver.org.


If you would like to send us feedback or have a question you would like us to answer on the show, please visit our forum at forums.runyourownserver.org.


The intro music, "I Like Caffeine" is by Tom Cote. This song, "Down the Road", is by Rob Costlow. Please visit our website for links to their websites.


This podcast is covered under a Creative Commons license. Please visit our website for more details.


Transcription by CastingWords