How to Secure a Domain Name Server (DNS)

1.0 Identification Data
1.1 BSP Number
1.2 BSP Title/Name
How to Secure a Domain Name Server (DNS)
1.3 Version Number
1.4 Adoption Date
1.5 Approving Authority
1.6 Responsible Organization
Not posted to honor anonymity request
1.7 Level of BSP
1.8 Security Processes or other Framework(s) Supported
In the Security Process Framework: Technical Security/Operate/Administer Technical Security Safeguards/Monitor Security Safeguards.

In the SSE CMM Framework: Monitor Security Posture /Monitor Security Safeguards.

1.9 Reserved
1.10 Points of Contact
Government BSP Owner:
  • Not posted to honor anonymity request.
  • Secondary POC:
    Yes, post this contact information with the publicly accessible BSP.

  • Artch Griffin
    General Services Administration, Office of Governmentwide
    Policy, Electronic Commerce (GSA/OGP/ME)
    1800 F Street, Suite G-131
    Washington DC 20405
    Telephone: 202-219-2370
    Fax: TBD
    E-mail: artch.griffin@gsa.gov
2.0 What This BSP Does
2.1 BSP's Purpose
The purposes of this BSP are to:
  1. Prevent unauthorized zone transfers from accessing the Domain Name Server (DNS) database (called a "zone" file),
  2. Reduce the exposure to DNS content corruption through either dynamic updates to the zone file or "cache pollution" (also called DNS spoofing or cache poisoning),
  3. Identify tools for checking the zone files and delegations for correct entries, and
  4. Identify other useful DNS resources.

This BSP provides DNS operators, "hostmasters", with suggestions and techniques for securing and improving the operation of their servers. It also guides them to useful tool and information resources. This BSP has no applicability to networks that are not using DNS for host name resolution.

The references given offer sample configurations for most implementations of DNS, however several of the low/no-cost tools are written as "Un*x shell scripts" or are written in PERL.

The author welcome reports and reviews on commercial DNS tools.

2.2 Requirements for this BSP
Improperly configured DNS servers generally slow or prevent proper connection of client application to their intended servers. Improper configuration can also lead to blocked and possibly miss-delivered e-mail, the "hijacking" of web sites or other services, and in the extreme, the root or administrative compromise of the system on which DNS is running. The services provided by the cooperative operation of DNS servers worldwide are necessary for the proper function of the Internet and for Intranets as well.
2.3 Success Stories
Informal testing of some of the domains within the ".gov" top level domain over the past several years showed that most systems would allow zone transfers by anyone. In the middle of 1999, Mr. Cricket Liu, co-author of the book DNS and BIND, offered a web base tutorial on "Securing Your Name Server". A number of government hostmaster took advantage of this. On January 1, 2000 two e-mails were received from the operator of the "Internet Operating System Counter" project (http://leb.net/hzo/ioscount/), Mr. Hans Zoebelein. Mr. Zoebelein was preparing to include the .gov and .mil domains in this years count of what operating systems are used to run web, ftp, and news services. The basis for finding these services is to first do zone transfers for the domain to be investigated (e.g., gsa.gov) and to recursively collect zones for delegated sub-domains. Then each collected zone is searched for host names that start with "www.", "ftp.", or "news.". The first e-mail from Mr. Zoebelein stated that he was starting the .gov and .mil surveys. The second e-mail said that he was unable to get zone transfers from many of the government’s systems. Now that is a major improvement from two years ago. However, many agencies still "leak" zone information in bulk.
3.0 What This BSP Is
3.1 Description of BSP
   3.1.1
Overview
  • Run a current version of your name server
  • Restrict zone transfers
  • Restrict dynamic updates
  • Protect against DNS spoofing (cache pollution)
  • Check your zones and test your delegations
  • Stay current
3.1.2
Tasks

Step 1 – Check that you are using the latest version appropriate to your specific situation. For BIND, the most commonly used implementation of DNS, the official version as of 3/31/2000, from the Internet Software Consortium (ISC, http://www.isc.org/ ) is 8.2.2-P5. ISC offers the following advise:

If you are running a version of BIND prior to 8.2.2 patchlevel 3, we recommend you upgrade to the current version for security reasons. If you are running BIND 8.2.2-P3, and compiled it yourself, we recommend you upgrade to 8.2.2-P5 to correct a named-xfer problem. If your vendor-provided BIND is 8.2.2-P3, you should consult their documentation and confirm that the named-xfer bug has been patched.

If you are using Microsoft’s DNS Server, check for information at: http://www.microsoft.com/ntserver/nts/downloads/recommended/ .

While the newest version doesn’t guarantee your server’s security, it is likely to reduce the risk of getting hit by old and known problems. Virtually all older server versions have widely known holes.

See http://www.cert.org/advisories/CA-99-14-bind.html and, in particular, the summary table at the end of: http://www.isc.org/products/BIND/bind-security-19991108.html for additional information on which versions have which problems. Be sure to check for newer advisories as well.

One way to check the version being run at a particular site is to check the system start-up logs if you have access to that system. To check on remote systems try the following sequence of name server lookup commands:

> nslookup
> server dns_server_to_test
> set type=txt
> set class=chaos
> version.bind.

You should get a response something like this: VERSION.BIND text = "8.1.2"

Another way to ask is to use the "dig" command like so:

dig @dns_server_to_test. txt chaos version.bind. The answer section would look something like this: VERSION.BIND. OS CHAOS TXT "8.1.2"

The sample data above was taken from a test of a major ISP currently under contract to several agencies. The reply 8.1.2 is disappointing as it reflects, if accurate, the use of a version with four known exploits (see the cert.org and isc.org URLs listed above). Note that not all BIND implementations correctly respond (i.e., the query is not supported) and, furthermore, it is possible to configure newer versions of BIND to report whatever you wish. This can be done using the "version" sub statement, for example:

options {
version "surely you must be joking" ;
};

Organizations that wish to operate "honey-pots" which imply the existence of an apparently broken version of BIND may wish to use this option to report an appropriately deceptive version string.

Step 2 – Restrict zone transfers to reduce the load on your server and network. This also prevents folks from collecting "G2" about your network and services. While the "crackers" can find out a lot without doing zone transfers, there is no reason to make their work easier. If you use BIND, use the allow-transfer sub-statement:

options {
allow-transfer { address_match_list; };
};


or, for specific zone:
zone "some.zone" {
type master;
file "db.some.zone";
allow-transfer { address_match_list; };
};

If you use Microsoft’s DNS, use the Notify tab of the Zone Properties dialog box and check the Only Allow Access From Secondaries Included on Notify List box.

Remember to restrict zone transfers from secondary (slave) name servers in addition to the primary (master) server. This can be a problem if your ISP is hosting your secondaries. Some ISPs do not know how to restrict zone transfers. If yours doesn’t know how, its time to train them or get a new one. To test, use the command nslookup ls domain.to.be.tested if you have a Un*x type system. The "ls’ option is implemented as a zone transfer.

Step 3 – Restrict dynamic updates to only authorized sources and be choosy about it. Dynamic updates are both useful and dangerous. Useful because you can keep your zone up-to-date, but risky since an authorized user can completely change your zone to any thing they want, including erasing it completely. If your needs dictate the use of dynamic updates, then be sure to restrict its use a tightly as possible. This means use individual IP addresses in the access control list. However, you now have another reason to be sure that your border router or firewall/proxy has strong anti-IP-address-spoofing rules in place. (See BSP xx-xxx-xxxx Blocking Spoofed Source IP Address with Ingress Filtering. This BSP is based on IETF RFC 2267, Network Ingress Filtering: Get your router/firewall administrators to take a look at it.)

At this time (3/31/2000) only BIND provides dynamic updates, however the capability is scheduled for Microsoft’s Windows 2000 offering. BIND’s default is to reject dynamic updates. To activate it, it has to be specified using the allow-update sub-statement.

zone "some.zone" {

type master;

file "db.some.zone";

allow-update { address_match_list; };

};

See Mr. Liu’s online presentation for more details; http://www.acmebw.com/paper.htm .

Step 4 – Protect against DNS spoofing (cache pollution). If you allow your name servers to respond to recursive requests from the Internet, then you run the risk of having your server tricked into learning "false" information. The technique of providing false data to inquisitive name servers has been used in a number of so-called web site cracks. One of the more recent events involved the RSA web site. What the cracker did was to inject false IP address information about RSA’s web site into a name server. The false IP address pointed to a web site in Columbia that had been cracked to display a faked RSA web page. The crackers can do this by sending a recursive query to a target name server asking it to find information about a domain name that is foreign to it. The name server will respond to the recursive request by asking other name servers if they know the answer. By tricking the target name server into asking a name server under the cracker’s control, the cracker can send any answer they want back to the target. Now the target has false information, its cache where it keeps learned information has been polluted. As more web masters improve the security of their sites, crackers are turning to DNS spoofing as a way to make it look like a site has been cracked. While it is true that a site has been broken into (the one in Columbia, in the RSA case) the actual targeted web site has not. Unfortunately the victim still suffers an embarrassment since a web surfer, whose browser looked up the spoofed IP address, will be sent to a corrupted page.

Many agencies appear to be running what is sometimes called a "split DNS" configuration. This is a "Good Thing."ä A split configuration means that two (possibly more) agency zone files are served by two different sets of name servers. One set offers DNS services to the Internet and serves up a limited set of names and IP addresses suitable for public use. It is this set of name servers that should not accept recursive queries. The other set of name servers generally has the full agency domain and is the set of name servers that are pointed to by the client software that the agency provides on its desktops. This internal set of name servers must support recursion.

Cricket Liu, co-author of DNS and BIND has this to say about turning off recursion (Copyright 1997-1998 Acme Byte & Wire LLC).

Disabling recursion puts your name servers into a passive mode, telling them never to send queries on behalf of other name servers or resolvers.

  • A non-recursive name server is very difficult to spoof, since it doesn’t send queries, and hence doesn’t cache any data
  • You can’t disable recursion on a name server if any legitimate resolvers query it, or if other name servers use it as a forwarder
  • If you can’t disable recursion, restrict the queries the name server will accept, shown later

To turn off recursion with BIND 8.*.*, use the recursion substatement:

options {
recursion no;
};

To turn off recursion in Microsoft’s DNS Server use the regedit tool (or regedt32) to add the value NoRecursion to the Registry Key, HKEY_LOCAL_MACHINE\SYSTEM\

CurrentControlSet\Services\DNS\Parameters. Set the value type to REG_DWORD with a value of 1.

One of the features of BIND 8.*.* is its ability to restrict which queries it will respond to. This is useful if you cannot turn off recursion. If this is the case, then you should restrict the queries that the name server will accept to: 1) the source (IP address) they should come from and 2) the zones that they should be asking about. Again quoting from Cricket Liu,

On most name servers:

  • Queries for records in authoritative zones can come from anywhere, because the zones are delegated to the name server
  • Queries for records outside of authoritative zones should only come from internal addresses

You can implement query restrictions with the allow-query substatement:

acl internal { [<network>/<bits>; | <address>;]
[<network>/<bits>; | <address>; …]
};
options {
directory "/var/named";
allow-query { internal; };
};
zone "some.zone" {
type master;
allow-query { any; };
};

See Mr. Liu’s online presentation for more details; http://www.acmebw.com/paper.htm .

Step 5 – Collect and apply zone-checking tools. Three useful "free" tools are DNSWALK, dlint, and DOC (the Domain Obscenity Checker). They can be found at several different locations:

DNSWALK is now hosted at SourceForge ( http://www.sourceforge.net ), but the link to its prime maintainer is: http://www.visi.com/~barr/dnswalk/ .

dlint can be found at: http://www.domtools.com/dns/dlint.shtml . dlint’s author has this to say:

Are you a DNS database maintainer? Have you ever wished there was an easy way to check your database for subtle errors like "PTR" records that don't point back to the right "A" records? Now you can check for this and many other problems with this useful utility, dlint.

DOC can be found at: http://www.shub-internet.org/brad/dns/ . Two other DNS tools that Brad Knowles maintains can also be found at this site.

It is important to be sure that you have the latest tool version that matches up with the new (8.*.* series of BIND). Which is a reminder that your should be running a current version of what every DNS server you chose.

Step 6 – Review on-line DNS resources and "sign-on/up" as appropriate. While CERT/Fed-CIRC are useful site for the broad spectrum of security issues and should be checked regularly, the comp.protocol.dns.* newsgroup hierarchy is specific to DNS. The Internet Software Consortium is the home of the reference implementation of BIND and, as such, is the authoritative source.

If you have DNS questions you can search the "Ask Mr. DNS" archive at http://www.acmebw.com/cats.htm first and if you don't find your answer there, then go-ahead and Ask Mr. DNS or post your question to the appropriate comp.protocol.dns.* newsgroup.

A newly published annotated list of BIND (named) messages is available at http://www.acmebw.com/askmrdns/bind-messages.htm .

3.1.3 Outputs
    1. DNS servers which can be tested to see if they respond to zone transfer, dynamic updates, or recursive requests from systems that should not be allowed.
    2. The reports for tool like DNSWALK and dlint will show how well a domain and the zone files are being maintained.
    3. Interested hostmasters can "subscribe" to news-groups or lists of interest.
3.2 Relationship to Other BSPs
Then IP addresses are used for access control, it is important to take steps to protect against IP address forging (also called spoofing). Information is available, but not yet in the BSP format, to help in reducing the exposure to spoofed IP addresses. The to-be-written BSP XX-X-nn.n.n, Blocking Spoofed Source IP Address with Ingress Filtering, describes how to block some spoofed source IP address datagrams from entering (or leaving) your network. This BSP will be based upon Internet Engineering Taskforce (IETF) Informational RFC 2267.

An number of federal DNS configurations fail to follow the IETF Best Current Practice for selection and operating secondary (slave) DNS servers. While this is not a material security issue there are security implications and definite network performance consiquences for failing to follow the recommendations. This to-be-written BSP XX-X-nn.n.o, Selection and Operation of Secondary DNS Servers will be based upon IETF RFC 2182 (BCP 16).

4.0 How To Use This BSP
4.1 Implementation Guidance
Having the Administrator of the DNS systems being reviewed work closely with the individual conducting the review can enhance the efficiency of this process.

There are several IETF Best Current Practices (BCP) related to DNS that hostmasters should be aware of:

  • RFC 2219 (BCP 17), Use of DNS Aliases for Network Services, M. Hamilton and R. Wright. The IANA name for a protocol should be used as the domain name for the machine that supports that protocol at a site. An HTML version is available. Oct-1997
  • RFC 2182 (BCP 16), Selection and Operation of Secondary DNS Servers, R. Elz, R. Bush, S. Bradner and M. Patton . How to select secondary servers. An HTML version is available. Jul-1997.
4.2 Implementation Resource Estimates
Personnel: Operating System Administrator or knowledge equivalent.

Time per System/Device:

  • Preparation Time up-front: 2 - 4 hours identifying the current condition of the configuration and downloading the appropriate patches in preparation for the on-site activities.
  • On-Site Time: 4 - 8 hours depending on the status of the device. Four hours to verify a previously configured device, and up to 8 hours to configure a newly installed device.
  • Final Report Preparation Time: 4 hours; this includes the documentation of activities by the reviewer and also the transfer of the documentation by the report writer into the final report.
4.3 Performance Goals and Indicators (Metrics)
  • General Goal: To eliminate those security vulnerabilities associated with DNS configuration and zone file maintenance.
  • Performance Goal: No name server, whether it is BIND, Microsoft DNS, or some other, that supports the .mil, .gov, or fed.us domains and any sub-delegation thereof will allow "foreign" zone transfers, dynamic updates, or inappropriate recursive queries.
  • Outcome Goal: Hostmasters will have configured their systems to block un-authorized use.
  • Output goal: Hostmasters will review [security] log summaries for unauthorized attempts and will report unusual activity as required by agency policy. The newly published annotated list of BIND (named) messages is available at http://www.acmebw.com/askmrdns/bind-messages.htm can be very helpful in figuring out what log entries mean.
4.4 Tools
Some tools used to perform review and analysis of zone files and as DNS administrative aids are:
4.5 Training Materials
  • DNS and BIND 3rd edition [comments below Copyright 1994-2000 by András Salamon]

Indispensable tutorial style DNS reference for anyone using BIND. Covers BIND version 4 and 8 while providing a solid background to DNS theory. The DNS is the foundation of nearly all Internet functionality, so this book has become a must-have for Internet administrators of all descriptions. Well-thumbed copies are also common on the shelves of network operations staff, Internet systems integrators, in fact almost all IT practitioners involved with Internet systems. Highly recommended!

This book is also useful for those running the freeware NT port of BIND 4, but note that it does not provide instructions for NT-specific operations issues such as installation, event logging, and the control panel version of ndc.

Published: September 1998.
Authors: Paul Albitz and Cricket Liu
Publisher: O'Reilly & Associates
ISBN: 1-56592-512-2

Errata are available for this book.

  • DNS on Windows NT [comments below Copyright 1994-2000 by András Salamon]

Version of the cricket book with the same DNS theory but covering the Microsoft NT 4.0 DNS server instead of BIND. Highly recommended if you need to run the Microsoft DNS server.

Published: October 1998.
Authors: Paul Albitz, Matt Larson and Cricket Liu
Publisher: O'Reilly & Associates
ISBN: 1-56592-511-4

Appendices
A Executive Overview and Briefing
Not applicable
B Reference List
Not applicable
C Procurement Information
Not applicable
D Evaluation Information
E Recommended Changes
F Glossary
Not applicable