Here are a few itemized caveats to take note of while setting up a DNS server for your organization. These items are mostly excerpts from RFCs and other web resources concerning DNS.
Mandatory RFC Reading:
- RFC 1537: Describes errors often found in DNS data files, points out common sysadmin mistakes and why they go unnoticed. (Has great error code detail.)
- RFC 1912: Describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain.
- RFC 2308: A discussion about negative caching, also has great error code detail.
- RFC 2317: Specifies best current practices for creating classless IN-ADDR.ARPA (partial class C reverse lookup) delegations.
Great DNS Links:
Miscellaneous DNS Links:
SUBJECT PARAGRAPHS
go to:
F |
G |
H |
M |
N |
R |
S |
T |
W |
Z
Firewalls:
If you are trying to operate a DNS server from within a firewall reverse lookups will be impossible. Only foreward lookups will be possible. (I am not sure if this actually true. This issue needs much more study. Suggestions appreciated.)
General:
When installing BIND (version 8 or higher) the named daemon runs as the user and group called "named". Therefore, the zone file directory, "/var/named" referred to in the "/etc/named.conf" file must be owned by the user/group "named". ($> chown named:named /var/named)
Hostnames:
Be sure that you select hostnames that use valid characters, which are numbers letters and the dash (-). BIND 4 used to allow underscores (_) which are no longer permitted in BIND 8.
Maintenance:
It is good practice to keep your root.hints file updated on a monthly basis. See DNS-HOWTO-8 for a a good cron script using dig: "The easiest way is using dig. First run dig with no arguments you will get the root.hints according to your own server. Then ask one of the listed root servers with dig @rootserver. You will note that the output looks terribly like a root.hints file. Save it to a file (dig @e.root-servers.net . ns >root.hints.new) and replace the old root.hints with it." (Refer to the Root Hints file entry below.)
MX records - CNAME caveats:
"... most mailers only look for their loca hosts's canonical domain name in the list of MX records. They don't check for aliases (domain names on the left side of CNAME records). ... there's no guarantee that a mailer will be able find itself in the MX list, and you'll run the risk of having your mai loop." - DNS and BIND, 4th ed., p. 99
I have tried this inadvertantly and can assert that mail queue backup storage and delivery will fail when using a CNAME instead of an A record for an MX reference.
MX records - more from RFC 1912:
It is a good idea to give every host an MX record, even if it points to itself! Some mailers will cache MX records, but will always need to check for an MX before sending mail. If a site does not have an MX, then every piece of mail may result in one more resolver query, since the answer to the MX query often also contains the IP addresses of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to support the MX mechanism.
Put MX records even on hosts that aren't intended to send or receive e-mail. If there is a security problem involving one of these hosts, some people will mistakenly send mail to postmaster or root at the site without checking first to see if it is a "real" host or just a terminal or personal computer that's not set up to accept e-mail. If you give it an MX record, then the e-mail can be redirected to a real person. Otherwise mail can just sit in a queue for hours or days until the mailer gives up trying to send it.
Don't forget that whenever you add an MX record, you need to inform the target mailer if it is to treat the first host as "local". (The "Cw" flag in sendmail, for example)
named.conf:
This file requires an application of absolutely clean syntax. The BIND daemon will not start if anything is out of place in this file. Furthermore, the named.conf file is not commentable.
Negative Caching - from RFC 2308:
Negative caching [formerly known as the default TTL] was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name.
Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part
of a DNS resolver.
... "Negative caching" - the storage of knowledge that something does not exist. We can store the knowledge that a record has a particular value. We can also do the reverse, that is, to store the knowledge that a record does not exist. It is the storage of knowledge that something does not exist, cannot or does not give an answer that we call negative caching.
Negative Caching - Deja email from Cricket Liu:
With BIND 8.1.2, you can't change the negative caching TTL.
It's ten minutes, hardcoded. With BIND 8.2+, the name server
uses the seventh SOA RDATA field as the negative caching TTL,
per RFC 2308, and you can cap that using max-ncache-ttl, as in:
options {
max-ncache-ttl 2; // Two minutes
};
cricket
Acme Byte & Wire
cricket@acmebw.com
www.acmebw.com
Reverse lookups - NXDOMAIN Error:
When doing a reverse lookup using the DiG utility, such as,
$> dig 82.211.133.64.in-addr.arpa @ns1.sprinthome.com PTR
and it yields a status of NXDOMAIN (no such domain) error in response, rather than a NOERROR response, then there has been no PTR record entered for domains pointed at by the host at 64.133.211.82. NXDOMAIN is an authoritive response.
Reverse lookups - more from RFC 1912:
You are required to have at least two nameservers for every domain, though more is preferred. Have secondaries outside your network. If the secondary isn't under your control, periodically check up on them and make sure they're getting current zone data from you. Queries to their nameserver about your hosts should always result in an "authoritative" response. If not, this is called a "lame delegation"
Reverse lookups - from DNS-HOWTO-5.5 (classless subnets, or smaller that a full class C):
A classless subnet is what keeps the Internet going these days. Some years ago there was much ado about the shortage of IP numbers. The smart people in IETF (the Internet Engineering Task Force, they keep the Internet working) stuck their heads together and solved the problem. At a price. The price is that you'll get less than a ``C'' subnet and some things may break.
Reverse lookups - from ACME Byte and Wire (
Ask Mr. DNS):
The problem you have is becoming more common as ISPs give out sub-Class C chunks of IP address space. Until very recently, only four levels of the in-addr.arpa portion of the name space were used--one level per octet of an IP address. Although it's not possible to delegate narrower than the fourth (least significant) octet, some clever folks have found a way around the problem and published anInternet-Draft:
[Ed. This is now at BCP at http://www.ietf.org/rfc/rfc2317.txt ]
The summary of it is this: the owner of the Class C (in this case, your ISP) inserts CNAME records instead of PTR records. These CNAME records point to PTR records in a zone that you manage. Your ISP might be doing this, but Mr. DNS can't tell what they're doing.
Reverse lookups - more from RFC 2317:
Some older versions of name server software will make no effort to find and return the pointed-to name in CNAME records if the pointed-to name is not already known locally as cached or as authoritative data. This can cause some confusion in resolvers, as only the CNAME record will be returned in the response. To avoid this problem it is recommended that the authoritative name servers for the delegating zone (the zone containing all the CNAME records) all run as slave (secondary) name servers for the "child" zones delegated and pointed into via the CNAME records.
Reverse lookups, PTR records - from RFC 1912:
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data.
Reverse lookups, zone file:
A reverse lookup zone file, whether it be classless (containing PTR records pointing to CNAME records at the ISP's DNS server owning you full class C) or whether you have your own full class C IP space (containing PTR records pointing to your own A records), only has functional relevance when it resides on a DNS server within the IP space it describes. This means that there is no benefit to having a slave DNS copy of a reverse lookup zone on a DNS server residing in an IP space not described by the master reverse lookup zone file. In fact, such a file will generate non-fatal "out-of-zone" error messages in your DNS log file when the named daemon is started.
Root Hints file (db.cache, formerly named.root):
"... the root hints tells your name server where the servers for the root zone are. It myst be updated periodically. The root name servers don't change very often, but they do change. A good practice is to check your root hints file every month or two. ... You can retrieve the current list of name servers just by running:
% dig @a.root-servers.net . ns > db.cache"
-- from DNS and BIND, O'Reilly 4th ed., page 157
rrset-order record (round robin) - from DNS and BIND, O'Reilly 4th ed., page 274:
The round robin feature of dealing with multiply defined records is implicit in BIND. Since BIND 8.2 the ability to turn off, or modify, round robin for multiply defined records has been available. The rrset-order option in the named.conf file permits three choices: 1) fixed, yielding a hierarchy based on availability, 2) random, and 3) cyclic, actual round robin. For example:
options {
rrset-order {
type A name "skybuilders.com" order cyclic;
};
};
* The SRV record type allows one to specify services associates with a particular server (corresponding to the target field of the SRV record) and assign a priority and weight to it. Unfortunately SRV record support among clients is thin to non-existant
Security, running BIND not as root:
There are a few discussions about this. First check DNS-HOWTO-6, which talks about restricting zone transfers and creating and running as the user "named" rather that as root. Also look at the general HOWTO called Chroot-BIND-HOWTO, which talks about creating a secure directory referred to as "chroot-jail".
Slave (or Secondary) DNS Servers - also from DNS-HOWTO-5.6:
Your master and slave should share as few as possible of these: Power supply, LAN, ISP, city and country. Always have an off site secondary server as backup.
SOA, general reference:
The SOA record informs as to the best source for DNS information regarding a zone. There can only be one SOA record per zone, including the in-addr.arpa zone. It typically refers to a primary (master) DNS server.
SOA, contents - (From RFC 1912):
- Refresh: How often a secondary will poll the primary server to see if the serial number for the zone has increased (so it knows to request a new copy of the data for the zone).
- Retry: If a secondary was unable to contact the primary at the last refresh, wait the retry value before trying again.
- Expire: How long a secondary will still treat its copy of the zone data as valid if it can't contact the primary.
- Minimum: The default TTL (time-to-live) for resource records -- how long data will remain in other nameservers' cache. ([RFC 1035] defines this to be the minimum value, but servers seem to always implement this as the default value) This is by far the most important timer. Set this as large as is comfortable given how often you update your nameserver. If you plan to make major changes, it's a good idea to turn this value down temporarily beforehand. Then wait the previous minimum value, make your changes, verify their correctness, and turn this value back up. 1-5 days are typical values. Remember this value can be overridden on individual resource records.
SOA, recommended settings - (From RFC 1912):
28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800 ; Expire 7 days
86400 ; Minimum TTL 1 day
SOA admin email reference:
This part of an SOA record entry is referred to as the hostmaster. "The `@' in the e-mail must be replaced by a `.' first. Do not try to put an `@' sign in this address. If the local part of the address already contains a `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by preceding it with `\' character. (e.g., to become John\.Smith.widget.xx) Alternately (and preferred), you can just use the generic name `hostmaster', and use a mail alias to redirect it to the appropriate persons." (From RFC 1912)
SOA serial number entries:
The serial number is in the customary yyyymmdd format with todays serial number appended; this is probably the sixth version of zone file on the 20th of September 1996. Remember that the serial number must increase monotonically, here there is only one digit for todays serial# [199609206], so after 9 edits he has to wait until tomorrow before he can edit the file again. Consider using two digits. (From DNS-HOWTO-7.4)
TTL (time to live) entries:
Before BIND 8.2 TTL entries were optional. BIND now complains about their absence. Get in the habit of placing them in the zone files, usually living at /var/named/[zone/] with file names such as [db.]127.0.0 and [db.]199.103.162 or [db.][ns2.]skybuilders.com .
TTL - (From RFC 1912):
This is by far the most important timer. Set this as large as is comfortable given how often you update your nameserver. If you plan to make major changes, it's a good idea to turn this value down temporarily beforehand. Then wait the previous minimum value, make your changes, verify their correctness, and turn this value back up. 1-5 days are typical values. Remember this value can be overridden on individual resource records.
Windows "TTL for this record":
The "TTL for this record" entry found in the DNS properties interface for SOA records means the following: The TTL applies to the SOA record itself - different records (A, MX, PTR, ect.) in the same zone can have their own TTLs bound to them, overriding the TTL they would otherwise inherit from the SOA record in the zone.
Zone file caveat:
It is extremely important that any zone file you edit is terminated with a newline. Failing to do this will cause a the failure of a zone file to load when the BIND daemon starts.
