DNS and BIND
Introduction
The Domain Name System (DNS organizes the Internet into a
hierarchy of domains, providing a system to resolve easy to remember host and domain names to
their IP address. An example of this is typing www.google.com into a Web browser and having the
google webpage come up. Another example is using the ping [hostname] command instead of the ping [IP address] command.
These are both examples of forward lookups. DNS can provide reverse lookups which is resolving a
hostname when given an IP address. Reverse lookups are handy for web sites tracking users, tools
such as traceroute and ping, checking the reverse DNS records of email addresses, which can be
useful against fighting spam, and so on. DNS also solves name uniqueness problems
on networks: a hostname only needs to be unique in the domain or organization, not the entire
Internet.
File:Docs Drafts AdministrationGuide Servers DNSBIND Introduction hierarchy.png
At the top of the DNS hierarchy is a "dot", which is the root domain. The root domain holds together all domains underneath it. Below the root domain are the familiar com's, edu's, net's, and so on. These are called global Top Level Domains (gTLD). Below gTLDs are subdomains, for example, google.com.
When working with DNS you will hear about zones, which are basically a group of machines within a domain. Every period in a DNS name indicates a point where authority can be delegated, so you can think of a zone as part of the DNS namespace. Using australia.test.com as an example, australia is a zone in the test.com domain.
DNS Queries
In most cases a DNS query is sent when you need the IP address of a hostname. The following example will use the host testhost, and the domain testdomain.com. The process is as follows:
- If the DNS server you are using is using cache facilities, the cache is first checked for any information about testhost.testdomain.com. If an A record for testhost.testdomain.com is found, the process is complete.
- If no information about testhost.testdomain.com exists in cache, the cache is then checked for any information on testdomain.com. This process continues, taking away parts of the DNS namespace from left to right.
- When the query reaches the end, which is the end of .com, a query for testhost.testdomain.com is sent to a root level nameserver. The root level nameserver refers you to a nameserver in the .com domain, which will know more about the query for testhost.testdomain.com.
- The .com level nameserver refers you to a testdomain.com level nameserver. The testdomain.com level nameserver will contain the A record (IP address) for the testhost.testdomain.com system.
Referrals do not contain an answer section (A Resource Records). Instead, they provide an answer section which contains a list of authoritative nameservers to query.
Types of DNS Queries
There are three types of queries you can send to a DNS server. These are recursive, iterative, and inverse:
- Recursive: the DNS server will provide the full answer by following all referrals.
- Iterative: non-recursive. The DNS server first checks its cache. If the query can not be resolved, a referral is sent to the resolver on your local system. Most local resolvers are stub resolvers, which mean they can not follow referrals. Therefore you should have at least one nameserver in
/etc/resolv.confthat can provide recursive queries. - Inverse: inverse queries map a resource record to a domain.
Types of DNS Servers
There are many different types of DNS servers. The following is a list of the most common:
- Master: holds zone files for the domain it is authoritative for. DNS is not owned by one central organization, instead authority is delegated so that everyone running a domain, or a zone, has control over their DNS.
- Slave: downloads zone information from Master DNS servers. Slave servers will reply with an authoritative answer as long as the information was not from cache.
- Advertising: only serves information for the zone it is authoritative for. Does not provide recursive queries. An advertising server will not be able to resolve any queries outside the domain it is authoritative for.
- Cache-only: uses a root hints zone file, and provides recursive queries. A cache-only server does not hold authoritative information or serve a domain.
In this guide BIND and named are the same thing. The actual daemon providing the DNS service is called named. These two terms will be used interchangeably throughout this guide.
Client Configuration
For client configuration there are four important files: /etc/hosts, /etc/host.conf, /etc/nsswitch.conf, and
/etc/resolv.conf.
/etc/hosts
The following is an example /etc/hosts file:
127.0.0.1 localhost.localdomain localhost testmachine ::1 localhost6.localdomain6 localhost6
The syntax is as follows: IP address, Fully Qualified Domain Name (FQDN), aliases or hostnames.A localhost entry is required otherwise applications will break. The second line is for IPv6, which will not be covered in this guide. Using this example, the ping localhost and ping testmachine commands will be the same as using the ping 127.0.0.1 command.
/etc/host.conf
The following is an example /etc/host.conf file:
order hosts,bind multi on nospoof on
The order section defines the order the resolver library will use. In this case the resolver will first query the local hosts file, /etc/hosts, and then a DNS server. The multi on option allows a machine in /etc/hosts to have multiple IP addresses, which is useful for systems with more than one network interface. Use the nospoof on option to help prevent IP spoofing.
/etc/nsswitch.conf
On systems running the GNU version 2 of the standard library, glibc, the /etc/nsswitch.conf file takes precedence over /etc/host.conf. If you are running glibc ignore the /etc/host.conf file. For DNS configuration the most important entry in /etc/nsswitch.conf is the hosts entry:
hosts: files dns
This defines the order the resolver will use. Using this example, the resolver will first query the local hosts file (files). If the query can not be resolved using the information in /etc/hosts, a DNS server is queried (dns). If the /etc/hosts file only contained an entry for localhost, a DNS server would be used for all queries other than those for localhost.
Do not remove
files from the hosts section of /etc/nsswitch.conf. This will cause applications to break and queries to fail if the DNS server becomes unavailable./etc/resolv.conf
The /etc/resolv.conf file is used to list the IP addresses of nameservers to use for DNS queries. This nameservers listed will be used to resolve all queries that can not be resolved using the /etc/hosts file. The following is an example /etc/resolv.conf file:
domain testdomain.com nameserver 192.168.0.1 nameserver 192.168.0.2
Currently you are allowed to have 3 nameserver directives. List these in order of preference. If queries timeout using the first nameserver, the query is attempted again using the second nameserver, and so on.
The domain directive is used to specify a default domain name to append to queries. If DNS fails to lookup a name, the default domain is appended. For example, if a query for testhost fails, the domain entry will be appended, in this example resulting in a query for testhost.testdomain.com. The search directive is similar to the domain directive. The domain directive specifies one default domain, whereas search allows you to specify many. The following is an example of the search directive:
search testdomain1.com search testdomain2.com search testdomain3.com
If a query for testhost.testdomain1.com timed out, a query for testhost.testdomain2.com would be attempted. If this timed out, a query for testhost.testdomain3.com would be attempted.
Installing BIND
Run the following command to install BIND:
yum install bind
DNS and BIND
Configuring BIND
Before you start named you need to create the main configuration file, /etc/named.conf. Zone database files are also be required.
/etc/named.conf
The /etc/named.conf file is the main configuration file for BIND. The first section is the options section. The following is an example options section. A complete /etc/named.conf file follows at the end of this section:
options {
directory "/etc/bind";
allow-query {any;};
recursion no;
pid-file "/var/run/named/named.pid";
zone-statistics yes;
statistics-file "/etc/bind/namedstats.log";
};
The directory directive tells named the default location of the zone database files. If you set directory "/etc/bind"; you will need to create the /etc/bind directory. The user running named requires read access to this directory, and depending on configuration needs, may require write access. This guide assumes that after you have configured the zone database files, named will not require write access to any zone database files. To increase security, place zone database files that require write access in a separate directory to zone database files that only require read access.
The allow-query directive controls who is able to send queries to the DNS server. Using allow-query {any;}; allows anyone to query your DNS server. This is not recommended - queries should be limited to systems on your own subnet. The following is an example that only allows systems in the 192.168.0.0/24 network to query the DNS server:
allow-query {192.168.0.0/24;};
The recursion directive controls the cache functionality. Using recursion no disables caching and will cause named to only return iterative responses. These responses are not stored in cache. If you want to cache queries run a separate caching-server. If that is not possible, limit who can perform recursive queries. This should be limited to the subnet you are on. The following is an example that only allow systems in the 192.168.0.0/24 network to perform recursive queries:
allow-recursion {192.168.0.0/24;};
Control the location of the named pid file using the pid-file directive. The default location is /var/run/named.pid, which by default, should not be writeable by the user running named. Create a directory under /var/run, for example, /var/run/named/, to store the named pid file and give the user you use to run named with write access to this directory. If you use another location other than the default, specify this location using the pid-file directive.
The zone-statistics directive controls whether the DNS server will collect statistically information. If this is set to yes you can view statics using the rndc stats command. These statstics are also used by tools such as dnsgraph, which can be downloaded here: [1]
Running the rndc stats command will write a file called named.stats under the directory specified with the directory directive. Control the location and the name of the statics file using the statistics-file directive.
Configuring Zones
Use the zone directive to define zones. Zone database files contain Resource Records. There are many different types of Resource Records, such as A records which map a hostname to an IP address, CNAME records which are used to map aliases to real names (for example, FTP and WWW mapping to the same server which is running both services), and MX, Mail Exchanger records. This list is note exhaustive, but lists the main Resource Records you will use.
Providing recursive queries outside of your own domain requires a root hints zone. The zone database file for the root hints zone contains a list of top level nameservers. The following is an example root hints zone file in /etc/named.conf. Define zone files underneath the options section in /etc/named.conf:
zone "." {
type hint;
file "/etc/bind/root.hint";
};
The following is an example zone for testdomain.com:
zone "testdomain.com" {
type master;
allow-transfer {192.168.0.5;};
file "/etc/bind/db.testdomain.com";
};
The name of the zone is defined between the talking marks after zone, in this case the zone name is testdomain.com. The type master; option configures the server to be a master server, which means it is authoritative for this zone. If type is set to slave the zone data is transferred from a master server. If you are specifying a slave zone, you need to configure where the master server is using the masters directive. The following is an example slave zone which uses a master server with an IP address of 192.168.0.6:
masters {192.168.0.6;};
The allow-transfer option controls who can perform a zone transfer. Zone transfers are used to replicate zone database files between servers. Definitely restrict who can perform a zone transfer, as zone files are a fantastic point to build up a network topology of a remote network. Restrict zone transfers using IP addresses, as shown in the example testdomain.com zone.
Define the location of the zone database file using the file option. This file is not anything special, it is simply a text file.
Two other zones you may require are zones for localhost and reverse lookups. The first is an example of a localhost host zone:
zone "localhost" {
type master;
file "/etc/bind/db.127";
};
The following is an example reverse lookup zone for a 192.168.0.0/24 network:
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.0.168.192.in-addr.arpa";
};
Reverse lookup zone files are used to support reverse lookups, which is resolving a hostname when given an IP address. A reverse lookup zone is not required.
The in-addr.arpa is a specially reserved domain to support reverse lookups. When a DNS query is performed, the namespace (for example, host.testdomain.com) is searched from right to left. If this was performed on an IP address you would never find the correct network or host:
Starting from the right will not work: 192.168.0.1 Reversing the order allows searching starting from in-addr.arpa: 1.0.168.192.in-addr.arpa
The following is a complete /etc/named.conf example:
options {
directory "/etc/bind";
allow-query {any;};
recursion no;
pidfile "/var/run/named/named.pid";
zone-statistics yes;
statistics-file "/etc/bind/namedstats.log";
};
zone "." {
type hint;
file "/etc/bind/root.hint";
};
zone "testdomain.com" {
type master;
allow-transfer {192.168.0.5;};
file "/etc/bind/db.testdomain.com";
};
zone "localhost" {
type master;
file "/etc/bind/db.127";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.0.168.192.inaddr.arpa";
};
These are the basic configuration options available in /etc/named.conf. For a complete listing please refer to [2]
/etc/named.conf Permissions
Run the following command as root to set the correct user and group for /etc/named.conf:
chown named:named /etc/named.conf
Run the following command as root to set the correct mode:
chmod 600 /etc/named.conf
If you are running SELinux, run the following command to set the correct SELinux context:
chcon -t named_var_run_t /etc/named.conf
Zone Database Files
Zone database files are text files which contain Resource Records. The following is the example of the first section of a zone database file. A ; symbol is used for comments. White spaces will cause problems so use ; symbols if you require spacing. A complete zone database file follows at the end of this section:
$TTL 3D @ IN SOA testdomain.com. hostmaster ( 2007022601 ;serial number 8H ;refresh 2H ;retry 4W ;expiry time 1H ;minimum )
The $TTL value defines the default time-to-live value for Resource Records that do not specify one. This sets the duration for how long a resource record is valid, in other words, how long a server can cache this information without having to make a request for it again.
The @ IN SOA defines the Start Of Authority (SOA). This means the Resource Records in this zone database file contain authoritative information. The @ stands for "replace with the zone name". Since version 9 of BIND this information can be obtained from /etc/named.conf, or it could be written as follows:
testdomain.com. IN SOA testdomain.com. hostmaster
hostmaster is an email address that you can be contacted on. It is important to note the . at the end of testdomain.com.. You must have a trailing . at the end of the domain specified in the SOA.
After the SOA a number of values are defined:
- The serial number
2007022601follows a year:month:day:number of modifications that day syntax. The example2007022601stands for 2007, February 26, and the database file was modified twice that day. Every time a zone database file is modified you must modify the serial number. Secondary nameservers use this information to notice when configuration changes have occurred. The serial number of the zone file on the master server is compared to the serial number of the zone file on the secondary server. If the serial number on the master server is more recent, a zone transfer occurs.
- The refresh time defines how often a secondary server checks its zone database files against a master server.
- When a request or zone refresh fails, the retry value defines how long a secondary server waits before trying to contact a master server.
- If a secondary server is unable to contact a master server, the expiry time defines when the secondary server will discard all zone data.
- The minimum time can cause some debate. In earlier versions of BIND (4,8) this value set the default time-to-live on resource records which did not specify one. In BIND 9 the minimum time is used to define how long a negative answer is cached. A negative answer is the response to a query for a domain which does not exist. Caching negative answers has the same benefits as caching positive responses: decreased resolving time and reduced network bandwidth, as the process of queries and referrals explained earlier does not have to keep taking place once the negative answer is cached. The time-to-live on cached negative answers is the minimum value of the minimum time and the
$TTLvalue. Since the maximum minimum value is 3 hours, this value will usually be used as the time-to-live for cached negative answers. For more information on negative answers visit [3]
Resource Records follow a name ttl class resource record parameter syntax. The following is an example of the Resource Records section of a zone database file:
; name - ttl - class - rr - parameter ; @ IN NS testserver.testdomain.com. @ IN MX 10 mail.testdomain.com. localhost IN A 127.0.0.1 mail IN A 192.168.0.1 testserver IN A 192.168.0.1 testclient IN A 192.168.0.2 laptop IN CNAME test
When a period is appended at the end of a name, for example with the NS and MX records, BIND takes that name as the Fully Qualified Domain Name (FQDN). If a period is not used the zone name will be appended. For example, the testserver A record resolves to the FQDN of testserver.testdomain.com. If it were written as
testserver. IN A then testserverwould be the FQDN, which probably is not what you want since there is no testserver global Top Level Domain.The first Resource Record is an NS entry, which stands for nameserver. The NS entry for testserver.testdomain.com is the actual machine the DNS server is running on. You should have at least two nameserver entries. When you use the dig tool the results will have an authority section, which contains a list of namesevers. A referral has a list of nameservers to query, so without nameserver entries in Resource Records, queries would not be possible.
Note, there is also an A record for the NS entry. Nameservers in your own domain require an A record - these are known as glue records. Glue records hold the DNS system together. Without an A record the testserver.testdomain.com nameserver would not be found, and queries would fail.
The next entry is an MX (Mail Exchanger) record. MX records are used for routing mail. The 10 between the MX and the name of the mail server sets the preference value. The server with the lowest prefernce will have the highest priority. The following is an example of a network with two mail servers. Multiple MX records are good for mail backup incase one server fails:
@ IN MX 10 mail.foo.bar. @ IN MX 20 backup.foo.bar. ; mail IN A 192.168.0.1 backup IN A 192.168.0.2
The mail.foo.bar. server has a higher priority that the backup.foo.bar. server. If the mail.foo.bar. server failed, backup.foo.bar. would be used for mail. There are A records for both mail servers. An A record is required for mail and nameservers within your own domain.
The following is an example A Resource Record, with details following afterwards:
testserver IN A 192.168.0.1
The name on the left hand side of the Resource Record is the hostname, which in this case is testserver. A TTL value is not defined, so this record will get the default of 3 days which was defined at the beginning of the zone database file using the $TTL 3D option.
The IN class stands for Internet Protocol. This is the most common class and most likely the only class you will need for a basic DNS server.
The Resource Record is the type of record, for example A, CNAME, and MX. An A record is used to map a hostname to an IP address. You must only have one A record per hostname: many hostnames pointing to one IP address is fine, but mapping one hostname to multiple IP address will cause routing problems.
The parameter at the end, in this case 192.168.0.1, can be another alias or hostname, or an IP address.
The following is an example of a CNAME resource record, with details following afterwards:
testclient IN A 192.168.0.2 laptop IN CNAME testclient
CNAME records are used to map aliases or hostnames to real names defined in A records. In this example, the ping laptop command would return the same results as the ping testclient command. The following is an example of when CNAMEs can be useful. One server (testserver) is providing both WWW and FTP services:
testserver IN A 192.168.0.1 www IN CNAME testserver ftp IN CNAME testserver
In both of these cases queries for www.testdomain.com and ftp.testdomain.com would direct you to the testserver (with the IP address of 192.168.0.1). However, using a CNAME record results in two lookups: one lookup is required for the CNAME, and another for the A record. Balance the use of CNAME records on heavily loaded servers as they will add more load. The following is a valid example of mapping different hostnames to one IP address, which may be better in high-load situations:
testserver IN A 192.168.0.1 www IN A 192.168.0.1 ftp IN A 192.168.0.1
The following is a complete zone database file:
$TTL 3D @ IN SOA testdomain.com. hostmaster ( 2007022601 ;serial number 8H ;refresh 2H ;retry 4W ;expiry time 1H ;minimum ) @ IN NS testserver.testdomain.com. @ IN MX 10 mail.testdomain.com. localhost IN A 127.0.0.1 mail IN A 192.168.0.1 testserver IN A 192.168.0.1 testclient IN A 192.168.0.2 laptop IN CNAME test
Reverse Lookup Zone Database Files
The following is an example reverse lookup zone database file for a 192.168.0.0/24 network. The SOA section has not been included, since it is the same as the previous example. This example concentrates on the Resource Records:
@ IN NS testserver.testdomain.com. ; 1 IN PTR testserver.testdomain.com. 2 IN PTR testclient.testdomain.com.
PTR (Pointer) records are used in reverse lookup zone database files. PTR records are basically the same as an A record. The values (1,2) in front of the IN class are the host portions of the IP addresses. For example, the testserver.testdomain.com machine uses a 192.168.0.1 IP address. Since this is a 192.168.0.0/24 network, the last octet of the IP address is the host section - therefore a value of 1 is used here. To make it clearer, if a new machine named pc1, with an IP address of 192.168.0.15 was added to the network. The correct entry would be as follows:
15 IN PTR pc1.testdomain.com.
Use Fully Qualified Domain Names in reverse lookup zone files. Using the following example a query for pc1 would result in pc12.0.168.192.in-addr.arpa trying to be resolved. This is not desirable:
15 IN PTR pc1
Localhost Zone Database File
The following is an example localhost zone database file. An NS and A record are required. Localhost queries can usually be resolved by the local machine, so are localhost zone is not necessary in all cases:
$TTL 3D @ IN SOA localhost. root.localhost. ( 2007022601 8H 2H 4W 1H ) @ NS localhost. @ A 127.0.0.1
Root Hints Zone Database File
The Root Hints zone database file contains a list of root level name servers. This file is used for queries outside of your own domain. Run the following command to create the root hints zone database file:
dig at e.root-servers.net . ns > /etc/bind/root.hint
Cache-only /etc/named.conf
The following is an example /etc/named.conf for a cache-only DNS server:
options {
directory "/etc/bind";
allow-query {subnet;};
allow-transfer {none;};
};
zone "." {
type hint;
file "/etc/bind/root.hint";
};
Use allow-query to define a subnet that can send queries to your server. Disable zone transfers using allow-transfer {none;};.
DNS and BIND
Configuring Logging
By default named uses syslog, but you can define your own logging in named.conf. Create a new file named /etc/bind/logging that contains the following:
logging {
channel simple_log {
file "/etc/bind/bind.log" versions 3 size 5m;
severity warning;
print-time yes;
print-severity yes;
print-category yes;
};
category default {
simple_log;
};
};
This is a basic example and should only be used as a guide. This will log all warnings (as defined with severity warning;) to /etc/bind/bind.log. There is a 5 megabyte limit on this file. For more information on logging please refer to [4]
Include the following line in named.conf to include the /etc/bind/logging file:
include "/etc/bind/logging";
After a reload using the rndc reload command the log file will look similar to the following:
10Mar2007 10:52:48.002 general: info: zone testdomain.com/IN: loaded serial 2007031001 10Mar2007 10:52:48.002 notify: info: zone testdomain.com/IN: sending notifies (serial 2007031001) 10Mar2007 10:52:48.002 notify: info: client 192.168.0.1#1024: received notify for zone 'testdomain.com'
DNS and BIND
Configuring and Using the rndc tool
Configuring the rndc tool
The rndc tool is used to control named. This tool can be used locally (on the same machine running named), or remotely. Run the following command to create the rndc configuration files:
/usr/local/sbin/rndc-confgen
This will produce the following output; however, the secret key will be different:
key "rndc-key" {
algorithm hmac-md5;
secret "sqDTXGGjF9nwpb4n6nxJhQ==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
#
The first section (between # Start of rndc.conf and # End of rndc.conf) is for the rndc.conf file. Copy this into a new file and save it as /etc/rndc.conf. The following is an example /etc/rndc.conf file:
key "rndc-key" {
algorithm hmac-md5;
secret "sqDTXGGjF9nwpb4n6nxJhQ==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
The /etc/rndc.conf file is self explanatory: an algorithm and a secret key are defined. You can set the IP address rndc will connect to along with the port using defaultserver and defaultport respectively. The /etc/rndc.conf file is the client side configuration. The IP address and port are for a remote server. If you are running rndc on the same server as named, leave the default-server and default-port options as their default.
Copy the next section into /etc/named.conf after the options section:
key "rndc-key" {
algorithm hmac-md5;
secret "sqDTXGGjF9nwpb4n6nxJhQ==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
This is the server side configuration. You can configure an IP address and port to listen on. These can be left as the default values. If you change the IP address here, conigure the allow { 127.0.0.1; } option with the correct IP address. The /etc/rndc.conf file may also have to be reconfigured.
To keep named.conf tidy you can include the key information in another file. This is an example /etc/bind/named_key file:
key "rndc-key" {
algorithm hmac-md5;
secret "sqDTXGGjF9nwpb4n6nxJhQ==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
Use the include option in /etc/named.conf after the options section to include this file. Change the permissions appropriately, particularly so that the named user has read permissions:
include "/etc/bind/named_key";
Using the rndc tool
The following are useful rndc commands:
rndc stats : write detailed statistical information about the DNS server to a file named named.stats underneath the directory specified using statistics-file in named.conf. This tool requires that zone-statistics yes; be configured in named.conf.
rndc reload : reloads all configuration and zone database files. Run this command after modifying configuration or zone database files so that your changes take affect.
rndc status : display statistical information about the DNS server. The output is similar to the following:
number of zones: 2
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
Run the following command as root to display a full list of rndc commands:
rndc
The rndc tool is located in the /usr/local/sbin/ directory. If this directory is not configured in your $PATH, run rndc using the following command:
/usr/local/sbin/rndc
DNS and BIND
Checking Configuration Files
The /usr/local/sbin directory contains two useful tools: named-checkconf and named-checkzone. These tools are to check whether your configuration files are valid.
Checking /etc/named.conf
Run the named-checkconf command to check whether your named.conf file is valid. If no results are returned, the configuration should be correct:
/usr/local/sbin/named-checkconf /etc/named.conf
Replace /etc/named.conf with the location of your named.conf file.
Checking Zone Database Files
The following is an example of checking the db.testdomain.com zone database file using the named-checkzone command:
/usr/local/sbin/named-checkzone testdomain.com /etc/bind/db.testdomain.com
The first argument is the zone name as it appears in named.conf, in this case testdomain.com. The last argument is the location of the zone database file for testdomain.com, in this case /etc/bind/db.testdomain.com. The output of the named-checkzone command should be similar to the following:
zone testdomain.com/IN: loaded serial 2007031008
OK
DNS and BIND
Starting and Testing BIND
Run the following command to start BIND:
/usr/local/sbin/named -u named -c /etc/named.conf
- The
-u switch specifies the user to run named with.
- The
-c switch specifies the location of the named.conf file.
On certain systems running a 2.6.19+ kernel, starting named may cause a "process 'named' is using obsolete
setsockopt SO_BSDCOMPAT" error. It is safe to ignore this error.
Testing BIND
Run the netstat command to confirm BIND started correctly:
netstat -an
The output will contain items similar to the following:
Active Internet connections (servers and established)
Proto RecvQ SendQ Local Address Foreign Address State
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 192.168.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:1024 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 192.168.0.1:53 0.0.0.0:*
The netstat -an output shows listening sockets on TCP and UDP port 53 (DNS), and TCP port 953 for rndc connections. Note the UDP port 1024 socket - BIND requires a source port for outbound queries, which is a random unprivileged port.
Using dig
The dig tool can be used to test your DNS server. The bind-utils package includes the dig tool. Run the following command to confirm the bind-utils package is installed:
rpm -q bind-utils
If bind-utils is not installed, install the package using the following command:
yum install bind-utils
Run the dig testdomain.com command to check the DNS server. Replace testdomain.com with your domain:
dig testdomain.com
The output will be similar to the following, when using the configuration files in this guide:
; <<>> DiG 9.3.2P2 <<>> testdomain.com
;; global options: printcmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 29672
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0
;; QUESTION SECTION:
;testdomain.com. IN A
;; AUTHORITY SECTION:
testdomain.com. 86400 IN SOA testdomain.com.
hostmaster.testdomain.com. 2007022604 28800 7200 2419200 86400
;; Query time: 1 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Mon Feb 26 17:45:39 2007
;; MSG SIZE rcvd: 69
The AUTHORITY SECTION shows our server is the authoritative for the testdomain.com domain. By default, dig will query for an A record, which is shown in the QUESTION SECTION.
You can use the dig tool to query for a specific host:
dig testserver.testdomain.com
The output will be similar to the following when querying for a hostname:
;; QUESTION SECTION:
;testserver.testdomain.com. IN A
;; ANSWER SECTION:
testserver.testdomain.com. 259200 IN A 192.168.0.1
;; AUTHORITY SECTION:
testdomain.com. 259200 IN NS testserver.testdomain.com.
These results contain an ANSWER SECTION because the query was for an A record for testserver.testdomain.com, which was found on our server. The AUTHORITY SECTION lists the nameservers required to perform the query. Resource Records can be specified using the dig tool. The following is an example of specifying an MX record:
dig MX testdomain.com
The output, using the configuration files in this guide, will be similar to the following:
;; QUESTION SECTION:
;testserver.testdomain.com. IN MX
;; ANSWER SECTION:
testserver.testdomain.com. 259200 IN MX 10 mail.testdomain.com.
;; AUTHORITY SECTION:
testdomain.com. 259200 IN NS testserver.testdomain.com.
;; ADDITIONAL SECTION:
mail.testdomain.com. 259200 IN A 192.168.0.1
testserver.testdomain.com. 259200 IN A 192.168.0.1
The MX record was found as shown in the ANSWER SECTION. This is what you want to have: an MX record and a corresponding A record; however, you can use CNAMEs to reference nameservers and MX records, but this is not recommended.
DNS and BIND
Running BIND in a Chroot Jail
This guide will not go into details. Please navigate to [5] for step-by-step instructions.
- Create a /chroot/named directory, with the correct structure. For example, /dev, /var, and /etc directories.
- Move
/etc/named.conf into the /chroot/named/etc/ directory.
- Move all zone database files to the
/chroot/named/etc/bind/ directory.
- Create the special files required, such as /dev/null and /dev/random.
Once the directory structure and special files have been created, run the following command to start named:
/usr/local/sbin/named -u named -t /chroot/named -c /etc/named.conf
The -t switch specifies the directory the named process will chroot to after processing any options, and before it accepts any queries. The process for named chrooting is as follows: chroot to directory, setuid() before forking, then bind the INET sockets.
DNS and BIND
DNS and Mail
An email address is made up of a user section and a domain section. The user section is in front of the @ and the domain follows after. For local delivery the MTA does not need to perform a DNS query, but when transferring mail to an outside domain it does.
When sending mail outside your own domain the MTA will query for an MX record for the domain specified in the email address. If sending mail to testuser@testdomain.com the MTA will essentially dig MX testdomain.com this will give the MTA the information needed to transfer mail to the testdomain.com domain.
One thing that makes mail different to a normal DNS query is that mail may not be going to the exact machine specified in the address. An example will make this clearer: sending mail to testuser@testdomain.com probably will not send mail to a machine called testdomain.com, but more likely mail.testdomain.com. This is achieved with MX and A records as shown earlier. If the mail server is in your domain you need an A record. A common configuration
problem, although providing a working solution, is to have MX records pointing to a CNAME:
IN MX 10 mail.testdomain.com.
mail IN CNAME server1
server1 IN A 192.168.0.1
This configuration works but can result in the CNAME being lost. There is an A record for server1 and a CNAME for the MX record, but nothing to join them. The correct configuration would be as follows:
IN MX 10 mail.testdomain.com.
mail IN A 192.168.0.1
server1 IN CNAME mail
A records for mail and server1 both pointing to 192.168.0.1 is also acceptable.
DNS and BIND
Security Considerations
This section requires a whole guide. Instead of a complete guide, this section will give points of advice, rather than how to implement each idea:
- Run dedicated servers: an internal advertising and an external server capable of resolving queries outside of your domain.
- Use
allow-transfer {ip-address;}; in named.conf to restrict zone transfers to only specified servers. Do not forget to restrict zone transfers for both master and slave servers.
- Separate cache and DNS functionality:
recursion no; in named.conf will disable caching. If caching must be done on the same server, restrict who can perform recursive, caching queries by using the allow-recursion {subnet;}; in named.conf. Allowing recursive queries from every one increases the chances of DNS cache poisoning. This is a good reason to run dedicated servers, this avoids your entire DNS system being brought down because of one poisoned cache.
- Restrict who can query your DNS server: use
allow-query {subnet;}; to restrict queries except from the specified subnet.
- For iptables, allow UDP and TCP port 53. UDP is used for almost all queries, but queries larger than 512 bytes and zone transfers require TCP. Depending on the information you are serving and whether or not you are allowing zone transfers, you can get away with only allowing UDP port 53. Allow TCP port 953 for rndc, and of course allow traffic on the loopback (lo) interface. The following is an iptables examples (for a machine with only a eth0 network interface card) that allows UDP and TCP port 53, and TCP 953 for rndc:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --dport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 953 -j ACCEPT
This example does not take outbound traffic into consideration.
- The "Securing an Internet Name Server" PDF found at [6] has a lot of information on securing a nameserver.
DNS and BIND
Resources and Thanks
The following is a list of books and resources that were used when researching the content found in this guide. The links were valid at the time of writing:
Linux Network Administrators Guide (Online and Printed Versions)
LPI Certification in a Nutshell
Linux Security Cookbook
Linux Users of Victoria (LUV) mailing lists
IRC: #ubuntu-au on Freenode (thanks for the help realist!)
Linux man pages