Download Domain Name Services - UNIX Network Services Administration | CIS 238 and more Study notes Computer Science in PDF only on Docsity!
Domain Name Services
Domain Name System (DNS) converts the name of a Web site (www.linuxhomenetworking.com) to an IP address (65.115.71.34). This step is important, because the IP address of a Web site's server, not the Web site's name, is used in routing traffic over the Internet. This chapter will explain how to configure your own DNS server to help guide Web surfers to your site. A family of Web sites can be loosely described a domain. For example, the domain linuxhomenetworking.com has a number of children, such as www.linuxhomenetworking.com and mail.linuxhomenetworking.com for the Web and mail servers, respectively.
Name Resolution
All UNIX services reference name resolution for connecting. The name service switch file determines which name services a system uses to search for information, and in which order the name services are searched. All Solaris systems use the /etc/nsswitch.conf file as the name service switch file. The nsswitch.conf file is loaded with the contents of a template file during depending on the name service that is selected. The /etc/nsswitch.conf file includes a list of databases that are sources of information about IP addresses, users, and groups. Data for these can come from a variety of sources. For example, host names and host addresses, are located in the /etc/hosts file, NIS, NIS+, LDAP, or DNS. Each database has zero or more sources; the sources and their lookup order are specified in the /etc/nsswitch.conf file There is an entry in the /etc/nsswitch.conf file for each database. Some typical examples of these entries are: There might be a single information source listed, in which case the search terminates if the information is not found. If two or more sources are listed, the first listed source is searched before moving on to the next listed source. files Specifies that entries be obtained from a file stored in the client’s /etc/hosts file nisplus Specifies that entries be obtained from an NIS+ table. For example, the hosts table. nis Specifies that entries be obtained from an NIS map. For example, the hosts map. dns Specifies that host information be obtained from DNS. ldap Specifies that entries be obtained from the LDAP directory. user Specifies that printer information be obtained from the ${HOME}/.printers file When multiple information sources are specified, it is sometimes necessary to define precisely the circumstances under which each source is searched. When a name service is referenced, the attempt to search this source can return one of the following status codes: SUCCESS The requested entry was found in the specified source. UNAVAIL The source is not configured on this system and cannot be used. In other words, the NIS or NIS+ processes could not be found or contacted.
NOTFOUND The source responded with No such entry. In other words, the table, map, or file was accessed, but it did not contain the needed information. TRYAGAIN The source is busy. It might respond if tried again. In other words, the name service is running and was contacted but could not service the request at that moment. For each status code, two actions are possible. When the action is not explicitly specified, the default action is to continue the search using the next specified information source, as follows: SUCCESS = return UNAVAIL = continue NOTFOUND = continue TRYAGAIN = continue
DNS Clients
A DNS client doesn't store DNS information; it must always refer to a DNS server to get it. However, they may cache it (Windows 2000 and after). /etc/resolv.conf file defines the IP address of the DNS server it should use. You shouldn't need to configure any other files. DNS resolution maps a fully qualified domain name (FQDN), such as www.linuxhomenetworking.com, to an IP address. This is also known as a forward lookup. The reverse is also true: By performing a reverse lookup, DNS can determining the fully qualified domain name associated with an IP address. Many different Web sites can map to a single IP address, but the reverse isn't true; an IP address can map to only one FQDN. This means that forward and reverse entries frequently don't match. The reverse DNS entries are usually the responsibility of the ISP hosting your site, so it is quite common for the reverse lookup to resolve to the ISP's domain. This isn't an important factor for most small sites, but some e-commerce applications require matching entries to operate correctly. You may have to ask your ISP to make a custom DNS change to correct this. There are a number of commands you can use do these lookups. Linux uses the host command, for example, but Windows uses nslookup. DNS clients (servers not running BIND) use the /etc/resolv.conf file to determine both the location of their DNS server and the domains to which they belong. The file generally has two columns; the first contains a keyword, and the second contains the desired values separated by commas. Host Command The host command accepts arguments that are either the fully qualified domain name or the IP address of the server when providing results. To perform a forward lookup, use the syntax: host www.linuxhomenetworking.com www.linuxhomenetworking.com has address 65.115.71.
;; ANSWER SECTION: www.hungrypenguin.net. 75583 IN A 67.15.117. ;; AUTHORITY SECTION: hungrypenguin.net. 75583 IN NS ns2.hosteurope.com. hungrypenguin.net. 75583 IN NS ns.hosteurope.com. ;; ADDITIONAL SECTION: ns.hosteurope.com. 158892 IN A 212.67.202. ns2.hosteurope.com. 158892 IN A 212.67.203. ;; Query time: 2474 msec ;; SERVER: 193.231.237.2#53(193.231.237.2) ;; WHEN: Tue Apr 5 16:10:48 2005 ;; MSG SIZE rcvd: 136 Lines beginning with ; are comments that are not part of the information received from the DNS server, but they do reflect some of the low-level protocol used in making the query. The first two lines tell us the version of dig (9.2.4), the command line parameters (www.hungrypenguin.net) and the query options (printcmd). The printcmd option means that the command section (the name given to these first two line) is printed. You can turn it off by using the option +nocmd. Next, dig shows the header of the response it received from the DNS server. Here it reports that an answer was obtained from the query response (opcode: QUERY) and that the response contains one answer, two pieces of information in the authority section, and a further two in the additional section. The flags are used to note certain things about the DNS server and its response; for example, the RA flag shows that recursive queries are available. Next comes the question section, which simply tells us the query, which in this case is a query for the A record of www.hungrypenguin.net. The IN means this is an Internet lookup (in the Internet class). The answer section tells us that www.hungrypenguin.net has the IP address 67.15.117.250. Along with the IP address the DNS record contains some other useful information. The authority section contains a list of name servers that are responsible for the domain name -- those that can always give an authoritative answer. Here we find two name servers listed, which are the name servers of the company with which the domain was registered. To save an extra lookup, dig lists the IP addresses of those name servers in the additional section. Lastly there are some stats about the query. You can turn off these stats using the +nostats option.
By default dig is quite verbose. One way to cut down the output is to use the +short option: dig www.hungrypenguin.net +short which will drastically cut the output to: 67.15.117. However, for diagnosing DNS problems, you generally need fuller output. You can find a happy medium by putting the following lines into a file called .digrc in your home directory: +nocmd +nostats +noquestion Querying different types of DNS records By default dig looks for the A record of the domain specified, but you can specify other records for it to examine. The MX or Mail eXchange record tells mail servers how to route the email for the domain. You can examine your MX records using dig like this: dig hungrypenguin.net MX Note that we asked for hungrypenguin.net and not www.hungrypenguin.net, since normally when you send email to someone, you send it to the domain and not to one of the subdomains like www or ftp -- webmaster@hungrypenguin.net, not webmaster@www.hungrypenguin.net. The salient part of the response is: ;; ANSWER SECTION: hungrypenguin.net. 86400 IN MX 10 mx0.123-reg.co.uk. hungrypenguin.net. 86400 IN MX 20 mx1.123-reg.co.uk. This tells us that there is a mail server called mx0.123-reg.co.uk that handles the email for the hungrypenguin.net domain. There is also a backup server (mx1) that handles the mail if mx0 is unavailable for any reason. The 10 and the 20 are the preference values for the domain; lower values are preferred over the higher ones. Querying other DNS servers By default dig queries the DNS servers listed in your /etc/resolv.conf file, which are normally the DNS servers of your ISP. However, it can also be useful to query other DNS servers, and particularly the authoritative DNS server. If you need to modify your DNS records, for example when migrating your Web site from one hosting provider to another, it is essential to ensure that your DNS records are updated correctly. The problem with DNS updates is that they can take up to 48 hours to propagate through the Internet. For a successful migration it is important to know that your DNS records are correct now rather than waiting 48 hours to discover that they contain an error!
known program in BIND is named, the daemon that responds to DNS queries from remote machines. Most RedHat and Fedora Linux software have the BIND RPM's filename usually starts with the word "bind" followed by a version number, as in bind-9.2.2.P3-9.i386.rpm. You install with the standard rpm command. Use the chkconfig command to get BIND configured to start at boot chkconfig named on To start, stop, and restart BIND after booting, use: service named start service named stop service named restart Remember to restart the BIND process every time you make a change to the configuration file for the changes to take effect on the running process. Authoritative servers provide the definitive information for your DNS domain, such as the names of servers and Web sites in it. They are the last word in information related to your domain. There are 13 root authoritative DNS servers (root authoriatative) that all DNS servers query first. These root servers know all the authoritative DNS servers for all the main domains - .com, .net, and the rest. This layer of servers keep track of all the DNS servers that Web site systems administrators have assigned for their sub domains. For example, when you register your domain my-site.com, you are actually inserting a record on the .com DNS servers that point to the authoritative DNS servers you assigned for your domain. Most servers don't ask authoritative servers for DNS directly, they usually ask a caching DNS server to do it on their behalf. The caching DNS servers then store (or cache), the most frequently requested information to reduce the lookup overhead of subsequent queries. If you want to advertise your Web site www.my-site.com to the rest of the world, then a regular DNS server is what you require.
Dynamic DNS
If your ISP provides your router/firewall with its Internet IP address using DHCP then you must consider dynamic DNS covered in Chapter 19, for now I’m assuming that you are using static Internet IP addresses. Dynamic DNS providers frequently offer you a subdomain of their own site, such as my- site.dnsprovider.com, in which you register your domain on their site.
If you choose to create your very own domain, such as my-site.com, you have to register with a company specializing in static DNS registration and then point your registration record to the intended authoritative DNS for your domain. Popular domain registrars include VeriSign, Register Free, and Yahoo. If you want to use a dynamic DNS provider for your own domain, then you have to point your registration record to the DNS servers of your dynamic DNS provider. (More details on domain registration are coming later in the chapter.). Dynamic DNS is also used for LAN based Operating Systems directory services Active Directory. If your ISP provides you with a fixed or static IP address, and you want to host your own Web site, then a regular authoritative DNS server would be the way to go. A caching DNS name server is used as a reference only, regular name servers are used as the authoritative source of information for your Web site's domain. Caching Nameserver Setting up a caching DNS server is fairly straightforward and works whether or not your ISP provides you with a static or dynamic Internet IP address. After you set up your caching DNS server, you must configure each of your home network PCs to use it as their DNS server. If your home PCs get their IP addresses using DHCP, then you have to configure your DHCP server to make it aware of the IP address of your new DNS server, so that the DHCP server can advertise the DNS server to its PC clients. Off-the-shelf router/firewall appliances used in most home networks usually can act as both the caching DNS and DHCP server, rendering a separate DNS server is unnecessary. The RedHat/Fedora default installation of BIND is configured to convert your Linux box into a caching name server. The only file you have to edit is /etc/resolv.conf; you'll have to comment out the reference to your previous DNS server (most likely your router) with a # or make it point to the server itself using the universal localhost IP address of 127.0.0. So, your old entry of nameserver 192.168.1. would be replaced by a new entry of
nameserver 192.168.1.
or nameserver 127.0.0. The next step is to make all the other machines on your network point to the caching DNS server as their primary DNS server.
Configuring resolv.conf
You'll have to make your DNS server refer to itself for all DNS queries by configuring the /etc/resolv.conf file to reference localhost only.
Reverse lookups operate similarly by scanning an IP address from left to right to get increasingly specific information about an address. The similarity in both methods is that increasingly specific information is sought, but the noticeable difference is that for forward lookups the scan is from right to left, and for reverse lookups the scan is from left to right. This difference can be seen in the formatting of the zone statement for a reverse zone in /etc/named.conf file where the main in-addr.arpa domain, to which all IP addresses belong, is followed by the first 3 octets of the IP address in reverse order. This order is important to remember or else the configuration will fail. This reverse zone definition for named.conf uses a reverse zone file named 192-168-1.zone for the 192.168.1.0/24 network. zone "1.168.192.in-addr.arpa" { type master; notify no; file "192-168-1.zone"; };
Configuring The Zone Files
You need to keep a number of things in mind when configuring DNS zone files: In all zone files, you can place a comment at the end of any line by inserting a semi-colon character then typing in the text of your comment. By default, your zone files are located in the directory /var/named or /var/named/chroot/var/named. Each zone file contains a variety of records (SOA, NS, MX, A, and CNAME) that govern different areas of BIND. Time to Live Value The very first entry in the zone file is usually the zone's time to live (TTL) value. Caching DNS servers cache the responses to their queries from authoritative DNS servers. The authoritative servers not only provide the DNS answer but also provide the information's time to live, which is the period for which it's valid. The purpose of a TTL is to reduce the number of DNS queries the authoritative DNS server has to answer. If the TTL is set to three days, then caching servers use the original stored response for three days before making the query again. $TTL 3D BIND recognizes several suffixes for time-related values. A D signifies days, a W signifies weeks, and an H signifies hours. In the absence of a suffix, BIND assumes the value is in seconds. DNS Resource Records The rest of the records in a zone file are usually BIND resource records. They define the nature of the DNS information in your zone files that's presented to querying DNS clients. They all have the general format: Name Class Type Data
There are different types of records for mail (MX), forward lookups (A), reverse lookups (PTR), aliases (CNAME) and overall zone definitions, Start of Authority (SOA). The data portion is formatted according to the record type and may consist of several values separated by spaces. Similarly, the name is also subject to interpretation based on this factor. The SOA Record The first resource record is the Start of Authority (SOA) record, which contains general administrative and control information about the domain. It has the format: Name Class Type Name-Server Email-Address Serial-No Refresh Retry Expiry Minimum-TTL The record can be long, and will sometimes wrap around on your screen. For the sake of formatting, you can insert new line characters between the fields as long as you insert parenthesis at the beginning and end of the insertion to alert BIND that part of the record will straddle multiple lines. You can also add comments to the end of each new line separated by a semicolon when you do this. Here is an example: @ IN SOA ns1.my-site.com. hostmaster.my-site.com. ( 2004100801 ; serial # 4H ; refresh 1H ; retry 1W ; expiry 1D ) ; minimum The SOA Record Format Field Description Name The root name of the zone. The "@" sign is a shorthand reference to the current origin (zone) in the /etc/named.conf file for that particular database file. Class There are a number of different DNS classes. Home/SOHO will be limited to the IN or Internet class used when defining IP address mapping information for BIND. Other classes exist for non Internet protocols and functions but are very rarely used.. Type The type of DNS resource record. In the example, this is an SOA resource record. Other types of records exist, which I'll cover later. Name-server Fully qualified name of your primary name server. Must be followed by a period. Email-address The e-mail address of the name server administrator. The regular @ in the e-mail address must be replaced with a period instead. The e-mail address must also be followed by a period. Serial-no A serial number for the current configuration. You can use the date format YYYYMMDD with an incremented single digit number tagged to the end. This will allow you to do multiple edits each day with a serial number that
BIND assumes an A record with www refers to www.my-site.com. This may be acceptable in most cases, but if you forget to put the period after the domain in the MX record for my-site.com, BIND attaches the my-site.com at the end, and you will find your mail server accepting mail only for the domain my-site.com.mysite.com.
Sample Forward Zone File
Now that you know the key elements of a zone file, it's time to examine a working example for the domain my-site.com. ; ; Zone file for my-site.com ; ; The full zone file ; $TTL 3D @ IN SOA ns1.my-site.com. hostmaster.my-site.com. ( 200211152 ; serial# 3600 ; refresh, seconds 3600 ; retry, seconds 3600 ; expire, seconds 3600 ) ; minimum, seconds NS www ; Inet Address of nameserver my-site.com. MX 10 mail ; Primary Mail Exchanger localhost A 127.0.0. bigboy A 97.158.253. mail CNAME bigboy ns1 CNAME bigboy www CNAME bigboy Notice that in this example: Server ns1.my-site.com is the name server for my-site.com. In corporate environments there may be a separate name server for this purpose. Primary name servers are more commonly called ns1 and secondary name servers ns2. The minimum TTL value ($TTL) is three days, therefore remote DNS caching servers will store learned DNS information from your zone for three days before flushing it out of their caches. The MX record for my-site.com points to the server named mail.my-site.com. ns1 and mail are actually CNAMEs or aliases for the Web server www. So here you have an example of the name server, mail server, and Web server being the same machine. If they were all different machines, then you'd have an A record entry for each. www A 97.158.253. mail A 97.158.253. ns A 97.158.253.
It is a required practice to increment your serial number whenever you edit your zone file. When DNS is setup in a redundant configuration, the slave DNS servers periodically poll the master server for updated zone file information, and use the serial number to determine whether the data on the master has been updated. Failing to increment the serial number, even though the contents of the zone file have been modified, could cause your slaves to have outdated information.
Sample Reverse Zone File
Now you need to make sure that you can do a host query on all your home network's PCs and get their correct IP addresses. This is very important if you are running a mail server on your network, because sendmail typically relays mail only from hosts whose IP addresses resolve correctly in DNS. NFS, which is used in network-based file access, also requires valid reverse lookup capabilities. This is an example of a zone file for the 192.168.1.x network. All the entries in the first column refer to the last octet of the IP address for the network, so the IP address 192.168.1.100 points to the name bigboy.my-site.com. Notice how the main difference between forward and reverse zone files is that the reverse zone file only has PTR and NS records. Also the PTR records cannot have CNAME aliases. Filename 192-168-1.zone ; ; Zone file for 192.168.1.x ; $TTL 3D @ IN SOA www.my-site.com. hostmaster.my-site.com. ( 200303301 ; serial number 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds NS www ; Nameserver Address 100 PTR bigboy.my-site.com. 103 PTR smallfry.my-site.com. 102 PTR ochorios.my-site.com. 105 PTR reggae.my-site.com. 32 PTR dhcp-192-168-1-32.my-site.com. 33 PTR dhcp-192-168-1-33.my-site.com. 34 PTR dhcp-192-168-1-34.my-site.com. 35 PTR dhcp-192-168-1-35.my-site.com. 36 PTR dhcp-192-168-1-36.my-site.com. Entries for 192.168.1.32 to 192.168.1.36, which are the addresses the DHCP server issues. SMTP mail relay wouldn't work for PCs that get their IP addresses via DHCP if these lines weren't included.
options { allow-transfer {none;}; }; Once applied, your zone transfer test should fail. [root@smallfry tmp]# dig my-site.com AXFR ... ... ; <<>> DiG 9.2.3 <<>> my-site.com AXFR ;; global options: printcmd ; Transfer failed
