1.1 An Introduction to Name Service
Name Service is a term which describes the protocols and process or translating human recognizable computer names into computer addressable addresses. The two types of computer addresses are IPv4 Protocol Addresses and IPv6 Protocol Addresses. Both of these types of addresses are written in octets, or 8 bit numbers, separated by a period. IPv4 are the most common form of address in most networks, and are most often written in Dotted Quad Notation. Dotted Quad Notation is a format for writing IPv4 addresses as four octets separated with periods. An example, of a computer address written in Dotted Quad Notation would be 127.0.0.1. The numerical address consists of four bits of hierarchal address space. IPv6 addresses are organized and written in the same way as IPv4 address, but contain additional bits of address space in order to allow them to accommodate more network nodes.
The format of human readable computer names is a heirchical structured systems called the Domain Name System or DNS. DNS consists of various levels of text components in a heirchary which are seperated by periods, pronounced as "dot".
As an exmaple lets say we have a machine which has been named "hewson". This machine belongs to a programmer in a genetics research group with in the biology department of the GNU College in Dublin, Ireland. To access that system over the internet we would use the name: hewson.gr.bio.gnucd.ie.
The Domain Name System was developed in the early days of the internet, because it is very difficult for humans to remember all of the dotted quad notation addresses of the computers they would like to access. Name Service relies upon databases which store name value pairs consiting of numerical addresses and human recognizable machine names in order to be able to perform fast and accurate translations between the two types of names.
There are two primary types of databases used to perform these associations. When one of the names, either text or numberical is used to determine the other, it is called a lookup. The databases used are a formatted flat text file called a "hosts file", and a distributed text file solution which is also called the Domain Name System, or DNS.
To clarify DNS referes to both a system of heircharily naming networked computers, as well as a distributed database system and associated protocol used to perform Name Service.
Two systems, or mechanisms, are available by which name resolution con occur on every Linux system. These are the two databases which we just mentioned. Again, they are the hosts file and the DNS system. The system configuration file /etc/resolv.conf controls the order in which the two system are checked for a resolution.
When a computer program, such as a web browser, wishes to perform a lookup it makes uses of a group of sub system called the resolver. The resolver is a group of API's which are included in the base operation system libraries.
The hosts file is the origin of the DNS system. When computers where first networked together to form the internet, host to address translations where stored in a flat text file in the /etc directory of unix servers. That file had the name hosts.
As the number of computers connected to the internet grew, the use of a single text file to track them all became impractical due to transmission time, synchronization, and maintenance requirements and DNS was invented. However, the hosts file still exists and is used on modern system today.
An example hosts file typically looks something like this:
# IP-Address Full-Qualified-Hostname Short-Hostname # 127.0.0.1 localhost.localdomain localhost 128.227.212.74 hewson.cns.gnucd.ie hewson
The example hosts file above includes the dns information for the loopback address and for the machine's hostname. In some flavors of Unix the hosts file plays a role is the system boot process, therefor removing the loopback information or the machine entry can cause system problems, even if you're using DNS for name resolution. This is because, a machine may make use of the /etc/hosts file to look up the machine name and its IP address, before the network interface is activated. Many flavors of linux, however, store this information separately in system configuration files or scripts the local hostname, hewson.cns.ufl.edu, in our example could be removed from such a system but the loopback address must remain.
The loopback address, or addresses, represent a special case because DNS was not designed to handle information about IP addresses bound to the loopback interface. This is because of the nature of the loopback, it is only a point back to the machine. Therefor, the loopback configuration is only valid on a single machine and it's configuration is local to that machine and not shared.
In some cases, the hosts file can act as a short cut to reduce administration effort and speed translations. Often, the hosts file is used to look up the machine's own name, or names, including those associated with the loopback device. Commonly access machines can also be placed in the hosts file in order to eliminate the need to make a network query to resolve them.
The hosts file system is robust enough to provide name resolution translations on a small network. For example, if you only have a small number of hosts, or only want to provide looks up for a small private lan, the hosts file can be a good way to do that without all of the overhead of running a full DNS system.
To shortcut the network requirement of resolving a stable host, you can add an entry to the hosts file for that host and modify a your resolv.conf file to tell your system's resolver to check the hosts file first, then to try dns. An example of a entry which you may which to add could be:
205.132.149.222 www.cryptnet.net cryptnet
The disadvantages to using the hosts file instead of DNS are that the hosts file must be maintained, distributed, and kept up to date. This may prove difficult if you are using your hosts file to reference machine which you are not in control of and are not updated on ip and dns changes. While your DNS cache will automatically update in the event of a remote configuration change, your hosts file will not, you must update it yourself.
1.4 The DNS System and Protocol
The DNS implements a distributed hierarchal database. Since it was impractical to store the name to address translation all in one place, the storage was distributed all across the Internet.
DNS still uses, in most cases, flat text files, to store name to address translation, however each domain has a SOA record, or a Source of Authority Record, which designates which server in the distributed system has the right to give trusted translations for a particular domain name and its sub domains.
Name servers are given
1.6 Primary and Secondary Servers
Each domain has a primary server which is where clients requesting information under their authority are directed.
1.5 How DNS Resolution Is Performed
There are a published set of Root Name Servers which provide referrals when necessary to name servers they have deligated authority to.
When you perform a query to resolve an internet domain name, your system send a request to one of the name servers listed in /etc/resolv.conf. That nameserver then checks its cache to see if the host has already been resolved. If a record for the host is not in the cache, or if the cache record has expired, the name server will make a query to one of the root name server which will refer it to the authoritative server for that domain name. Your system will then contact the authoritative server and ask for address resolution.
BIND is the standard software which most people use to provide name service. BIND has a reputation of being insecure having suffered a number of vulnerabilities. BIND was completely rewritten in version 9 and many of the security issues with the codebase appear to have been addressed.
djbdns is a viable BIND alternative. It was written by David J. Bernstein (DJB), to be a much more secure alternative. DJB, in "The djbdns security guarantee", has gone as far as to offer a $500USD reward to the first person to publicly report a verifiable security hole in the latest version of djbdns.
Since resolving a non-local domain name to a routable IP address involves a network connection, domain name resolution can be slow if a site's internet connection is slow.
Details on how to set up a caching only server with djbdns are available on the djbdns website. If you've chosen to run djbdns over BIND, please see How to run a djbdns cache on a workstation.
.Caching Only Server configuration involves the use of the forward directive.
To configure clients to make use of a Caching Only Server, you simply have to list the IP of the Caching Only Server as one of the name server for the system in /etc/resolv.conf. It is best to list a caching only server as the first name server record in resolv.conf since many applications are implemented in a way that gives a preference in terms of listing order.
The first step in deploying name service is to have domain name for which you have the authority to do so. When you register a domain name with a Domain Registrar, you are asked to provide the IP address of an authoritative name server as well as one or more secondary servers. The address you provide are the addresses which the root name server will provide to internet hosts attempting to translate your domain name into a routable address.
4.2 Public and Private IP Allocation
When determining what IP range your network will use, and therefor your name service will resolve, you must determine where and if you will use public and private IP address ranges.
The Source Of Authority designates the primary name server for a given domain.
| Mask | Hosts | NetMask |
|---|---|---|
| /30 | 4 | 255.255.255.252 |
| /29 | 8 | 255.255.255.248 |
| /28 | 16 | 255.255.255.240 |
| /27 | 32 | 255.255.255.224 |
| /26 | 64 | 255.255.255.192 |
| /25 | 128 | 255.255.255.128 |
| /24 | 256 | 255.255.255.0 |
| /23 | 512 | 255.255.254.0 |
| /22 | 1,024 | 255.255.252.0 |
| /21 | 2,048 | 255.255.248.0 |
| /20 | 4,096 | 255.255.240.0 |
| /19 | 8,192 | 255.255.224.0 |
| /18 | 16,384 | 255.255.192.0 |
| /17 | 32,768 | 255.255.128.0 |
| /16 | 65,536 | 255.255.0.0 |
4.6 Delgating Classless in-apra Sub-nets
5.1 Understanding Your Name Service Needs
The DNS system is one of the most scalable and heavily used systems in place on the internet. The robust scalability of the DNS design allows you to size a solution to your own needs and grow it as the work load increases. The wide rage of growth requires you to choose from many different possible topologies for the design deployment of your solution. The type of solution you deploy is most depending upon the amount of work your name servers will need to do and the number of records that they will need to keep track of.
5.2 Primary and Single Secondary
The most common and simple set-up for a DNS infrastructure is a single primary server and a single secondary server. In this environment the primary is capable servicing all requests and the secondary is only to provide fail over in the event that the primary goes down or becomes unreachable.
A significant load of requests is not expected and in most cases, the secondary server can handle all resolution requests with out any degradation in service.
5.3 Primary with Remote Third Party Secondary
This topology design is identical to the design describe in section 2.1. However, a third party is relied upon to provide the secondary DNS from an alternative network location. A list of providers will to provide that service for free is included in section 12.6 for reference.
5.4 Primary and Multiple Secondary
In the case that your domain has more queries that can be handled by a single primary and single secondary server with acceptable response times, more secondary servers may be brought online to take some of the resolution query load.
Multiple secondary servers may also be used to provide additional redundancy.
Finally, multiple secondary servers may be used to improve the security topology of your network.
If you domain has a number of sub domains, you may delegate authority for subdomains to servers which then become the primary servers for those domains. This may allow you to distribute some of the work load of maintaining your DNS tree while providing other DNS administrators authoritative privileges only over part of your domain.
5.6 Stealth Primary and Multiple Secondary
A topology that may be of benefit to domains with a very large number of records is called Stealth Primary. The topology of a Stealth Primary involves setting up a domain as you would in a single primary and multiple secondary servers, however no NS record is given for the primary server.
The lack of an NS record for the primary server relieves the server from answering queries directly. It causes all resolution queries to be performed by the secondary servers. This allows you to perform complex edits on the database of the primary and rely on the secondary to roll in your changes by performing normal transfers.
The benefits of a topology such as this, is that if you make an error during your edit which renders your name record database invalid, the secondaries will continue to resolve requests until such time as the records they currently have expire. Adequately reviews the log files after performing an edit and reload on the primary server should give you sufficient time to correct any errors made in the database files. Corrections can then be done with out any interruption in service.
5.7 Automatically Generated Domain Files
There are many programs available on the internet to generate domain database record files from various sources. Some of these sources include relational databases, LDAP directories, and XML files. These programs can be deployed in solutions in which the primary record system is leveraged to provide edit authorization.
For example, take a large educational institution which uses LDAP to store it's DNS information and generates new BIND record files nightly. The institution has about 200 sub domains for its various departments and many differnet administrators across campus. LDAP acl's can allow a given individual to edit and update DNS only for a given subdomain. Each administrator can perform their own changes reducing the workload of a central DNS administrator.
Programs to deploy these types of topologies are listed in section 12.7.
In order to make you name service infrastructure more resistant to denial of service attacks, you should limit the hosts which are allowed to perform transfers. This will prevent attackers from attempting to throttle your name server or internet connection with malicious transfer requests.
Example:
options {
allow-transfer { 10.10.0/24; };
};
In order to further protect yourself from denial of service attacks, you can also limit the hosts which are allow to submit queries to your name servers.
Example:
options {
allow-query { 10.10.0/24; };
};
All new versions of BIND install in a chroot jail and are run as a regular user. Older versions of BIND ran under the rood userid and had full access to the file system by default.
Each DNS Master Record file contains a series of configuration options which are local only to that domain name record file. These options include information such as how low host translations looked up in this domain should be cashed on remote servers and how often secondary servers should check back for changes to the record file.
Name server records are identified by the NS entry in the domain database file.
Example: IN NS 10.10.1.2.
Host to IP associations are performed by using the A record entry in the domain database file.
Example: hewson IN A 10.10.1.10.
In order to allow you to create aliases for services that can be moved with the service with out having to have clients update their configurations, the CNAME record type can be used.
Example:
hewson IN A 10.10.1.10. www IN CNAME hewson.gnu.edu.
In order for mail to be routed to a host it should be given an MX record. MX is short for Mail Exchange. It is used to notify other internet hosts which servers they should send email to for your domain.
Note: Some Anti-Spam systems will reject mail from servers which do not have valid MX records.
The core goals of any Name Service Deployment should be:
The Time To Live (TTL) value is an integer number of seconds which specifies how long data is valid for until it should be refreshed.
# The following zone definitions don't need any modification. The first one
# is the definition of the root name servers. The second one defines
# localhost while the third defines the reverse lookup for localhost.
zone "." in {
type hint;
file "root.hint";
};
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "gnu.edu" in {
type master;
file "master/l.f.gnu.edu";
allow-transfer {
10.10.10.195;
};
};
@ IN SOA @ ns1.gnu.edu. (
2004041501 ; serial
3600 ; refresh
360 ; retry
3600000 ; expiry
8640 ) ; minimum
IN NS ns1.gnu.edu.
IN NS ns2.gnu.edu.
IN A 10.10.10.222
IN MX 5 kilcher.gnu.edu.
localhost IN A 127.0.0.1
kilcher IN A 10.10.10.222
www IN CNAME gnu.edu.
$TTL 900
; reverse data for 10.10.in-addr.arpa
;
;
@ in soa ns1.gnu.edu. ns2.gnu.edu. (
2004042101 ; Serial
500 ; refresh
200 ; retry
864000 ; expire
1800 ) ; minimum
91117 in ns ns1.gnu.edu.
91117 in ns ns2.gnu.edu.
;+end-soa+
;
10.222 in ptr kilcher.gnu.edu.
DNS is a very complex system and there are many things that can go wrong. Fortunately, most of the problem stem from type-o's in the record files, configuration errors, or simply forgeting to increment a serial number.
The host command allows you to quickly see what a host name or ip number is resolving to. It does not give any details about which servers where queried or what data beyond the actual resolution was returned.
The dig command is a wonderful tool for dns administrators. It performs a record lookup and displays all of the peripheral information about that operation. It will tell you which server was queried, in what order, and what responses they gave.
The check_soa command is useful for determining if delegation has been performed properly in a large domain.
10.4 Performing a Transfer On The Command Line
Transfers can be one of the more complicated aspects of the DNS system. Sometimes the easiest way to trouble shoot a transfer problem is to attempt to perform the transfer by hand.
To perform a transfer by hand, first make sure that the host your are attempting the transfer from is authorized to transfer the domain you are to test, then issue the following command:
bash$ < transfer command >
10.5 Common Error Messages and Solutions
non-glue record below bottom of zone Is a common error that beginning administrators of large domains make when they are first creating their record files. This error occurs when a DNS record is encountered before an NS record in a forward file, or when a reverse record is encountered before an NS record in a reverse file. To avoid this error, it's best to always list your NS records at the top of your domain files.
Delegation -
Lame Server -
Record -
Root Server -
Serial Number -
SOA Record -
Source of Authority [SOA] -
Time To Live [TTL] -
Top Level Domain [TLD] -
Zone -
Zone Transfer -
11.2 Commonly Used NS Record File Options
A - Address Record. This record is used to associate an ipv4 address with a host name.
AAAA - 6 octet Address Record. This record is used to associate an ipv6 address with a host name.
MX - Mail Exchange Record. This record is used to list authorized name servers in a subdomain as well as to order them by preference for remote hosts. Some networks have begun using MX records to verify the source of email, making the assumption that any host sending email without an MX record is likely a spammer and therefor blocking hosts which lack MX records.
NS - Name Server Record.
PTR - Pointer Record. This record is used in in-arpa record files to associate an IP address with a hostname.
SOA - Source of Authority Record.
TXT - Text String which can be upto 255 bytes in length.
12.1 Links to related documents
Copyright (c) 2004 V. Alex Brennen (VAB).
This document is hereby placed in the public domain.
This document lives at http://www.cryptnet.net/fdp/admin/nameservice.html
Version 0.0.0, 2004.04.15 Initial Release.
This document is currently only available in the following languages:
[en] English
If you know of a translation or would like to translate it to another language please let me know so that I can distribute or link to the translated versions.
V. Alex Brennen (Principal Author)
V. Alex Brennen currently works for the University of Florida in the Network Services Group of the Computing and Networking Services Department as a Network Administrator. His duties include the maintenance and configuration of the University's Name Service.