DNS Service
Setting up a small DNS server is a fairly straightforward, common task for a network administrator or system administrator in a small to medium sized environment. There is a fair amount of jargon involved and some common usage is unnecessary confusing. I'll try to elucidate a few key concepts and demonstrate some important configuration items. I'm using BIND, the most common nameserver daemon.
Authoritative nameservers
Authoritative name service provides data about a zone from the administrators of that zone or from their delegates. In other words, if you run a zone then the zone files that describe that zone are used to answer requests authoritatively, in contrast to a caching resolver which will discover the answers to DNS requests about zones that you do not control. A primary authoritative nameserver will usually notify any secondary nameservers when the zone is updated and the new data will be transferred so that the secondary nameserver(s) remain current.
Caching resolvers
Caching/resolving dns servers provide resolution for your clients. They mean that many resolution requests can be handled without sending packets of the local network. When a client makes a dns request, the cache replies if it can or if not, it finds the answer, caches it for next time (subject to timeouts) and informs the originating client. Also referred to as a recursive resolver because they have to ask someone else for the answers.
- they should be separated from authoritative servers that provide information about zones that you control to the world in general. This separation ideally should be separate machines with separate IP addresses.
- recursive services should only be offered to your own clients not to the internet as a whole.
Split DNS
The term 'Split DNS' refers to the practice of providing different answers to dns resolution queries depending on who is asking. Generally, this is manifested as giving the internet at large a different, reduced view of your organisation's dns information. For example, if you have a database server for internal usage only that does not accept connections from outside your network, why should you publish dns information for it? In particular, you should not publish dns information to the outside world for hosts in private network address space. In BIND9, this is configured using a 'view' block.
Practical configuration for BIND9
Basic caching resolver
The following named.conf creates a caching resolver for use by the local subnet, 192.168.0.0/16.
options { directory "/var/named"; // the default dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; }; view "localhost_resolver" { /* This view sets up named to be a localhost resolver ( caching only nameserver ). * If all you want is a caching-only nameserver, then you need only define this view: */ match-clients { localhost; 192.168.0.0/16;}; recursion yes; # all views that allow recursive service must contain the root hints zone: include "/etc/named.root.hints"; /* these are zones that contain definitions for all the localhost * names and addresses, as recommended in RFC1912 - these names should * ONLY be served to localhost clients: */ include "/etc/named.rfc1912.zones"; };
The files /etc/named.root.hints, /etc/named.rfc1912.zones and the files that they refer to come in the distribution.
Basic Authoritative Service
Appending the following fragment to named.conf will allow this host to serve the allgoodbits.org zone based on the data in /var/named/allgoodbits.org.db.
view "external" { /* This view will contain zones you want to serve only to "external" clients * that have addresses that are not on your directly attached LAN interface subnets: */ match-clients { any; }; match-destinations { any; }; recursion no; // These are your "authoritative" external zones zone "allgoodbits.org" { type master; file "allgoodbits.org.db"; }; // Reverse zone "0.168.192.IN-ADDR.ARPA" { type master; file "192.168.0.info"; }; };
Secondaries and Transfers
Secondary or backup name service allows a zone admin to configure multiple machines to answer requests based on automated replication of the zone information using transfers.
Configuring a primary machine to permit a transfer
A new Access Control List(ACL) stanza must be added to named.conf:
acl secondaries { // IP addresses for any secondary servers 69.93.127.10; 65.19.178.10; };
The zone stanza must be modified as well:
zone "allgoodbits.org" { type master; file "allgoodbits.org.db"; allow-transfer { secondaries; }; };
Configuring a secondary machine to receive a transfer
A zone stanza must be inserted for each zone you want to be a secondary for:
zone "allgoodbits.org" { type slave; file "allgoodbits.org.db"; masters { // IP addresses of one or more masters 97.107.132.102; }; };
Checking it works
Use named-checkconf(8) and/or named-checkzone(8) to verify that your configs are valid.
The most common mistake when modifying a zone file is to forget to update the serial number.
Don't forget to configure both forward and reverse zones.
Example Zone Files
At a basic level, zone files are fairly straightforward to understand if you keep the following definitions in mind:
- A records
- the basic DNS record that translates names to IP addresses
- CNAME
- consider this to be an aliasing of one name to another name
- MX
- Mail eXchanger. These records list which hosts handle mail for the zone
- NS
- Name Server. These records list which hosts are authoritative DNS servers for the zone
- PTR
- PoinTeR records handle reverse resolution, that is mapping addresses to names
Consider using nslint(8) to check on your DNS config; it's likely available in your distro's package archive.
Forward
allgoodbits.org. IN SOA ns1.allgoodbits.org. postmaster.allgoodbits.org. ( 2011100301 ;Serial 1h ;Refresh 1h ;Retry 1w ;Expire 1h ;Negative caching TTL ) ;name servers allgoodbits.org. IN NS ns1.allgoodbits.org. ;A records gw IN A 192.168.0.1 ns1 IN A 192.168.0.2 smtp IN A 192.168.0.3 imap IN A 192.168.0.4 www IN A 192.168.0.5 ;CNAME records mirror IN CNAME www ;MX records allgoodbits.org. IN MX 10 mail
Reverse
A reverse zone file for 192.168.0.1/24 might look like this:
@ IN SOA ns1.allgoodbits.org postmaster.allgoodbits.org ( 2011100301 ; Serial 1h ;Refresh 1h ;Retry 1w ;Expire 1h ;Negative caching TTL ); NS ns1.allgoodbits.org. 1 IN PTR gw 2 IN PTR ns1 3 IN PTR smtp 4 IN PTR imap 5 IN PTR www