Domain Name ServicesThe Domain Name System (DNS) converts the name of a Web site (www.oakton.edu) to an IP address (192.234.16.8). This is a critical function as the IP address of a Website, not the Website's name, is used in routing traffic over the Internet.

A DNS name is made up of a host name, domain name and organization type. For example: www.oakton.edu - www is the host name, oakton is the domain name, edu is the organization type. A domain may also have a subdomain; a name in front of the domain name. However, the host name is always first and the organization type is always last in a DNS name. Sometimes the hostname is implied; if left off, it points to a default hostname for the domain (see DNS server setup below).

DNS Queries - Recursive and Iterative

With a recursive name query, the DNS client requires that the DNS server respond to the client with either the requested resource record or an error message stating that the record or domain name does not exist. If a DNS server does not have the requested information (cached locally) when it receives a recursive query, it queries other servers until it gets the information, or until the name query fails. The DNS server cannot just refer the DNS client to a different DNS server. Recursive name queries are generally made by a DNS client to a DNS server, or by a DNS server that is configured to pass unresolved name queries to another DNS server configured to use a forwarder.

An iterative name query is one in which a DNS client allows the DNS server to return the best answer it can give based on its cache or zone data. If the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a referral (that is, a pointer to a DNS server authoritative for a lower level of the domain namespace). The DNS client can then query the DNS server for which it obtained a referral. It continues this process until it locates a DNS server that is authoritative for the queried name, or until an error or time-out condition is met. This process is sometimes referred to as "walking the tree," and this type of query is typically initiated by a DNS server that attempts to resolve a recursive name query for a DNS client.

The below figure shows an example of iterative and recursive queries. This example assumes that none of the servers have the requested information in their caches.

Iterative and Recursive Queries

In the example, a client somewhere on the Internet needs the IP address of noam.reskit.com. The following events take place:

1. The client contacts NameServer1 with a recursive query for noam.reskit.com. The server must now return either the answer or an error message.

2. NameServer1 checks its cache and zones for the answer, but does not find it, so it contacts a server authoritative for the Internet (that is, a root server ) with an iterative query for noam.reskit.com.

3. The server at the root of the Internet does not know the answer, so it responds with a referral to a server authoritative for the .com domain.

4. NameServer1 contacts a server authoritative for the .com domain with an iterative query for noam.reskit.com.

5. The server authoritative for the .com domain does not know the exact answer, so it responds with a referral to a server authoritative for the reskit.com domain.

6. NameServer1 contacts the server authoritative for the reskit.com domain with an iterative query for noam.reskit.com.

7. The server authoritative for the reskit.com domain does know the answer. It responds with the requested IP address.

8. NameServer1 responds to the client query with the IP address for noam.reskit.com.

Note that this example shows a DNS server performing direct queries against a root DNS server. This not usually the way DNS lookups are performed due to the overhead involved. Most local DNS servers will refer to an ISP DNS server with a forwarder statement that will cache a larger number of DNS queries eliminating the above overhead.

There are 13 root authoritative DNS servers (root authoriatative) that all DNS servers eventually queryt. These root servers know all the authoritative DNS servers for all the main domains - .com, .net, and the rest amd keep track of all the authorative DNS servers that Web site systems administrators have assigned for their sub domains. For example, when you register your domain example.com, you are actually inserting a record on the .com DNS servers that point to the authoritative DNS servers you assigned for your domain.

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. 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.example.com to the rest of the world, then a regular DNS server is what you require.

Name Resolution

All UNIX services reference name resolution for connecting to other systems. 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. Most LINUX/UNIX 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

Specifically for Domain Name Services (DNS) client or resolver, the DNS client will finally reference /etc/host.conf for how to perform name resolution specifically for DNS.

Local name resolution (/etc/hosts)

If the nsswitch ror host.conf file refers to file as the source for name resolution services, the assumption is there is a local static file on the system containing the name and location of the service. For IP name to address resolution, this file is known as /etc/hosts. The format of /etc/hosts is simple an IP address (one per line), a hostname, a fully qualified hostname (or several hostnames). Windows systems include an hosts file; also a version corresponding to NETBIOS (Windows network) hosts called the lmhosts file.

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 DNS responses (Windows 2000 and after, current LINUX releases). /etc/resolv.conf file defines the IP address of the DNS server it should use. DNS clients 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.

For a client–only, you shouldn't need to configure any other files than /etc/resolv.conf.

/etc/resolv.conf File

Keyword Value

Nameserver IP address of your DNS nameserver. There should be only one entry per "nameserver" keyword. If there is more than one nameserver, you'll need to have multiple "nameserver" lines.

Domain The local domain name to be used by default. If the server is bigboy.example.com, then the entry would just be example.com

Search If you refer to another server just by its name without the domain added on, DNS on your client will append the server name to each domain in this list and do an DNS lookup on each to get the remote servers' IP address. This is a handy time saving feature to have so that you can refer to servers in the same domain by only their servername without having to specify the domain. The domains in this list must separated by spaces.

A sample /etc/resolv.conf:

nameserver 10.1.1.1domain oakton.edusearch cis238.oakton.edu

DNS resolution maps a fully qualified domain name (FQDN), such as www.oakton.edu, to an IP address. This is known as a forward lookup. The reverse is also true: a reverse DNS lookup determines the fully qualified domain name associated with an IP address.

If using an unqualified name on a forward lookup, domain name will be appended to it to perform a lookup; if that fails, domain names in the search list will be appeneded in sequence and a lookup performed .

Many different Web sites can map to a single IP address using host headers (see Apache), 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 and E-Mail applications require matching entries to operate correctly.

There are a number of commands you can use do perform DNS lookups. Linux uses the host, nslookup and dig commands, but Windows uses only nslookup.

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.oakton.edu

To perform reverse lookup: host 192.234.16.8

The host command is an archaic DNS lookup under UNIX/LINUX.

nslookup Command

The nslookup command is the most widely used commands for DNS queries. To perform forward lookup: nslookup www.oakton.edu

To perform a reverse lookup: nslookup 1982.234.16.8

Nslookup can also be entered as a standalone for interactive queries. “?” will give you the options to use in interactive mode.

The nslookup command queries the servers in /etc/resolv.conf for an answer. The server answering is listed in the nslookup response. You can change the default query server with the server command in interactive mode.

The default answer is the A (address) record. You can change the type of record returned using the “set q=” option in interactive mode. For example: set q=MX” will query for mail exchange records for a provided domain name – like oakton.edu. “

nslookupset q=MXoakton.eduexit

“set q=any” will return the most complete information under nslookup for a particular domain.

Dig commandDig comes standard with all the major Linux distributions, and is useful for verifying and troubleshooting DNS problems. It is not currently provided as part of Windows which uses only nslookup for client DNS queries.

To perform a forward lookup, run dig with your domain name as the parameter: dig www.oakton.edu

To perform a reverse lookup, run dig with th IP addres as the parameter: dig 192.234.16.8

The default forward dig answer is the A (address) record of the domain specified (as with nslookyp), but you can specify other records. 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 oakton.edu MX. Note that you ask for oakton.edu, not www.oaktobn.edu, 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. That is: webmaster@oakton.edu, not webmaster@www.oakton.edu.

dig starts by looking in your /etc/resolv.conf file and querying the DNS servers listed there. To use a different name server, call dig with the first parameter of @nameserver. For example: dig @ns.someothernameserver.com www.oakton.edu..

Dig provides a lot more info than nslookup.

user1@Instructor SPECS]$ nslookup www.oakton.eduServer: 10.218.176.84Address: 10.218.176.84#53

Non-authoritative answer:Name: www.oakton.eduAddress: 192.234.16.8

[user1@Instructor SPECS]$ dig www.oakton.edu

; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> www.oakton.edu;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29778;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:;www.oakton.edu. IN A

;; ANSWER SECTION:www.oakton.edu. 85316 IN A 192.234.16.8

;; Query time: 8 msec;; SERVER: 10.218.176.84#53(10.218.176.84);; WHEN: Thu Mar 24 17:32:04 2011;; MSG SIZE rcvd: 48

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 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.

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.oakton.edu. The IN means this is an Internet lookup (in the Internet class).

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 which will drastically cut the output: dig www.oakton.edu +short. 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

DNS Servers

There are several DNS server types: master (authorative), slave (redundant R/O) for inbound queries, caching, forwarding for outbound queries. Split for both inbound and outbound. Off-the-shelf router/firewall appliances used in most home networks usually can act as both the caching DNS server (and DHCP) that are pointed to by the inside system. If you have a DHCP server on your network, you'll need to make it assign the IP address of the Linux box as the DNS server it tells the DHCP clients to use. DNS can reveal a lot about the nature of your domain. You should take some precautions to conceal some of the information for the sake of security.

Dynamic DNS

Most DNS entries as describerd below are static – hardcoded. Dynamic DNS (DDNS) provides real-time updating of DNS entries as opposed to the static coding described below. DDNS is used primarily on internal private networks for LAN based Operating Systems directory services Active Directory; and NDS for (formerly) Netware. DDNS use for Internet is usually restricted to ISP connections where the IP address is not fixed – i.e. home users. If you actually provide a host service out of a floating IP connection; there are tools that allow you to register the domain with a floating IP in the ISPs database. Internal DDNS are not exposed to the Internet for security reasons.

BIND

BIND is an acronym for the Berkeley Internet Name Domain project, which is a group that maintains the DNS-related software suite that runs under Linux. The most well 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: rpm –i bind*

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 startservice named stopservice named restart

Restart the BIND process every time you make a change to the configuration file for the changes to take effect on the running process.

Caching Nameserver(s)

Most Windows and LINUX workstations implement a DNS client with local caching obviating the need for a caching only DNS server. Older UNIX versions may not implement caching DNS clients; also some server types (SENDMAILfor example) that perform numerous DNS lookups may overwhelm the simple cache of a default DNS client. This requires installation of a local caching server.

The RedHat/Fedora default installation of BIND is configured to convert your Linux box into a caching name server. 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 - comment out the previous DNS server and point it to the server itself using the universal localhost IP address of 127.0.0.1: nameserver 127.0.0.1

/etc/named.conf

/etc/named.conf file contains the main DNS server configuration and tells BIND where to find the configuration files for each domain you control. This file usually has two zone areas:

Forward zone file definitions list files to map domains to IP addresses. Reverse zone file definitions list files to map IP addresses to domains.

The actual zone information is usually stored in a separate default directory like /var/named specified in the named.conf file and pointed to by the file directive in the zone definition as in this forward zone example.

zone "example.com" { type master; notify no; allow-query { any; }; file "example.zone";};

The actual zone file records are stored in /var/named/example.zone.

The allow-query directive defines the networks that are allowed to query your DNS server for information on any zone; usualy for security purposes on an internal network. For example, to limit queries to only your 192.168.1.0 network, you could modify the directive to: allow-query { 192.168.1.0/24; };

For reverse zones, format entries to handle the reverse lookups for your IP addresses you will have to create reverse zone entries. ASsin this example using the private 192.168.1.0/24 address space:

zone "1.168.192.in-addr.arpa" { type master; notify no; file "192-168-1.zone";};

This isn't important for the Windows clients on your network, but some Linux applications require valid forward and reverse entries to operate correctly.

The forward domain lookup process for mysite.com scans the FQDN from right to left to get to get increasingly more specific information about the authoritative servers to use. Reverse lookups operate similarly by scanning an IP address from left to right to get increasingly specific information about an address. 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.

Some named,conf examples:

MasterSlaveCacheForwarding

Zone File Configuration

Some rules: 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 (TTL)

The very first entry in the zone file is usually the zone's time to live (TTL) value. To reduce traffic caching DNS servers cache the responses to their queries from authoritative DNS servers for the TTL value. In their query response, 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. For example for a 3 day expiration: $TTL 3DBIND recognizes several suffixes for time-related values: D=days, W=weeks, H=hours; the default value is in seconds.

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.example.com. hostmaster.example.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 both increments and reflects the date on which the change was made.

Refresh Tells the slave DNS server how often it should check the master DNS server. Slaves aren't usually used in home / SOHO environments.

Retry The slave's retry interval to connect the master in the event of a connection failure. Slaves aren't usually used in home / SOHO environments.

Expiry Total amount of time a slave should retry to contact the master before expiring the data it contains. Future references will be directed towards the root servers. Slaves aren't usually used in home/SOHO environments.

Minimum-TTL There are times when remote clients will make queries for subdomains that don't exist. Your DNS server will respond with a no domain or NXDOMAIN response that the remote client caches. This value defines the caching duration your DNS includes in this response.

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.

So in the example, the primary name server is defined as ns1.example.com with a contact e-mail address of hostmaster@example.com. The serial number is 2004100801 with refresh, retry, expiry, and minimum values of 4 hours, 1 hour, 1 week, and 1 day, respectively.

NS, MX, A And CNAME Records

Like the SOA record, the NS, MX, A, PTR and CNAME records each occupy a single line with a very similar general format. Table 18.4 outlines the way they are laid out.

NS, MX, A, PTR and CNAME Record Formats

RecordType

Field Descriptions

Name Field ClassField2

TypeField

DataField

NS Usually blank1 IN NS IP address or CNAME of the name server

MX Domain to be used for mail. Usually the same as the domain of the zone file itself.

IN MX Mail server DNS name

A Name of a server in the domain IN A IP address of server

CNAME Server name alias IN CNAME "A" record name for the server

PTR Last octet of server's IP address IN PTR Fully qualified server name

1. If the search key to a DNS resource record is blank it reuses the search key from the previous record which in this case of is the SOA @ sign.

2. For most home / SOHO scenarios, the Class field will always be IN or Internet. You should also be aware that IN is the default Class, and BIND will assume a record is of this type unless otherwise stated.

3. “@” is used to specify the default value of an unnamed host on a domain, usually “www” to direct queries to a webpage.

If you don't put a period at the end of a host name in a SOA, NS, A, or CNAME record, BIND will automatically tack on the zone file's domain name to the name of the host. So, BIND assumes an A record with www refers to www.example.com. This may be acceptable in most cases, but if you forget to put the period after the domain in the MX record for example.com, BIND attaches the example.com at the end, and you will find your mail server accepting mail only for the domain example.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 example.com. ;; Zone file for example.com;; The full zone file;$TTL 3D@ IN SOA ns1.example.com. hostmaster.example.com. ( 200211152  ; serial# 3600  ; refresh, seconds

3600  ; retry, seconds 3600  ; expire, seconds 3600 )  ; minimum, seconds

NS www  ; Inet Address of nameserverexample.com. MX 10 mail  ; Primary Mail Exchanger localhost A 127.0.0.1bigboy A 97.158.253.26mail CNAME bigboyns1 CNAME bigboywww CNAME bigboy

In this example: Server ns1.example.com is the name server for example.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 example.com points to the server named mail.example.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.26mail A 97.158.253.134ns A 97.158.253.125

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

You may need to make sure that you can do a host query on all your home network's PCs and get their correct IP addresses. For xample an e- mail relay 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.example.com.

Filename 192-168-1.zone ;

; Zone file for 192.168.1.x;$TTL 3D@ IN SOA www.example.com. hostmaster.example.com. ( 200303301  ; serial number 8H  ; refresh, seconds 2H  ; retry, seconds 4W  ; expire, seconds 1D )  ; minimum, seconds

NS www  ; Nameserver Address

100 PTR bigboy.example.com.103 PTR smallfry.example.com.102 PTR ochorios.example.com.105 PTR reggae.example.com.

32 PTR dhcp-192-168-1-32.example.com.33 PTR dhcp-192-168-1-33.example.com.34 PTR dhcp-192-168-1-34.example.com.35 PTR dhcp-192-168-1-35.example.com.36 PTR dhcp-192-168-1-36.example.com.

Notice how the main difference between forward and reverse zone files is that the reverse zone file only has PTR (instead of A) and NS records. PTR records cannot have CNAME aliases. 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. If you want to create a reverse zone file for the public NAT IP addresses for your home network; unfortunately most ISPs won't usually delegate this ability for anyone with less than a Class C block of 256 IP addresses – usually business not home service for DSL or Cable ISP service..

Zone Transfer Protection

The host command does one DNS query at a time, but the dig command is much more powerful. When given the right parameters it can download the entire contents of your domain's zone file. For example, the dig command AFXR zone transfer parameter is used to get the contents of the example.com zone file.

dig example.com AXFR; <<>> DiG 9.2.3 <<>> example.com AXFR;; global options: printcmdexample.com. 3600 IN SOA www.example.com. hostmaster.example.com. 2004110701 3600 3600 3600 3600example.com. 3600 IN NS ns1.example.com.example.com. 3600 IN MX 10 mail.example.com.192-168-1-96.example.com. 3600 IN A 192.168.1.96192-168-1-97.example.com. 3600 IN A 192.168.1.97192-168-1-98.example.com. 3600 IN A 192.168.1.98bigboy.example.com. 3600 IN A 192.168.1.100

gateway.example.com. 3600 IN A 192.168.1.1localhost.example.com. 3600 IN A 127.0.0.1mail.example.com. 3600 IN CNAME www.example.com.ns1.example.com. 3600 IN CNAME www.example.com.ntp.example.com. 3600 IN CNAME www.example.com.smallfry.example.com. 3600 IN A 192.168.1.102www.example.com. 3600 IN A 192.168.1.100example.com. 3600 IN SOA www.example.com. hostmaster.example.com. 2004110701 3600 3600 3600 3600;; Query time: 16 msec;; SERVER: 192.168.1.100#53(192.168.1.100);; WHEN: Sun Nov 14 20:21:07 2004;; XFR size: 16 records

This may not seem like an important security threat at first glance, but it is. Anyone can use this command to determine all your server's IP addresses and from the names determine what type of server it is and then launch an appropriate cyber attack. In a simple home network, without master and slave servers, zone transfers should be disabled. You can do this by applying the allow-transfer directive to the global options section of your named.conf file or use it to restrict queries to specific subnets on an internal commercial network.

options { allow-transfer {none;};};Once applied, your zone transfer test should fail. [root@smallfry tmp]# dig example.com AXFR...... ; <<>> DiG 9.2.3 <<>> example.com AXFR ;; global options: printcmd ; Transfer failed