Hack 47 Understand DNS Records and Tools


figs/moderate.gif figs/hack47.gif

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 204.101.251.1 nameserver 204.101.251.2

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        209.226.175.236 ns6.bellnexxia.net.        32m47s IN A        209.226.175.237 dns1.sympatico.ca.         27m28s IN A        204.101.251.1 dns2.sympatico.ca.         22m26s IN A        204.101.251.2 ;; Total query time: 2038 msec ;; FROM: genisis to SERVER: default -- 198.235.216.111 ;; WHEN: Sun Nov 23 17:22:31 2003 ;; MSG SIZE  sent: 30  rcvd: 182

5.7.1.1 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:

  • ns5.bellnexxia.net

  • ns6.bellnexxia.net

  • dns1.sympatico.ca

  • dns2.sympatico.ca

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        204.101.251.2 ns5.bellnexxia.net.         9m55s IN A        209.226.175.236 ns6.bellnexxia.net.        18m57s IN A        209.226.175.237 dns1.sympatico.ca.         13m38s IN A        204.101.251.1 ;; Total query time: 239 msec ;; FROM: genisis to SERVER: default -- 198.235.216.111 ;; WHEN: Sun Nov 23 17:36:22 2003 ;; MSG SIZE  sent: 30  rcvd: 228

Notice the answer? Looks like dns1.sympatico.ca or 204.101.251.1 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        209.226.175.84 mta1.sympatico.ca.          13m56s IN A        209.226.175.80 mta2.sympatico.ca.          28m30s IN A        209.226.175.81 mta3.sympatico.ca.          13m56s IN A        209.226.175.82 <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        204.101.251.2 ns5.bellnexxia.net.        9m55s IN A        209.226.175.236 ns6.bellnexxia.net.       18m57s IN A        209.226.175.237 dns1.sympatico.ca.        13m38s IN A        204.101.251.1

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!

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

5.7.2.2 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 209.226.175.236 Server failed, trying next server: Query refused Trying 209.226.175.237 Server failed, trying next server: Query refused Trying 204.101.251.1 Server failed, trying next server: Query refused Trying 204.101.251.2 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

  • man dig

  • man host

  • Implementing Split DNS (http://www.relevanttechnologies.com/splitdns_081000.asp)

  • "Securing an Internet Name Server" (http://www.acmebw.com/resources/papers/securing.pdf)



BSD Hacks
BSD Hacks
ISBN: 0596006799
EAN: 2147483647
Year: 2006
Pages: 160
Authors: Lavigne

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net