Introduction to DNS:
The Domain Name System (DNS) is essentially a distributed database that translates hostnames into IP addresses (and IP addresses back to hostnames). That database also contains information related to each domain, such as how the domain is organized into zones, where to route mail for that domain, and who to contact with questions associated with the domain.
By setting up a DNS server, we become part of a hierarchy of DNS servers that make up the Internet. At the top of this hierarchy is the root server, represented by a dot ("."). Below the root, server is the Top-Level Domains, or TLDs (such as .com, .org, and so on). Domains that individual organizations own and maintain lie below the TLDs. That's where we come in.
As someone who's setting up a DNS server is responsible for managing the hostnames and IP addresses for the computers in the domain (or domains) for which we're responsible. Keeping our DNS information correct means that people can access the services that we want to share, and the Internet as a whole work that much better as a result.
Besides using our DNS server to help people from the Internet find the public servers in our domain, we can also, use DNS to provide name and IP address mapping for computers on our private network.
Setting up a DNS server can be a complex and (these days) potentially dangerous undertaking. A compromised DNS server can cause requests for host addresses to be directed to a cracker's server. The sample DNS server in this section is one created as an example of a DNS server for a home or small office environment.
Understanding DNS:
The basic function of a name server is to answer queries by providing the information that those queries request. A DNS name server primarily translates domain and hostnames into IP addresses. Each domain is typically represented by at least two DNS servers.
1. Primary (Master) Name Server:
This name server contains authoritative information about the domains that it serves. In response to queries for information about its domains, this server provides that information marked as being authoritative. The primary is the ultimate source for data about the domain. The secondary name server only carries the same authority in that it has received and loaded a complete set of domain information from the primary.
2. Secondary (Slave) Name Server:
This name server gets all information for the domain from the primary. As is the case for the primary, DNS considers the secondary's information about the domain that it serves authoritative. (We need to set secondary servers in the NS RR records for the zone in the named.conf file on the primary.)
NS records in the parent zone for a domain list the primary and one or more secondary name servers. This delegation of servers defines the servers that have authority for the zone.
Because zone records change as we add, remove, or reconfigure the computers in the zone, we assign expiration times for information about our zone. We need to set the expiration time in the time to live (TTL) field, in the named.conf file.
Other specialized types of DNS servers are possible as well. Although these types of servers don't have authority for any zones, they can prove useful for special purposes:
1. Caching Name Server:
This type of server simply caches the information it receives about the locations of hosts and domains. It holds information that it obtains from other authoritative servers and reuses that information until the information expires (as set by the TTL fields).
2. Forwarding Name Server:
Creating a server that's not authoritative for a zone but that can forward name server requests to other name servers may prove efficient. This server is essentially a caching name server but is useful in cases where computers lie behind a firewall and in which only one computer can make DNS queries outside that firewall on behalf of all the internal computers.
Understanding Authoritative Zones:
As an administrator of a DNS server, we need to configure several zones. Each zone represents part of the DNS namespace as we view it from our DNS server. Besides the one or more zones representing our domain, we have a zone that identifies our local host and possibly our local, private LAN.
If we configure a server as authoritative for a zone, that server has the last word on resolving addresses for that zone. Our master name server is authoritative for the domain we configure in the "DNS name server example" section but not for domains outside our domain.
Remember that the DNS server that we configure is the ultimate authority for our zone. Other zones don't know how we configure our hostnames and IP addresses unless we properly set up our DNS server to distribute that information across the Internet.
The definitive data that we set up for our domain exists in the form of resource records. Resource records consist of the data associated with all names below the authoritative point in the tree structure. When the DNS server uses these records to reply to queries, it sets the authoritative answer (AA) bit in the packet that includes the reply. The AA bit indicates that our name server has the best and most current information available about our domain.
Understanding BIND:
In Red Hat Linux (and most other Linux and UNIX systems), we implement DNS services by using the Berkeley Internet Name Domain (BIND) software. The Internet Software Consortium maintains BIND.
The Basic Components of BIND Include The Following:
1. DNS Server Daemon (/usr/sbin/named):
The named daemon listens on a port (port number 53 by default) for DNS service requests and then fulfils those requests based on information in the configuration files that we create. Mostly, named receives requests to resolve the hostnames in our domain to IP addresses.
Note: The named daemon actually launches from the /etc/init.d/named startup script. We need to set that script to start automatically after our DNS server is ready to go. We can also use the named startup script to check the status of the named daemon.
2. DNS Configuration Files (named.conf and /var/named/*):
The /etc/named.conf file is where we add most of the general configuration information that we need to define the DNS services for our domain. Separate files in the /var/named directory contain specific zone information.
3. DNS Lookup Tools:
We can use several tools to check that our DNS server is resolving hostnames properly. These include commands such as host, dig, and nslookup (which are part of the bind-utils software package).
To maintain our DNS server correctly, we can also perform the following configuration tasks with our DNS server:
1. Logging:
We can indicate what we want to log and where log files reside.
2. Remote Server Options:
We can set options for specific DNS servers to perform such tasks as blocking information from a bad server, setting encryption keys to use with a server, or defining transfer methods.
We don't need to give out DNS information to everyone who requests it. We can restrict access to those who request it based on the following:
1. Access Control List:
This list can contain those hosts, domains, or IP addresses that we want to group together and apply the same level of access to our DNS server. We create acl records to group those addresses, then indicate what domain information the locations in that acl can or can't access.
2. Listen-on Ports:
By default, our name server accepts only name server requests that come to port 53 on our name server. We can add more port numbers if we want our name server to accept name service queries on different ports.
3. Authentication:
To verify the identities of hosts that are requesting services from our DNS server, we can use keys for authentication and authorization. (The key and trusted-keys statements are used for authentication.)
DNS Name Server Example:
To get an idea of what we need to set up our DNS server, the following sections step us through an example of a DNS server for a domain called yourdomain.com. In the example, we're creating a DNS server for a small office network that includes the following:
1. A private, local network that resides behind a firewall.
2. A server providing DNS service and acting as a firewall between the LAN and the Internet.
In this office, other computers on the LAN are using the same Internet connection for outgoing communications. So, the firewall on the server does network address translation (NAT) to enable the client computers to use the firewall as a router to the Internet. The figure below shows the configuration of the example yourdomain.com domain.
Figure: The sample yourdomain.com DNS server has a combination of public servers and private client computers.
The figure shown above illustrates a small office network that's sharing a single Internet connection. The DNS, Web, mail, and FTP servers all have public IP addresses. (These addresses are fictitious, so please don't try to use them.) Behind the DNS server (which is also operating as a firewall) are four client computers that have private IP addresses.
The job of the DNS server, in this configuration, is to map the names of the public servers (www.yourdomain.com, mail.yourdomain.com, ftp.yourdomain.com, and ns1.yourdomain.com) into the static IP addresses that the ISP assigns (123.45.67.1 through 123.45.67.4). The DNS server also provides DNS service from the private addresses on the LAN, so each computer can reach the others on the LAN without needing to store all computer names in their own /etc/hosts file.
A key feature of this example is that it divides the view of this domain between what the outside world can see and what the computers on the private network can see. Using the view feature of BIND, we create an outside view that lets queries from the Internet find only public servers (Web, Mail, and FTP) in the domain. Then we create an inside view that lets queries from the local LAN find both the public servers and private computers (red, blue, green and yellow) in the domain.
Quick-starting a DNS server:
The DNS server software that comes with the current Red Hat Linux is Berkeley Internet Name Daemon (BIND) version 9. To configure BIND 9, we work with the following components:
1. Configuration file (/etc/named.conf): The main DNS server configuration file.
2. Zone directory (/var/named): The directory containing files that keep information about Internet root DNS servers (named.ca file) and information about the zones that we create for our DNS server.
3. Daemon process (/usr/sbin/named): The daemon process that listens for DNS requests and responds with information that the named.conf file presents.
4. Debugging tools (named-checkconf, and named-checkzone): What we use to determine whether we created our DNS configuration correctly.
BIND 9 also includes tools for creating DNSSEC secured zones. By using these tools, we can create and generate keys to provide authentication and secure address resolution. The example illustrated in these sections doesn't include DNSSEC configuration.
The basic steps in creating a DNS server for our example are as follows:
1. Identifying DNS servers
2. Creating DNS Configuration files (named.conf and /var/names/*)
3. Starting the named daemon
4. Monitoring named activities
In the example configuration, we set up a primary master DNS server and a slave DNS server. The primary holds the authoritative records for the domain. The secondary is there to share requests for information about the domain, particularly in case the primary goes down.
Identifying DNS Servers:
If we didn't have our DNS servers set up at the time that we purchased our domain name with a registration authority, we might have just "parked" the domain name there until we configured our DNS servers. Whenever we're ready to set up our DNS servers, return to that registration authority and provide the following information about our DNS servers:
1. DNS server IP addresses (the static IP addresses of your DNS servers, probably primary and slave).
2. DNS server hostnames (often ns1.yourdomain.com, where we replace yourdomain.com with our domain name for the primary; the slave hostname is ns2.yourdomain.com)
We should register both the primary and slave DNS servers. After we update this record, that information typically takes a day or two to propagate throughout the Internet. Once our DNS servers are registered, we also need to tell the registration authority to use those DNS servers as the authority for addresses in our domain. The registration authority probably offers an online form we can fill out to identify our DNS servers.
Creating DNS configuration files (named.conf and /var/names/*)
In configuring a DNS server, we're actually creating definitions that apply to a particular zone in the public DNS tree, as well as several local zones that apply to our computer and local network. To create a useful DNS server for our example small-office environment, we have the following zones:
1. Public DNS Server Zone:
The DNS server is authoritative for the domain that we're serving. This zone serves the names and IP addresses for our public servers. In the example named.conf file, we need to replace the name yourdomain.com with the domain that we're creating. These records become accessible to everyone on the Internet.
2. Private DNS Server Zone:
Each computer on the private network doesn't need to know the IP addresses for other computers on our private network, a zone is added in the example named.conf file to let the DNS server resolve these addresses. The names and IP addresses (which are private) are available only to computers on your LAN.
Note that by creating different views of these zones, different information will be returned to queries, depending on where the queries come from. For example, when someone from the Internet requests the address of the DNS server (ns1.yourdomain.com), they will get the address 123.45.67.89. However, when a query for ns1.yourdomain.com comes from inside the LAN, the address 10.0.0.1 is returned. Also, any queries from the Internet for addresses of private computers (red.yourdomain.com, blue.yourdomain.com, and so on) are rejected.
Editing /etc/named.conf:
To begin, we configure the /etc/named.conf file on the primary master DNS server representing our example yourdomain.com domain. This example starts from the /etc/named.conf file that comes with the caching-nameserver package in Red Hat Linux. (Make sure that we install the caching-nameserver and bind packages before we continue.) Following are a few tips relating to editing the named.conf file:
1. If a statement contains substatements, make sure that we end the last substatement with a semicolon.
2. Comments can appear in the same formats that popular programming languages use. These languages include C (begin with /* and end with */), C++ (begin with // and go to the end of the physical line), and shell or Perl styles (begin from a # and go to the end of the physical line).
3. A leading exclamation mark (!) negates an element. Putting !123.45.67.89 in a statement causes the IP address 123.45.67.89 not to match the element. (Just make sure that the negation occurs before a positive match or the positive match takes precedence.)
The edited version of the /etc/named.conf file is as follows:
options {
directory "/var/named";
};
acl "mylan" {
127/8; 10.0.0.0/24;
};
view "inside" {
match-clients { "mylan"; };
recursion yes;
zone "." IN {
type hint;
file "named.ca";
};
zone "0.0.10.in-addr.arpa" IN {
type master;
file "yourlan.db";
};
zone "yourdomain.com" {
type master;
file "db.yourdomain.com.inside";
allow-transfer { 10.0.0.2; };
};
};
view "outside" {
match-clients { any; };
recursion no;
zone "." IN {
type hint;
file "named.ca";
};
zone "yourdomain.com" {
type master;
file "db.yourdomain.com.outside";
allow-transfer { 123.45.67.2; };
};
};
include "/etc/rndc.key";
The options definition lies at the beginning of the /etc/named.conf file and identifies the /var/named directory as the location where the zone files reside. The acl lines define the mylan access-control list, which consists of host computers on the 10.0.0.0 local private network and the localhost (127/8). (We use this definition in the 0.0.10.in-addr.arpa zone to enable only users on the LAN to perform reverse lookups of names of computers on the LAN.)
The DNS server is broken up into two views: inside and outside. The inside view defines how IP addresses are resolved for requests that come from the private LAN and localhost (as defined in mylan). By having recursion on (recursion yes), the named daemon will allow name server queries from any computer on the LAN. The outside view defines how queries coming from all other places (presumably, the Internet) are handled. With recursion off (recursion no), only queries from other name servers are honoured. (Turning recursion off can help eliminate a common attack, where a cracker causes your server to seek information from a DNS server controlled by the cracker.)
Each zone entry in the /etc/named.conf file describes the type of server this computer is for the zone (master in all cases here, except the root zone), the database file (in /var/named) that contains records for the zone, and other options relating to the zone records. The named.ca file is set up for you by default. It identifies the locations of the Internet root servers.
I made the other zones (yourlan.db, db.yourdomain.com.inside, db.yourdomain.com.outside and 0.0.10.in-addr.arpa) for this example. For the "inside" view, the yourlan.db file lets the computers on our LAN do reverse address lookups (getting the names for IP address queries). The db.yourdomain.com.inside file contains names and addresses for all computers in our domain (including those on the local LAN). The DNS slave server for the inside view of this domain is at 10.0.0.2. (Clients in our LAN would use 10.0.0.1 and 10.0.0.2 as DNS servers in /etc/resolv.conf.)
For the "outside" view, the db.yourdomain.com.outside file contains names and IP addresses for any computers in our domain we want to make public (computers on our private LAN are excluded). The DNS slave server for the outside view of this domain is 123.45.67.2.
Notice that each zone points to a zone file in the /var/named directory. Table below shows which file in the /var/named directory each zone points to.
Zones and Related Zone Files in DNS Example
| |
Zone
|
Zone File ( in /var/named directory)
|
. (a single dot representing Internet root servers)
|
named.ca
|
0.0.10.in-addr.arpa
|
yourlan.db
|
yourdomain.com (inside view)
|
db.yourdomain.com.inside
|
yourdomain.com (outside view)
|
db.yourdomain.com.outside
|
Be very careful editing the /etc/named.conf file. Forgetting a semicolon is all too easy, resulting in the entire file not loading. To ensure that the /etc/named.conf file doesn't contain any syntax errors, we can run the following command (as root user):
# named-checkconf
If a syntax error is present, a message identifies the problematic line and tells what seems to be wrong with it. If the syntax is correct, continue on to create the zone files in the /var/named directory.
Setting Up The Zone Files:
The /var/named directory contains the zone files that the /etc/named.conf file names. For the example, we need to create only three zone files from scratch. We can (and should) leave the named.ca file alone.
The zone files are where most of the real work of the domain name server occurs. In the example, the db.yourdomain.com.inside file contains the basic records for the yourdomain.com domain, including all private names and addresses. The following is an example of that file:
$TTL 86400
@ IN SOA yourdomain.com. hostmaster.yourdomain.com. (
2003040701; Serial
28800; Refresh
14400; Retry
3600000; Expire
86400 ) ; Minimum
; Name servers
IN NS ns1.yourdomain.com.
IN NS ns2.yourdomain.com.
; Mail server for domain
IN MX 10 mail.yourdomain.com.
; Public servers
ns1 IN A 10.0.0.1
ns2 IN A 10.0.0.2
mail IN A 123.45.67.2
www IN A 123.45.67.3
ftp IN A 123.45.67.4
; Private clients on the LAN
red IN A 10.0.0.2
blue IN A 10.0.0.3
green IN A 10.0.0.4
yellow IN A 10.0.0.5
; EOF
The zone file for our "inside" yourdomain.com contains resource records that include information about the zone. Our DNS server uses the TTL (time-to-live) record to tell name servers that store the information that we provide for this domain how long they can keep the information before they need to throw it out and get fresh information. The first value is the default for the entire zone, and the time is in seconds. So, a value of 86,400 seconds indicates that a client that is using the information should obtain fresh records about this domain every 24 hours.
The SOA line identifies the start of authority for the domain. The at sign (@) represents the yourdomain.com. name. The dot (.) must appear at the end of the domain name. The dot represents the root server of the Internet. If we leave the dot off, our DNS server appends the domain name, so the DNS server will use the name yourdomain.com.yourdomain.com. The hostmaster.yourdomain.com string indicates the e-mail address of the person who is to receive e-mail regarding the domain. (The first dot changes to an @ sign, resulting in hostmaster@yourdomain.com). Other information regarding the SOA record is as follows:
1. Serial:
Start with any number here. If the zone records change, increase the serial number to alert other servers that they need to get fresh data about our domain.
Caution: If we forget to increase the serial number after changing zone records, other servers that cache this data never pick up your changes. To help remember, use the date in the serial number. The number 2003082701 would be for August 27, 2003. The 01 represents the first change made on that day.
2. Refresh:
Defines how often the slave DNS server for the zone checks for changes. (Here, 28,800 seconds represents 8 hours.)
3. Retry:
If the slave can't reach the master, it tries again after this retry interval. (Here, 14,400 seconds represents 4 hours.)
4. Expire:
If the slave can't contact the master within the expire time (3,600,000 seconds, or 1,000 hours, here), the slave discards the data.
5. Minimum:
Defines the cache time to live for negative answers. (Here, it's 86,400 seconds or 24 hours.)
The name server (NS) records define the name servers that represent this zone. In this case, NS records define hosts with the names ns1 and ns2 in yourdomain.com. The MX record indicates the location of the mail server for the domain so that the DNS server can direct e-mail to users in yourdomain.com. The rest of the file defines IP addresses for the private clients and public servers that are associated with the domain. Notice that the server at address 10.0.0.2 serves as a client on the LAN and a slave DNS server.
For the "outside" yourdomain.com zone we made a db.yourdomain.com.outside file using the same information from the "inside" file, with the following exceptions:
1. Removed all references to private clients on the LAN. That way, someone poking around from the Internet can't get information about our private computers.
2. Changed the addresses of the primary and slave DNS servers (ns1 and ns2) to 123.45.67.1 and 123.45.67.2, respectively. In that way, only public addresses for name servers are seen by the public.
The other new file in the example is the yourlan.db file, which contains the information necessary to perform reverse IP lookups for the computers on our LAN. Here's an example:
$TTL 86400
@ IN SOA 0.0.0.10.in-addr.arpa. hostmaster.yourdomain.com. (
2002052701; Serial
28800; Refresh
14400; Retry
3600000; Expire
86400); Minimum
IN NS 0.0.0.10.in-addr.arpa.
1 IN PTR yourdomain.com.
2 IN PTR red.yourdomain.com.
3 IN PTR blue.yourdomain.com.
4 IN PTR green.yourdomain.com.
5 IN PTR yellow.yourdomain.com.
; EOF
The SOA record identifies 0.0.0.10.in-addr.arpa. as the start of authority for the zone. The NS line defines 0.0.0.10.in-addr.arpa. as the name server for the zone. Other records are pointers to hostnames that reverse-map on the 10.0.0. network. The records represent the address for the DNS server (yourdomain.com) and each of the clients on the LAN (red, blue, green, and yellow).
After we finish creating our own zone files, we can use the named-checkzone command to make sure that each zone file is correctly formed. Here is how we'd run the named-checkzone command (as root user) to check the two yourdomain.com zone files:
# named-checkzone yourdomain.com /var/named/db.yourdomain.com.inside
zone yourdomain.com/IN: loaded serial 2003082701
OK
# named-checkzone yourdomain.com /var/named/db.yourdomain.com.outside
zone yourdomain.com/IN: loaded serial 2003082701
OK
The output indicates that both files are okay and that named-checkzone command is able to load the new serial numbers. In this case, the serial number represents the first serial number (01) on August 27, 2003 (2003082701).
Starting The Named (DNS) Daemon:
To start the named daemon and see whether it's working, type the following (as root user):
# /etc/init.d/named start
If the named daemon starts successfully, clients of our DNS server should start getting information about our domain. To set the named daemon to start each time that the system boots up, type the following:
# chkconfig named on
Remember that, whenever we make changes to the named.conf or any of the zone files, we must increase the serial number for anyone checking our domain records to pick up those changes. After that, we should restart the named service too (as root user) as follows:
# /etc/init.d/named restart
If we see the Starting named message, our DNS server is probably up and running. If we want to make sure that our server is correctly resolving addresses, the following section describes some tools that we can use to check our DNS name server.
Checking/Querying That DNS Is Working:
The best way to see if our DNS server is working correctly is to watch it in action. Here are a few commands we can use to check out our DNS server. The first example uses the host command to get the IP address for the host computer named blue in the local domain:
# host blue
blue.yourdomain.com has address 10.0.0.3
Instead of using the simple hostname to get the computer's IP address, you can enter an IP address (instead of the name) or a fully qualified hostname. In the following example, the dig command is used with a domain name to get information about the addresses for a domain:
# dig yourdomain.com
; <<>> DiG 9.2.1 <<>> yourdomain.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43728
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;yourdomain.com. IN A
;; AUTHORITY SECTION:
yourdomain.com. 604800 IN NS ns1.yourdomain.com.
yourdomain.com. 604800 IN NS ns2.yourdomain.com.
;; Query time: 24 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Mon Apr 6 02:12:32 2003
;; MSG SIZE rcvd: 129
Sections in the output from dig include a question section and an authority section. The results show name server assignments and addresses associated with the domain we're querying about. The nslookup command is another tool we can use to look up domain information. In the following example, nslookup looks up the server that is resolving ftp.yourdomain.com:
# nslookup -sil ftp.yourdomain.com
Server: 123.45.67.1
Address: 123.45.67.1#53
Name: ftp.yourdomain.com
Address: 123.45.67.3
The output from the nslookup command includes the name of the computer fulfilling the request and its IP address, along with the name and address of the computer we're asking for. (The -sil prevents a message that nslookup might soon be removed from Red Hat Linux.) Try nslookup with an IP address (such as 10.0.0.1) to make sure reverse lookup works.
To check the status of the named server that is running on our local system, use the same script that starts named. Type the following to check the status of our DNS server daemon:
# /etc/init.d/named status
number of zones: 5
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
If we can't reach the computers that our DNS server is serving by name or IP address, we should make sure that each client's address records are correct. We can also try to ping each client and server computer using the full hostname or IP address.
Getting More Information About BIND:
For details on many other BIND options that, we can refer to several places, as the following list relates:
1. /usr/share/doc/bind-*/arm (Contains HTML and XML versions of the BIND 9 Administrator Reference Manual.
2. Man pages (Type the man command, following it by named or named.conf. These man pages contain terse descriptions of options and variables that relate to the named daemon and named.conf file, respectively.
3. Internet Software Consortium (The ISC Web site contains information and downloads related to BIND. From this site, we find links to BIND mailing lists, security advisories relating to BIND, and BIND history.
No comments:
Post a Comment
If you have any doubt, then don't hesitate to drop comments.