Domain Name System is an Internet service that converts a fully qualified domain name, such as www.redhat.com, into its corresponding IP address. A system for converting host names and domain names into IP addresses on the Internet or on local networks that use the TCP/IP protocol. For example, when a Web site address is given to the DNS either by typing a URL in a browser or behind the scenes from one application to another, DNS servers return the IP address of the server associated with that name.
The DNS system is a hierarchy of database servers that start with the root servers for all the top level domains (.com, .net, etc.). The root servers point to authoritative servers residing within ISPs and companies that resolve the host names to complete the name resolution. Using the example www.google.com ,google.com is the domain name, and WWW is the host name. The domain name is the organization's identity on the Web, and the host name is the name of the actual Web server within that domain.
Root Servers
One of several domain name system (DNS) servers on the Internet that contain the IP addresses of the top level domain (TLD) registry organizations that maintain the global domains (.com, .net, .gov, etc.) and country code domains (.uk, .ca, .fr, etc.). The first point of entry for resolving a domain name, there are currently 34 root servers throughout the world operated by government agencies and private organizations, all of which contain the same data.
ISPs and other institutional organizations routinely download copies of the root server tables so that name resolution can be performed locally. There are thousands of these "resolver" computers throughout the Internet that keep the main root servers from becoming overloaded.
Authoritative Name Servers
An authoritative DNS server is a network device (usually a computer) which holds the definitive DNS records for a given domain name. Such a server does not necessarily contain any correct DNS records for domain names other than those for which it is the authority. In the context of the internet the root DNS servers ultimately define which DNS server is the authority for a given domain name.
Caching Name Server
A DNS caching server is a network device (usually a computer) which can be queried to resolve DNS records. It will either return a result from its cache or follow the DNS authority chain to ultimately consult the authoritative DNS server for the domain in question.
DNS records
A DNS server is configured with a "zone file" for each domain that contains "resource records." There are several types of records, and the most common are described below.
DNS A and PTR Records
The Address (A) record associates a domain name with an IP address, which is primary purpose of the DNS system. The Pointer (PTR) record provides data for reverse DNS, which is used for logging the domain name and verification purposes. Also called "inverse DNS," the PTR record is an option..
Aliasing Names (CNAME)
The Canonical Name (CNAME) record is used to create aliases that point to other names. It is commonly used to map WWW, FTP and MAIL subdomains to a domain name; for example, a CNAME record can associate the subdomain FTP.COMPUTERLANGUAGE.COM with COMPUTERLANGUAGE.COM.
DNS Name Servers (NS)
The Name Server (NS) record identifies the authoritative DNS servers for a domain. A second name server is required for redundancy, and two NS records must be in the zone file (one for the primary; one for the secondary). The secondary server queries the primary server for changes.
Mail Servers (MX)
The Mail Exchange (MX) record identifies the server to which e-mail is directed. It also contains a priority field so that mail can be directed to multiple servers in a prescribed order.
First Record in File (SOA)
Start of Authority (SOA) is the first record in the zone file. It contains the name of the primary DNS server, which must correspond to an NS record in the file, the administrator's e-mail address and the length of time records can be cached before going back to the authoritative DNS server.
Command Line Utilities to Resolve Domain to IP address and Vice Versa
============================================================
host (Host Name to IP address)
dig (Host Name to IP address)
dig –x (IP address to Host Name)
nslookup (Hostname to IP address) for linux and windows
If you have your own UNIX machine with a static IP somewhere on the public internet, it's possible to roll your own secure DDNS server using BIND 8 (or greater) and its nsupdate tool on your dynamic UNIX client.
Let's assume that you have a machine on the internet called my.inet.server and a dynamically assigned address on your home machine, my.cable.machine, attached to the net by a cable modem. You own the domain my.home.domain and want to use that name space to statically refer to your cable modem.
On the client side (my.cable.machine), you'll need to:
Install BIND 8 or greater
Generate a TSIG ID key (needed for security)
Set up a script that will notify my.inet.server via nsupdate when your IP changes
On the master nameserver, my.inet.server, you'll need to:
Install BIND 8 or greater
Create a zone for your home network (or you can add to an existing zone)
Create a key entry in /etc/named.conf
Add an allow-update entry for your zone in /etc/named.conf
Make sure that the timeout in your zone file for your dynamically addressed hosts is very low
To create the TSIG key on my.cable.machine, you can run the following command (as root), substituting whatever name you want for keyname:
dnskeygen -H 128 -h -n keyname
This creates two files, Kkeyname.+157+00000.key and Kkeyname.+157+00000.private. The base64 encoded key included in these files is what you'll later want to put in the key directive in /etc/named.conf on your my.inet.server. I'd suggest putting these two files in with your zone records on my.cable.machine, making sure that they are unreadable/unwritable/unexecutable by normal users.
For our example, we'll say that the files are called /etc/namedb/tsig/Kbob.+157+00000.key, which has the following contents:
bob. IN KEY 513 3 157 hrCDCUNBtlY3sgF8NPnJrg==
And /etc/namedb/tsig/Kbob.+157+00000.private, which contains:
Private-key-format: v1.2
Algorithm: 157 (HMAC)
Key: hrCDCUNBtlY3sgF8NPnJrg==
Use an existing zone entry for your domain, or create a new one. It should look something like the following, though there are other options and keywords that you may want to include:
zone "my.home.domain" {
type master;
allow-transfer {
10.0.0.0; // put your slave servers here
};
file "my.home.domain.zone";
};
Be sure that the domain name is registered with the correct nameserver information and that you populate the initial zone file with the proper records (NS, A, CNAME, MX, whatever is required). If you don't know how to do this, invest some time reading the documentation at ISC's BIND site.
On my.inet.server you need to make the following entry in /etc/named.conf:
key bob {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret hrCDCUNBtlY3sgF8NPnJrg==;
};
And then add the allow-update directive to my.home.domain:
zone "my.home.domain" {
type master;
allow-transfer {
10.0.0.0; // replace this with your real slave servers
};
allow-update {
key bob;
};
file "my.home.domain.zone";
};
Be sure to HUP named on my.inet.server after making the changes to /etc/named.conf.
my.inet.server is now ready to accept dynamic updates from my.cable.machine. To send an update, you need to use the nsupdate command on my.cable.machine.
There are lots of DDNS client scripts out there writting in shell, perl, and even C that will allow you to automatically use nsupdate to change the information on my.inet.server. Do a web or a news search for something that will fit your specific platform and versions of DHCP and DNS.
If you wanted to do an interactive update, instead of an automated one, you'd do:
nsupdate -k /etc/namedb/tsig:bob.
This will bring you to a > prompt. Let's say, for example, that you wanted to add an record for mail.my.home.domain to be the IP of my.cable.machine with a TTL of 10 minutes (600 seconds). You want to keep your timeout low so that changes will propagate rapidly in the event of an IP change. I'll use the loopback address of 127.0.0.1 as an example, but be sure to put the correct address in when you're making your actual changes. You'd do the following:
update add mail.my.home.domain. 600 IN A 127.0.0.1
Then hit return again so that nsupdate executes the command you typed in on the previous line. You can do multiple lines of changes destined for the same zone file before you hit return the second time, but if you want to make changes to two different zone files, you need to make the changes in two blocks.
Once you hit return a second time, a lookup is performed on my.home.domain to extract the nameserver information, and then that nameserver (my.inet.server) is contacted and they key authentication takes place. On my.inet.server, you should now see a log file appear wherever you keep your zone file. The log file will be called my.home.domain.zone.log, and it contains the directives to make the changes you specified with the nsupdate command. Eventually, these changes will be rolled into the actual zone file and the log file will be removed. For the time being, though, these entries are merely in named's cache.
Take a look at the nsupdate man page for more information on the nsupdate syntax and usage for your particular version of BIND.
The Domain Name System (or Service) provides a naming resolution service that makes it easy for us humans to use the Internet, among other tasks. Every computer located on the Internet that is publicly accessible uses an unique Internet address, but these Internet addresses are numerical in nature and difficult to remember. To download the latest Linux kernel I point my browser to www.kernel.org, but the server is located at the Internet address of 204.152.191.5, I know which address I would prefer to remember.
The global DNS provides listings for publicly accessible addresses. If you need to access any computer resources inside your own network and your network is using RFC1918 private address allocation, then you will not be able to use the public DNS to resolve your internal network resources. This can be fixed by introducing your own DNS for the internal network.
This chapter will provide the steps necessary to configure your own DNS server to assist in internal name resolution and to provide a caching service for external domains. The Berkeley Internet Name Domain (BIND) software is installed on most Linux distributions, and is also available from the Internet Systems Consortium site.
| | If you are using a dynamic IP address and you would like to host your own website and email servers, then you will also need to review the Dynamic DNS details in Chapter 5. |
Initial Configuration
For a Linux host to use DNS, the system resolver must be told which name servers to use. This information is stored in the /etc/resolv.conf file. As with any configuration, we should always backup the original configuration file before editing it.
| [bash]# cp /etc/resolv.conf /etc/resolv.conf.original |
The resolver on the new DNS server needs to be adjusted so it points to itself for name resolution. Be sure to substitute "example.com" for the domain(s) you are configuring.
| search example.com |
The search parameter defines a list of domains that will be searched when doing hostname queries. The nameserver parameter lists the DNS servers that the host should use for name resolution, in this case itself.
For more information on the system resolver, type "man resolv.conf" at the command prompt.
Setting Daemon Options
The name of the DNS daemon in the BIND package is funnily enough called named, and the main configuration file is located in /etc/named.conf. The configuration can be quite daunting to the new, so lets back it up before making any changes.
| [bash]# cp /etc/named.conf /etc/named.conf.original |
The main configuration file is split into many sections. To configure named to only allow queries from the local server and internal network hosts, add the "listen-on" and "allow-query" options. This will restrict unwanted queries on your server.
| options { |
If your DNS server is located behind a firewall and is having difficulty with resolving names, you may need to uncomment this directive.
| query-source address * port 53; |
The "." zone below tells named to check this file for a list of the root name servers, so it knows where to send external queries. This enables the caching nameserver feature of BIND, by forwarding any unknown requests to the root nameservers listed in the file. This zone should already be listed in the configuration.
| zone "." IN { |
You may find that sending every new DNS query to the root name servers will be a little slow. This can be improved by sending all of your queries to a quicker "upstream" DNS server which will process your request for you. An upstream DNS server (like the ones at your ISP) may already have the query you're after in its cache, or it will normally have a faster backbone link to the root name servers.
To use forwarders you need to have at least one upstream DNS server IP address. Forwarders are a configuration option which needs to be placed inside the "options" section (place under the "allow-query" option above).
| #Place INSIDE 'options' |
| Pay particular attention to the format of the configuration file, missing semicolons will cause the daemon to function irrationally, if at all. |
Adding Your Domain
To provide resolution for the network and computer resources inside your own private network, you need to configure your DNS with your own master DNS zone. The examples below will now guide the configuration of a master zone. These examples are more designed to provide DNS for an internal private network (the home or small office user), and should be used only as a basis for a full authoritative zone. It is also suggested that you configure your domain externally for people to find you on the Internet, see DDNS Service Providers in Chapter 5 if you don't have external name resolution.
Firstly we need to set the zone information in the same named configuration file we used earlier, place the following configuration settings at the bottom of the "/etc/named.conf" file.
| [bash]# vi /etc/named.conf | |
| zone "example.com" IN { | |
The "example.com" zone will be configured as a master using the file "master-example.com" to store all the details about the zone entities (inside the "/var/named/chroot/var/named/data" directory).
You should notice the configuration file is located inside a chroot() jail directory, this is a secure configuration typical of BIND installations. We will not cover chroot here, but be aware of the importance of the directory structure (some Linux versions may differ slightly though).
| [bash]# vi /var/named/chroot/var/named/data/master-example.com |
The following is an example FORWARD zone file for the "example.com" domain name, it is using private addressing for internal only name resolution.
| ; |
The forward zone file allows name resolution from NAME to IP address. To allow name resolution from IP address to NAME, we need to configure a REVERSE zone file.
| [bash]# vi /var/named/chroot/var/named/data/reverse-192.168.1 |
The reverse zone file looks similar to the forward zone file, however you will note the IP addresses are listed first, with the names listed after the pointer directive (PTR).
| ; |
| When configuring the forward and reverse zone files, ensure the IP addresses and the host names are identical in both files. Also, DO NOT add DHCP names and addresses into the files, they will change over time - this can be resolved by using Dynamic DNS below. |
The following are some of the common parameters (and definitions) required to configure our zone files.
| Parameter | Definition |
| $TTL | Time To Live for the zone file |
| IN | The Internet system |
| SOA | Start Of Authority to administer zone |
| NS | Name Server for the zone |
| MX | Mail Exchange for the zone (needs a priority value) |
| A | Address records for hosts / network equipment |
| CNAME | Canonical name for an alias (points to "A" record) |
This line specifies that the host galaxy.example.com is the SOA for the zone, and that sysadmin.example.com is the email address of the zone's technical contact (sysadmin@example.com). It is important to note that a period "." at the end of the domain names indicates they are fully qualified.
| @ IN SOA galaxy.example.com. sysadmin.example.com. |
| | The periods "." located at the end of fully qualified domain names are required. Failure to use periods for FQDNs will cause irregular name resolution. |
The following entry specifies that galaxy.example.com is the mail exchange for the zone, which has been set to priority 10. Leave this as standard unless you know what you are doing, or remove it if you are not running your own email servers.
| MX 10 galaxy ; Mail Exchange |
That completes the configuration of named and the new forward/reverse zone files for our "example.com" domain name. The zone files now need to be chown'd to the named user account and a symbolic link created to the new chroot() jailed file.
| [bash]# chown named.named /var/named/chroot/var/named/data/master-example.com |
| | The file naming convention is typical of Fedora Core and may differ slightly between Linux distributions. |
Checking Your Work
There are several small programs that are in the BIND package that allow integrity checking of the named configuration and zone files. These are great tools to maintain your sanity for testing purposes, as named can be quite particular about problems in the configuration and zone files.
| [bash]# named-checkconf /etc/named.conf |
| The most common errors for misconfiguration in the named file are missing semicolons ";" after parameter settings. |
The zone file should be checked for format consistency, and should resemble the above example.com zone file (substitutions should be made for the domain and hosts being configured).
| [bash]# named-checkzone -d example.com /var/named/data/master-example.com |
| loading "example.com" from "/var/named/master-example.com" class "IN" |
The reverse zone file should also be checked for any errors.
| [bash]# named-checkzone -d 1.168.192.in-addr.arpa /var/named/data/reverse-192.168.1 |
| loading "1.168.192.in-addr.arpa" from "/var/named/data/reverse-192.168.1" class "IN" |
| | The most common errors for misconfiguration in zone files are missing periods "." at the end of fully qualified domain names - especially for the SOA line. |
Starting BIND
After BIND has been configured and there are no errors being returned from the check applications, it is time to set the runlevels and start the service.
| [bash]# chkconfig --level 2345 named on |
A manual check after setting the runlevels confirms that named should start properly after a system reboot.
| [bash]# chkconfig --list named |
Once the service has been started, check the system log to see if there are any runtime errors, and that your newly configured zone is being served successfully. The entries "zone example.com/IN: loaded serial 10" and "zone 1.168.192.in-addr.arpa/IN: loaded serial 10" confirms the zone load was successful and can now be queried.
| [bash]# grep named /var/log/messages |
| galaxy named[19111]: starting BIND 9.3.2 -u named -t /var/named/chroot |
Testing The Server
Now that you have configured your Linux server to query itself for DNS and you have configured the caching server and added your own zone files, its time to test that everything we did was successful. Using the dig application we can check a name resolution for www.example.com, remembering that www in our configuration was an alias that really pointed to galaxy.example.com.
| [bash]# dig www.example.com |
| ; <<>> DiG 9.3.2 <<>> www.example.com |
The above results return the true CNAME for www, and also the A record for galaxy.example.com being 192.168.1.1. In the footer area the query server is set as 127.0.0.1#53, this is the nameserver we originally set in the /etc/resolv.conf file, itself.
We can now check a complete listing of the whole zone file with the following command.
| [bash]# dig example.com AXFR @localhost |
| ; <<>> DiG 9.3.2 <<>> example.com AXFR @localhost |
The most important test is that we are able to successfully resolve domain names that are listed externally to our private network, and cached from the many Internet DNS servers.
| [bash]# dig fedora.redhat.org |
| ; <<>> DiG 9.3.2 <<>> fedora.redhat.org |
Our last test is to confirm that reverse name lookup is available by querying the reverse delegation zone.
| [bash]# host 192.168.1.201 |
| 201.1.168.192.in-addr.arpa domain name pointer wkstn1.example.com. |
Now that the DNS set up is complete, the rest of the workstations inside the private network must be configured to use DNS 192.168.1.1 as the primary name server. For Linux clients this should be listed in /etc/resolv.conf, for Windows clients this should be configured in network settings.
If your internal network is using DHCP to provide IP addresses to your workstations, then "option domain-name-servers 192.168.1.1;" should be set in your "/etc/dhcpd.conf" configuration file.
Configuring Dynamic DNS
As you would have noticed, configuring the forward and reverse zones for a single domain name can take some time to set up correctly and the information these zone files contain are pretty much static, ie they shouldn't change much. However when an IP address or name does change the information in the zone files also need to be changed otherwise the incorrect details will be returned from our DNS server when queried.
To automate this, we use Dynamic DNS. The Internet Systems Consortium corporation (ISC) write both of the BIND and DHCP server suites that are utilised within Fedora Core, when both of these server applications are utilised together, they are able to update themselves whenever details change between DHCP and DNS. This allows an easy method for the forward and reverse DNS zone files to be updated when a dynamic host is allocated an IP address from the DHCP server.
| | The following configuration adjustments assume you have already configured your ISC DHCP daemon in accordance with Chapter 10; please do this first. |
To configure Dynamic DNS, we can generate a basic set of configuration files by running the rndc-confgen application. The first half of the output goes into the "/etc/rndc.conf" file, while the remaining half of the output goes into the "/etc/named.conf" file.
| [bash]# rndc-confgen |
| key "rndckey" { <-- Insert first section into /etc/rndc.conf file |
| | Ensure the "include /etc/rndc.key" directive is removed (or commented out) from both the /etc/rndc.conf and /etc/named.conf files, as you have now created a new configuration. Only ensure there is only ONE "controls" directive in /etc/named.conf. |
To ensure that all zone updates are secure, the update requests and transfers are covered using a secure key (MD5 message hash algorithm) which can be generated easily with the dnssec-keygen application. This key then needs to be replicated and shared with the DNS and DHCP server configuration files.
| [bash]# dnssec-keygen -a HMAC-MD5 -b 128 -n USER DYNAMIC_DNS_KEY | |
| Private-key-format: v1.2 | |
| | The "Kdynamic_dns_key*" file generated in the above step is safe to delete after the DNS and DHCP configuration files have been updated. |
The DNS server configuration file needs to be updated with the secure key declaration, and the zone file settings will also need to be allowed to update if they are done so with the secure key.
| [bash]# vi /etc/named.conf |
| key DYNAMIC_DNS_KEY { |
Now the DHCP server configuration file needs to updated with the same secure key declarations. The server is also told where the primary zone files are stored (on 127.0.0.1) so they can update the DNS server.
| [bash]# vi /etc/dhcpd.conf |
| key DYNAMIC_DNS_KEY { |
| | The secure key must match in both the "/etc/named.conf" and "/etc/dhcpd.conf" files otherwise Dynamic DNS will not work effectively. |
The DHCP server must now be configured to allow client updates, make the following two changes to your "/etc/dhcpd.conf" file.
| [bash]# vi /etc/dhcpd.conf |
| # |
The DHCP daemon now needs to be configured for Dynamic DNS updates.
| [bash]# vi /etc/sysconfig/named |
| OPTIONS=-4 |
| | For detailed information about named daemon, type "man named" at the command prompt. |
Now that the Dynamic DNS configurations are complete, the services need to be restarted.
| [bash]# /etc/init.d/dhcpd restart |
Allow your Dynamic DNS configuration a little time to run (enough for some DHCP clients to renew IP Addresses) and then check the syslog to see if your server is successfully updating the forward and reverse zone files with the new client information.
| [bash]# grep dhcpd /var/log/messages |
| dhcpd: if wkstn3.example.com IN TXT "3168f50e8140ac8a1c8b84d809c6adbefe" rrset exists and wkstn3.example.com IN A 192.168.1.200 rrset exists delete wkstn3.example.com IN A 192.168.1.200: success. |
The named daemon will also add entries to the syslog to identify correct/successful operation.
| [bash]# grep named /var/log/messages |
| named: client 127.0.0.1#32769: updating zone 'example.com/IN': adding an RR at 'wkstn3.example.com' A |
A forward lookup can be checked against a known DHCP client to ensure a successful lookup.
| [bash]# host wkstn3.example.com |
| wkstn3.example.com has address 192.168.1.200 |
A reverse lookup can also be done to ensure reverse delegation can also be confirmed.
| [bash]# host 192.168.1.200 |
| 200.1.168.192.in-addr.arpa domain name pointer wkstn3.example.com |
If you have got this far, you have done well - enjoy a fully automated Dynamic DNS solution.