ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


Five Basic Mistakes Not to Make in DNS
Pages: 1, 2

The forward-mapped zone file supplied with most BIND distributions is a masterpiece of the terse and incomprehensible, and a typical example is shown here:



$TTL 86400 
$ORIGIN localhost.
@  1D  IN    SOA @ hostmaster (
             0 ; serial
             12h  ; refresh
             15m  ; retry 
             1w ; expiry
             3h ; minimum
     )
@  1D  IN  NS @ ; localhost is the name server
   1D  IN  A  127.0.0.1 ; always returns the loop-back address

An alternate zone file format which is functionally identical may be more comprehensible - or then again it may not!

$TTL 1d ; 24 hours could have been written as 24h or 84600
$ORIGIN localhost.
localhost.    IN    SOA localhost. hostmaster.localhost. (
             2007040800 ; serial
             3H ; refresh
             15M ; retry
             1w ; expire
             3h ; minimum
     )
localhost.     IN  NS localhost. ; localhost is the name server
localhost.     IN  A  127.0.0.1 ; the loop-back address
The reverse-mapped zone file should look like this:
$TTL 86400 ; 24 hours
$ORIGIN 0.0.127.IN-ADDR.ARPA.
@       IN      SOA     localhost. hostmaster.localhost.  (
                        2007040800 ; Serial number
                        3h      ; Refresh
                        15      ; Retry
                        1w      ; Expire
                        3h )    ; Minimum
        IN      NS      localhost.
1       IN      PTR     localhost.

Ensure That Your Domain Name Does Not Have a Lame Delegation

Lame delegation means that a name server defined in an NS Resource Record (RR) for the zone does not respond authoritatively. That is, it does not set the AA bit in a query response for the zone. This normally happens for one of two reasons. The zone could have failed to load for some reason, in which case the problem will appear in BIND's log (or you could run the named-checkzone utility to verify the zone file). Alternatively, one or more of the name servers defined in the NS RRs for the domain is not configured with a zone clause. The fragment zone file below shows two name servers for the domain. BIND's named.conf file must have a zone clause for "example.com" at both name servers (the type may be master or slave), otherwise lame delegation will result:

; fragment of example.com zone file
$ORIGIN example.com.
; name servers Resource Records for the domain
; the ns1 is inside our domain, ns2.example.net 
; is in another domain
; both name severs must be configure with a zone clause
; for example.com in BIND's named.conf
          IN      NS      ns1.example.com.
; out of domain name server
          IN      NS      ns2.example.net.
; normal A RR for the in domain name server
ns1       IN      A       192.168.5.2

It is worth a couple of points of clarification here. The master and any slave servers for the domain will respond authoritatively to queries for the domain, so it is not possible to differentiate between a master and slave answer except, possibly, by looking at the SOA RR. A caching name server, which is neither a master nor a slave server for the zone, will respond with the AA bit the first time it reads the DNS Resource Record data from an authoritative name server. If it supplies the RR from the cache, the AA bit will not be set. To state the obvious, caching name servers cannot be authoritative for a domain. Only name servers with a zone clause for the domain (the type may be master or slave) in BIND's named.conf file can be authoritative for that domain.

Lame delegations are not good for two reasons. First, they cause requery of the zone's name servers looking for an authoritative answer, which adds unnecessary network load. Secondly, BIND helpfully logs lame delegation, so you can rapidly become famous for reasons you never really wanted. Avoid lame delegations!

Ensure That You Are Not Running an Open Recursive Name Server

Running an open recursive server--which means that essentially anyone, anywhere can use your name server to perform recursive queries--is a very bad idea. First, it increases the possibility of cache poisoning (the malicious insertion of false DNS data), by issuing more recursive queries than are required. Essentially, every query is a potential source of cache poisoning, so why do more of them than you have to?

Second, and far more important, an Open DNS may be used to amplify Denial of Service attacks by being requested to query the zone under attack. Sadly, as with open mail relays, what used to be a friendly neighbor thing has become a potential source of harm to everyone else on the Internet. Either remove the ability to issue recursive queries completely, or limit the recursive queries to allowed users only. All methods are shown in the following BIND named.conf fragments:

// if you are running an authoritative only server 
// the following statement should always be present
recursion no;

For a caching name server, or a mixed authoritative and caching name server (remember the recommended practice is not to mix the capabilities), use one of the two methods below:

// mixed authoritative and caching server
// use an appropriate local address scope statement
// to limit recursion requests to local users
allow-recursion {192.168.2.0/24;};
//
// if you run only a caching name server use this method
// use an appropriate local address scope statement
// to limit all query requests to local users
allow-query {192.168.2.0/24;};

Remember: Open DNS = Very Bad Idea. Treat this one as a very high priority, and fix it as soon as possible if you find you are running an Open DNS.

Ensure That Your Email Address Is Correct in the SOA RR

As the saying goes, stuff happens. You may, heaven forbid, end up with a zone that is giving people problems. For everyone's sake, and especially yours, make sure that your email address in the zone is correct and functional. The email address of a responsible person for the zone is defined in the SOA Resource Record (the so-called RNAME field), an example of which is shown below:

@         IN      SOA   ns1.example.com. hostmaster.example.com. (
                        2007040800 ; serial number
                        12h         ; refresh
                        15m        ; retry
                        3w         ; expiry
                        2h         ; min = minimum
                        )

In the above example, the email address shown is the recommended (in RFC 2142) hostmaster (specified as hostmaster.example.com), but it can be any valid email address that can ensure that you get the mail quickly. This also means you can respond equally quickly after taking any required remedial action, and earning yourself a Netizen of the Year Award.

Let's Give Ourselves Some DNS Headroom

The DNS system has worked well for more than 20 years, and it continues to work in spite of all kinds of unpleasant things thrown at it. Nevertheless, it is in our own self-interest to make sure we all play our part in trying to remove as much of the unpleasant stuff as possible. Because if real trouble arrives, as occasionally it does, the DNS infrastructure will have just a little bit more headroom to let it fix or absorb the problems and keep the Internet rolling along merrily, which is what we all want. A quiet life.

Resources

  1. RFC 4697 Observed DNS Resolution Misbehavior (www.ietf.org/rfc.html)
  2. ISC OARC (oarc.isc.org)
  3. IEPG (www.iepg.org)
  4. Cooperative Association for Internet Data Analysis (www.caida.org)
  5. Root-server web site (www.root-servers.org)
  6. Wow that's a lot of Packets (dns.measurement-factory.com/writings/wessels-pam2003-paper.pdf)

Ron Aitchison is the author of Pro DNS and BIND (Apress, 2005), the first book on DNS to describe the DNSSEC.bis security updates--and in mind-numbing detail.


Return to SysAdmin.



Sponsored by: