About Us
News
PGP Key
Sponsors
Software
BIND
DHCP
INN
Client Services
Support
Training
Consulting
Software Dev.
Public Services
Root Server (F)
Hosted @ ISC
List Archives
Tech Notes
Toolmakers
Domain Survey
ISC Technical Note Series
ISC-TN-2002-2 Duane Wessels 20-Dec-2002 CAIDA/TMF
Running An Authoritative-Only BIND Nameserver
ISC Technical Note Series
| This memo describes a methodology in use by some network operators which may be of use to other members of the Internet technical community. Distribution of this memo is unlimited, if full attribution is given. |
Copyright Notice
|
Copyright (C) 2002,2003 Internet Software Consortium, Inc. All Rights Reserved. |
Abstract
| Nameservers (BIND) fulfill two functions: serving authoritative data for delegated zones, and relaying queries and responses for non-authoritative zones. In the interest of security, operators generally should not use a single nameserver for both functions. This note explains why, and how, you should configure BIND to implement these functions separately. |
1. Introduction and Overview
1.1. Authoritative Zones -- BIND serves data authoritatively when you use a zone directive with type master or slave in named.conf:
zone "example.com" {
type master;
file "master/example.com";
};
Typically, BIND receives queries for authoritative zones from all over the Internet. When BIND receives a query for a name in an authoritative zone, it returns either a valid RR, or an NXDOMAIN error.
1.2. Hints, Recursion, and Caching -- In order to improve response time and reduce network traffic, BIND also functions as a local caching nameserver. Local clients initially contact the caching nameserver, which resolves cache misses through recursion. In this case, BIND is normally configured with the root zone as type hint:
zone "." {
type hint;
file "named.root";
};
BIND serves cached data non-authoritatively.
1.3. Security Considerations -- Although BIND can provide both functions (authoritative and non-authoritative) in single instance, ISC recommends always separating these two functions. In other words, you should run one server for your authoritative zones, and another that caches non-authoritative data. Reasons include:
| - | Authoritative and non-authoritative data are served to different sets of clients. In order to serve authoritative data to the Internet, the nameserver must be outside any firewalls. However, caching nameservers should generally be placed inside firewalls to protect them from outside abuse. |
| - | In general, serving authoritative data is more critical than serving cached data. |
| - | Cached RRs are kept in memory and increase the BIND process size over time. Authoritative data sets remain constant in size. BIND may serve authoritative data more efficiently when cached data does not compete for system resources. |
| - | Caching nameservers are subject to poisoning. For example, if an attacker can trick your caching nameserver into accepting a forged RR with high TTL, your local users will receive and trust the invalid data. This may cause browsers to connect to the wrong server, etc. |
| - | Certain denial-of-service and buffer overrun attacks are more likely to be successful in caching nameservers. |
2. Recommendations
2.1. Create an authoritative-only nameserver with recursion disabled. When you disable recursion, BIND does not contact other servers for unknown zones on the client's behalf. Instead, it either returns a referral to a server that can answer the query, or returns an error message.
To disable recursion, use the recursion no; option in named.conf. It also makes sense to disable fetch-glue when recursion is disabled:
options {
recursion no;
fetch-glue no;
};
If you have the root zone as a hint in named.conf, queries for unknown zones receive a referral to the root name servers. On the other hand, if you remove the root zone hints, clients receive a SERVFAIL error message. ISC recommends removing the root zone hints for authoritative-only nameservers.
2.2. If necessary, create a separate caching-only nameserver with recursion enabled. Your named.conf file should contain a hint for the root zone, a master zone for 0.0.127.IN-ADDR.ARPA, as well as master zones for any private (RFC 1918) addresses that you may be using:
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "master/localhost.rev";
};
zone "0.168.192.IN-ADDR.ARPA" {
type master;
file "master/192.168.0.rev";
};
zone "." {
type hint;
file "named.root";
};
This name server should only be used by your local clients. You may wish to place the server behind a firewall to prevent unauthorized access.
3. Testing
You may want to periodically test that your nameservers are configured as they should be. For example, your authoritative-only nameserver should return an error (SERVFAIL) for domains that don't belong to you:
% dig @127.0.0.1 example.com soa
; <<>> DiG 8.3 <<>> @127.0.0.1 example.com soa
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; example.com, type = SOA, class = IN
;; Total query time: 0 msec ;; FROM: localhost to SERVER: 127.0.0.1 127.0.0.1 ;; WHEN: Fri Dec 20 09:57:08 2002 ;; MSG SIZE sent: 29 rcvd: 29
Also note that ra (recursion available) is missing from the flags line.
4. Acknowledgments
This work partially funded by CAIDA and WIDE.
This web site and its contents - ©2003 Internet Software Consortium
Questions or comments regarding this web site can be sent to webmaster@isc.org