Demystify DNS records.
DNS is one of those network services that has to be configured carefully and tested regularly. A misconfigured DNS server can prevent the world from finding your web and mail servers. Worse, a misconfigured DNS server can allow the world to find more than just your web and mail servers.
Even if you're not a DNS administrator, you should still know some handy DNS commands. The simple truth is, if DNS isn't working, you're not going anywhere. That means no surfing, no downloading, and no email for you.
5.7.1 Exploring Your ISP's DNS
On your home system, you most likely receive your DNS information from your ISP's DHCP server. Do you know where to find your primary and secondary DNS server addresses? If not, try this:
% more /etc/resolv.conf search domain.org nameserver 18.104.22.168 nameserver 22.214.171.124
Another method is to use the dig (domain information groper) utility. Here, I'll ask for the nameservers (ns) for the sympatico.ca network:
% dig ns sympatico.ca ; <<>> DiG 8.3 <<>> ns sympatico.ca ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; QUERY SECTION: ;; sympatico.ca, type = NS, class = IN ;; ANSWER SECTION: sympatico.ca. 8h29m IN NS ns5.bellnexxia.net. sympatico.ca. 8h29m IN NS ns6.bellnexxia.net. sympatico.ca. 8h29m IN NS dns1.sympatico.ca. sympatico.ca. 8h29m IN NS dns2.sympatico.ca. ;; ADDITIONAL SECTION: ns5.bellnexxia.net. 23m45s IN A 126.96.36.199 ns6.bellnexxia.net. 32m47s IN A 188.8.131.52 dns1.sympatico.ca. 27m28s IN A 184.108.40.206 dns2.sympatico.ca. 22m26s IN A 220.127.116.11 ;; Total query time: 2038 msec ;; FROM: genisis to SERVER: default -- 18.104.22.168 ;; WHEN: Sun Nov 23 17:22:31 2003 ;; MSG SIZE sent: 30 rcvd: 182
22.214.171.124 Understanding DNS entries
dig results are divided into sections. Not surprisingly, the ANSWER SECTION answers the question asked; in this case, "What are the nameservers for sympatico.ca?" In DNS, each entry in the DNS database is called a record. The answer indicates that sympatico.ca has four nameservers. Their hostnames are:
The next section, ADDITIONAL SECTION, maps each hostname in the ANSWER SECTION to its corresponding IP address. As an end user, you're really interested in the IP addresses of your nameservers, not their names. You need the address of least one DNS server before you can resolve any name to an address.
The other thing I'd like to point out is the type of records that were returned in the output. Notice that each nameserver record had an NS. If you ever see NS in a DNS database, you know you're looking at a DNS server record. Also, all hosts, regardless of whether they also happen to be a DNS server, web server, or mail server, have an A record. An A record maps a hostname to an IP address. In other words, a DNS server has two records: the NS record indicates that it is a DNS server, and the A record lists its IP address.
Can you tell which of the four nameservers in this output is the primary nameserver? You could look at the names and try to figure it out from there. However, it is possible to find out for sure, and it's easy once you know that SOA, the start of authority record, indicates the primary nameserver. Let's ask dig to show us the SOA record:
% dig soa sympatico.ca <snip banner> ;; ANSWER SECTION: sympatico.ca. 16m18s IN SOA dns1.sympatico.ca. dns-admin.sympatico.ca. ( <snip> ;; AUTHORITY SECTION: sympatico.ca. 3h22m20s IN NS dns2.sympatico.ca. sympatico.ca. 3h22m20s IN NS ns5.bellnexxia.net. sympatico.ca. 3h22m20s IN NS ns6.bellnexxia.net. sympatico.ca. 3h22m20s IN NS dns1.sympatico.ca. ;; ADDITIONAL SECTION: dns2.sympatico.ca. 8m36s IN A 126.96.36.199 ns5.bellnexxia.net. 9m55s IN A 188.8.131.52 ns6.bellnexxia.net. 18m57s IN A 184.108.40.206 dns1.sympatico.ca. 13m38s IN A 220.127.116.11 ;; Total query time: 239 msec ;; FROM: genisis to SERVER: default -- 18.104.22.168 ;; WHEN: Sun Nov 23 17:36:22 2003 ;; MSG SIZE sent: 30 rcvd: 228
Notice the answer? Looks like dns1.sympatico.ca or 22.214.171.124 is the primary nameserver. We also received an extra section, the AUTHORITY SECTION. Every query except ns will show which nameservers have the "authority" to answer your question.
You may prefer to try an any query instead of ns. This will show both the NS records and the SOA record, all in one shot.
While you're digging through your ISP's DNS information, you might want to find the name of your SMTP server. Since these servers have mail exchange (MX) records, use an mx query:
% dig mx sympatico.ca <snip banner> ;; ANSWER SECTION: sympatico.ca. 27m48s IN MX 5 smtpip.sympatico.ca. sympatico.ca. 27m48s IN MX 5 mta1.sympatico.ca. sympatico.ca. 27m48s IN MX 5 mta2.sympatico.ca. sympatico.ca. 27m48s IN MX 5 mta3.sympatico.ca. ;; AUTHORITY SECTION: sympatico.ca. 2h34m29s IN NS dns2.sympatico.ca. sympatico.ca. 2h34m29s IN NS ns5.bellnexxia.net. sympatico.ca. 2h34m29s IN NS ns6.bellnexxia.net. sympatico.ca. 2h34m29s IN NS dns1.sympatico.ca. ;; ADDITIONAL SECTION: smtpip.sympatico.ca. 28m30s IN A 126.96.36.199 mta1.sympatico.ca. 13m56s IN A 188.8.131.52 mta2.sympatico.ca. 28m30s IN A 184.108.40.206 mta3.sympatico.ca. 13m56s IN A 220.127.116.11 <snip>
Looks like my ISP has four SMTP servers; I'd better remember which one I'm supposed to use!
MX records always include a priority number. In this example, each mail server has a priority of 5, so they all have the same priority. Sometimes you'll see records where one mail server has a higher number than another. Always try sending your email to the server with a lower number that server has a higher priority. If the priority is 0, you should always use that mail server. This bit of information is good to know if you plan to send someone an email without using a mail client [Hack #48] .
5.7.2 Securing DNS
Put on your administrator's hat for a moment and re-examine these dig outputs. Did you happen to notice that the nameservers live on different networks? Let's take another look at those A records for the DNS servers:
dns2.sympatico.ca. 8m36s IN A 18.104.22.168 ns5.bellnexxia.net. 9m55s IN A 22.214.171.124 ns6.bellnexxia.net. 18m57s IN A 126.96.36.199 dns1.sympatico.ca. 13m38s IN A 188.8.131.52
Two of the four nameservers live on network 204.101.252, and the other two live on network 209.226.175. This is actually a good network design. Several attacks against high-profile companies have succeeded because their DNS servers were all on the same subnet of the same network. (See this article about DNS troubles at Microsoft for an example: http://www.findarticles.com/cf_dls/m0FOX/3_6/75645162/p1/article.jhtml.)
Realistically, to provide such protection, your company has to enter into an agreement with another company willing to host a copy of your DNS database. That other company may be your ISP, or perhaps a sister company. While adding redundancy, this also adds complexity and another element of trust. It's one thing to keep your own DNS servers up-to-date, fully patched, and securely configured. It's quite another to work with another administrator and assume that she has the resources to devote the same time and effort to your DNS servers.
Regardless of how the network is organized, someone has to address the issue of zone transfers. In DNS, your database is called a zone, as it really is just a portion of the globally distributed DNS database. When you need to make a change to your zone, you edit the database on the primary DNS server. However, you have to implement at least one secondary DNS server to provide redundancy. How are those changes propagated to the secondary DNS server(s)? If you guessed "via a zone transfer," you're right!
It's important to make a distinction here. Resolving a hostname is one thing. As an end user, you need that functionality in order to access Internet resources. As an administrator, you want your DNS servers to provide name resolution. Otherwise, you have to listen to a lot of unhappy end users.
However, your end users do not need to know the entire contents of your DNS database. The world at large certainly doesn't need to know the name and IP address of every host in your network. Think about that one for a moment. You probably have machines right now called finance, hr, patents, store, or admin. What tasty names those are to fire the imaginations of a malicious user!
184.108.40.206 The two-pronged approach
You can use a two-pronged approach to prevent your DNS servers from leaking information you'd rather not have the world see. The first approach is called split DNS. Run your full DNS zone within your internal network, and run a very small subset of that zone in your DMZ. That small subset is all the world sees. If you think about it for a moment, which records does the world need to know about? Probably just the record for your DNS server (the one in the DMZ, with its secondary preferably hosted at your ISP or somewhere else), the record for your web server, and the record for your SMTP server. Those are the only records that this mini-zone should contain.
The second approach is to control zone transfers tightly. The last thing you want to happen is for the DNS server in the DMZ to ask for a copy of your full internal zone. For that matter, you also don't want a user on the Internet to ask your internal DNS server for all of the records in your network.
There are multiple ways to control zone transfers, and you should implement all of them. First, read the documentation for your DNS server to see how to restrict the IP addresses that are allowed to ask for zone transfers. (The "Securing an Internet Name Server" link in this hack's Section 5.7.3 section explains how to do this for BIND.)
Second, configure your firewalls to control zone transfers. DNS is an interesting protocol, as it uses port 53 with both TCP and UDP. Your firewalls must allow UDP 53; if you deny this, all name resolution will stop. That is a bad thing. However, TCP 53 is used for zone transfers. You must carefully construct a firewall rule that allows TCP 53 only for the specific IP addresses of the DNS servers that need to participate in a zone transfer. Remember, you do want to transfer changes to your secondary servers.
Third, create guidelines to test your DNS servers periodically. Notice how complex it was to secure those nameservers. How many things could go wrong? Perhaps an OS patch or a DNS server application patch will introduce a new hole. Perhaps a change in a firewall rulebase will unwittingly reallow zone transfers. You're dealing with multiple DNS servers probably in multiple locations and multiple firewalls, which only increases the possibility of error. A routine testing schedule increases the chance of catching those errors before they remain for very long.
220.127.116.11 Testing DNS
You can use the axfr switch with dig to test your DNS servers, but I prefer the output provided by host -al. When you run this utility against your own domain name, you should see a result similar to this one:
% host -al sympatico.ca rcode = 0 (Success), ancount=4 Found 1 addresses for ns5.bellnexxia.net Found 1 addresses for ns6.bellnexxia.net Found 1 addresses for dns1.sympatico.ca Found 1 addresses for dns2.sympatico.ca Trying 18.104.22.168 Server failed, trying next server: Query refused Trying 22.214.171.124 Server failed, trying next server: Query refused Trying 126.96.36.199 Server failed, trying next server: Query refused Trying 188.8.131.52 Server failed: Query refused
Remember, host -al asks for a zone transfer. You want your DNS servers to refuse this request. In this example, all four DNS servers received the request, so I know they are up and working. The host utility then requested a zone transfer from each server. Note the order: the first IP address is for the first listed nameserver, and so on. This is important, especially if one of those nameservers responds with a zone transfer. I can't count the number of times I've tested DNS servers and two out of three will refuse the query, but one will allow the zone transfer. You'll know which DNS server was the culprit if you make note of the server response order.
This test is especially important if one or more of your DNS servers is hosted elsewhere. Make sure your agreement indicates that you will be regularly testing your DNS servers for misconfigurations.
5.7.3 See Also