DNS organizes names in a domain hierarchy. A domain is a collection of sites that are related in some sensebecause they form a proper network (e.g., all machines on a campus), because they all belong to a certain organization (e.g., the U.S. government), or because they're simply geographically close. For instance, universities are commonly grouped in the edu domain, with each university or college using a separate subdomain, below which their s are subsumed. Groucho Marx University the groucho.edu domain, while the LAN of the mathematics department is assigned maths.groucho.edu. Hosts on the departmental network would have this domain name tacked onto their name, so erdos would be known as erdos.maths.groucho.edu, which would be the FQDN (see Section 4.1.2 in Chapter 4).
Figure 5-1 shows a section of the namespace. The entry at the root of this tree, which is denoted by a single dot, is quite appropriately called the root domain and encompasses all other domains. To indicate that a name is a FQDN, rather than a name relative to some (implicit) local domain, it is sometimes written with a trailing dot. This dot signifies that the name's last component is the root domain. Depending on its location in the name hierarchy, a domain may be called top-level, second-level, or third-level. More levels of subdivision occur, but they are rare. Table 5-1 lists several top-level domains that you may see frequently.
|
Domain |
Description |
|---|---|
|
(Mostly U.S.) educational institutions such as universities. | |
|
Commercial organizations and companies. | |
|
Noncommercial organizations. | |
|
Originally for gateways and other administrative entities, now commercial organizations and companies as well. | |
|
U.S. military institutions. | |
|
U.S. government institutions. | |
|
For use by companies or commercial entities | |
|
Designated for individuals to use for personal web sites | |
|
Established for informational resource sites |
Historically, the first four of these were assigned to the U.S., but changes in policy have meant that these domains, named global Top-Level Domains (gTLD), are now considered global in nature. Recent negotiations to broaden the range of gTLDs resulted in the last three additions. However, these new options have so far proven to be quite unpopular.
Outside the U.S., each country generally uses a top-level domain of its own named after the two-letter country code defined in ISO-3166. Finland, for instance, uses the fi domain; fr is used by France, de by Germany, and aq by Antarctica. Below this top-level domain, each country's NIC is free to organize names in whatever way they want. Australia has second-level domains similar to the international top-level domains, named com.au and edu.au. Other countries, such as Germany, don't use this extra level, but have slightly long names that refer directly to the organizations running a particular domain. It's not uncommon to see names such as Of course, these national domains do not necessarily mean that a below that domain is actually located in that country; it means only that the has been registered with that country's NIC. A Swedish manufacturer might have a branch in Australia and still have all its s registered with the se top-level domain.
This practice has become more popular in recent years, with countries such as Tuvalu (tv) and Togo (to) selling TLDs to enterprising agents who resell domain names such as go.to or watch.tv.
Organizing the namespace in a hierarchy of domain names nicely solves the problem of name uniqueness; with DNS, a name has to be unique only within its domain to give it a name different from all other s worldwide. Furthermore, fully qualified names are easy to remember. Taken by themselves, these are already very good reasons to split up a large domain into several subdomains.
DNS does even more for you than this. It also allows you to delegate authority over a subdomain to its administrators. For example, the maintainers at the Groucho Computing Center might create a subdomain for each department; we already encountered the math and physics subdomains above. When they find the network at the physics department too large and chaotic to manage from outside (after all, physicists are known to be an unruly bunch), they may simply pass control of the physics.groucho.edu domain to the administrators of this network. These administrators are free to use whatever names they like and assign them IP addresses from their network in whatever fashion they desire, without outside interference.
To this end, the namespace is split up into zones, each rooted at a domain. Note the subtle difference between a zone and a domain: the domain groucho.edu encompasses all s at Groucho Marx University, while the zone groucho.edu includes only the s that are managed by the Computing Center directlythose at the mathematics department, for example. The s at the physics department belong to a different zone, namely physics.groucho.edu. In Figure 5-1, the start of a zone is marked by a small circle to the right of the domain name.
At first glance, all this domain and zone fuss seems to make name resolution an awfully complicated business. After all, if no central authority controls what names are assigned to which s, how is a humble application supposed to know?
Now comes the really ingenious part about DNS. If you want to find the IP address of erdos, for example, DNS says, "Go ask the people who manage it, and they will tell you."
In fact, DNS is a giant distributed database. It is implemented by so-called nameservers that supply information on a given domain or set of domains. For each zone there are at least two, or at most a few, nameservers that hold all authoritative information on s in that zone. To obtain the IP address of erdos, all you have to do is contact the nameserver for the groucho.edu zone, which will then return the desired data.
Easier said than done, you might think. So how do I know how to reach the nameserver at Groucho Marx University? In case your computer isn't equipped with an address-resolving oracle, DNS provides for this, too. When your application wants to look up information on erdos, it contacts a local nameserver, which conducts a so-called iterative query for it. It starts off by sending a query to a nameserver for the root domain, asking for the address of erdos.maths.groucho.edu. The root nameserver recognizes that this name does not belong to its zone of authority, but rather to one below the edu domain. Thus, it tells you to contact an edu zone nameserver for more information and encloses a list of all edu nameservers along with their addresses. Your local nameserver will then go on and query one of those for instance, a.isi.edu. In a manner similar to the root nameserver, a.isi.edu knows that the groucho.edu people run a zone of their own and points you to their servers. The local nameserver will then present its query for erdos to one of these, which will finally recognize the name as belonging to its zone and return the corresponding IP address.
This looks like a lot of traffic for looking up a measly IP address, but it's miniscule considering the speed of networking today. There's still room for improvement with this scheme, however.
To improve response time during future queries, the nameserver stores the information obtained in its local cache. So the next time anyone on your local network wants to look up the address of a in the groucho.edu domain, your nameserver will go directly to the groucho.edu nameserver.[1]
[1] If information weren't cached, DNS would be as inefficient as any other method because each query would involve the root name servers.
Of course, the nameserver will not keep this information forever; it will discard it after some time. The expiration interval is called the time to live (ttl). Each datum in the DNS database is assigned such a ttl by administrators of the responsible zone.
Nameservers that hold all information on s within a zone are called authoritative for this zone. Any query for a within this zone will end up at one of these nameservers.
Authoritative servers must be fairly well synchronized. Thus, the zone's network administrator must make one the primary server, which loads its zone information from datafiles, and make the others secondary servers, which transfer the zone data from the primary server at regular intervals.
Having several nameservers distributes workload; it also provides backup. When one nameserver machine fails in a benign way, such as crashing or losing its network connection, all queries fall back to the other servers. Of course, this scheme doesn't protect you from server malfunctions that produce wrong replies to all DNS requests, such as from software bugs in the server program itself.
You can also run a nameserver that is not authoritative for any domain.[2] This is useful since the nameserver will still be able to conduct DNS queries for the applications running on the local network and cache the information. Hence, it is called a caching-only server.
[2] Well, almost. A nameserver has to provide at least name service for local and reverse lookups of 127.0.0.1.
We have seen that DNS not only deals with IP addresses of s, but also exchanges information on nameservers. DNS databases may have, in fact, many different types of entries.
A single piece of information from the DNS database is called a resource record (RR). Each record has a type associated with it describing the sort of data it represents, and a class specifying the type of network it applies to. The latter accommodates the needs of different addressing schemes, including IP addresses (the IN class), Hesiod addresses (used by MIT's Kerberos system), and a few more. The prototypical resource record type is the A record, which associates a fully qualified domain name with an IP address.
A may be known by more than one name. For example you might have a server that provides both FTP and World Wide Web servers, which you give two names: Example 5-3 shows a part of the domain database that is loaded into the nameservers for the physics.groucho.edu zone.
; Authoritative Information on physics.groucho.edu.
$TTL 3D
@ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
2004010200 ; serial no
8H ; refresh
2H ; retry
4W ; expire
1D ; default ttl
}
;
; Name servers
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Theoretical Physics (subnet 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
nameserver IN CNAME niels
otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
iowa IN AAAA 2001:30fa::3
strange IN A 149.76.12.6
...
; Collider Lab. (subnet 14)
boson IN A 149.76.14.1
muon IN A 149.76.14.7
bogon IN A 149.76.14.12
...Apart from the A and CNAME records, you can see a special record at the top of the file, stretching several lines. This is the SOA resource record signaling the Start of Authority, which holds general information on the zone that the server is authoritative for. The SOA record comprises, for instance, the default time to live for all records.
Note that all names in the sample file that do not end with a dot should be interpreted relative to the physics.groucho.edu domain. The special name (@) used in the SOA record refers to the domain name by itself.
We have seen earlier that the nameservers for the groucho.edu domain somehow have to know about the physics zone so that they can point queries to their nameservers. This is usually achieved by a pair of records: the NS record that gives the server's FQDN, and an A record that associates an address with that name. Since these records are what holds the namespace together, they are frequently called glue records. They are the only instances of records in which a parent zone actually holds information on s in the subordinate zone. The glue records pointing to the nameservers for physics.groucho.edu are shown in Example 5-4.
; Zone data for the groucho.edu zone. .... ; ; Glue records for the physics.groucho.edu zone physics IN NS niels.physics.groucho.edu. IN NS gauss.maths.groucho.edu. niels.physics IN A 149.76.12.1 gauss.maths IN A 149.76.4.23 ...
The primary configuration file of BIND is /etc/named.conf. This style of configuration file has been in use by BIND since Version 8 replaced the old named.boot file.
The syntax is somewhat complex and supports a wide range of functions, but is fairly straightforward when configured to provide basic functionality. Example 5-5 shows a simple configuration file for the vbrew domain.
// This is the primary configuration file for the BIND DNS server named.
//
options {
directory "/var/cache/bind";
allow-query { any; };
recursion no;
zone "local" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "vbrew.com" {
type master;
allow-transfer { 10.10.0.5;
172.16.90.4;
1.2.3.4;
};
file "/etc/bind/db.vbrew.com";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.0";
};If you take a close look, you will see that each of the statements is written similar to a C-like statement with attributes enclosed within { } characters in the named.conf file.
The comments, often indicated by a pound character (#) in Linux, are indicated by two forward slashes (//) instead.
One of the most important options in this configuration file is zone. This is how you tell BIND what it's supposed to know. Beneath zone is another very important option, allow-transfer. This option allows you to set the IP addresses permitted to perform a zone transfer. It is important to restrict this to authorized entities only because it contains a lot of information that could be useful to potential attackers. In the example configuration files, we've restricted zone transfers to the three IP addresses listed.
In the option statement, we've also disabled DNS recursion. This allows us to separate the DNS server functionality from the DNS cache functionality. For security reasons it's a good idea to do this. There have been many papers written on this subject, with one of the best explanations found at http://cr.yp.to/djbdns/separationl. If you need recursive functionality, it is best to configure a caching-only server on an IP address separate from your DNS server. We'll discuss how to make a caching-only server with BIND a little bit later.
If you've decided that you can't live without recursion on the same server, there are ways within the named.conf to restrict recursion to specified domains. By using the allow-recursion option in place of the recursion no, you can specify a range of IP addresses allowed to perform recursive queries.
You've probably noticed that in this file we've included quite a few other entries than just the vbrew.com domain. These are present to be compliant with the specifications established in RFC 1912, "Common DNS Operational and Configuration Errors." This specification requests that sites be authoritative for the local forward and reverse zones, and for broadcast zones.
The BIND configuration supports many more options that we haven't covered here. If you'd like information all of the options, the best source of information is the documentation supplied with the BIND Version 8 or 9 source package.
Master files included with named, zone files, always have a domain associated with them, which is called the origin. This is the domain name specified with the cache and primary options. Within a master file, you are allowed to specify domain and names relative to this domain. A name given in a configuration file is considered absolute if it ends in a single dot; otherwise, it is considered relative to the origin. The origin by itself may be referred to using (@).
The data contained in a master file is split up in RRs, the smallest units of information available through DNS. Each RR has a type. A records, for instance, map a name to an IP address, and a CNAME record associates an alias for a with its official name. Examples appear later in the chapter when a complete set of configuation and zone files are shown.
RR representations in master files share a common format:
[domain] [ttl] [class] type rdata
Fields are separated by spaces or tabs. An entry may be continued across several lines if an opening brace occurs before the first newline and the last field is followed by a closing brace. Anything between a semicolon and a newline is ignored. A description of the format terms follows:
domain
This term is the domain name to which the entry applies. If no domain name is given, the RR is assumed to apply to the domain of the previous RR.
ttl
In order to force resolvers to discard information after a certain time, each RR is associated a time to live (ttl). The ttl field specifies the time in seconds that the information is valid after it has been retrieved from the server. It is a decimal number with at most eight digits.
If no ttl value is given, the field value defaults to that of the minimum field of the preceding SOA record.
class
This is an address class, such as IN for IP addresses or HS for objects in the Hesiod class. For TCP/IP networking, you have to specify IN.
If no class field is given, the class of the preceding RR is assumed.
type
This describes the type of the RR. The most common types are A, SOA, PTR, and NS. The following sections describe the various types of RRs.
rdata
This holds the data associated with the RR. The format of this field depends on the type of RR. In the following discussion, it will be described for each RR separately.
The following is partial list of RRs to be used in DNS master files. There are a couple more of them that we will not explain; they are experimental and of little use, generally.
SOA
This RR describes a zone of authority. It signals that the records following the SOA RR contain authoritative information for the domain. Every master file included by a primary statement must contain an SOA record for this zone. The resource data contains the following fields:
origin
This field is the canonical name of the primary nameserver for this domain. It is usually given as an absolute name.
contact
This field is the email address of the person responsible for maintaining the domain, with the "@" sign replaced by a dot. For instance, if the responsible person at the Virtual Brewery were janet, this field would contain janet.vbrew.com.
serial
This field is the version number of the zone file, expressed as a single decimal number. Whenever data is changed in the zone file, this number should be incremented. A common convention is to use a number that reflects the date of the last update, with a version number appended to it to cover the case of multiple updates occurring on a single day, e.g., 2000012600 being update 00 that occurred on January 26, 2000.
The serial number is used by secondary nameservers to recognize zone information changes. To stay up to date, secondary servers request the primary server's SOA record at certain intervals and compare the serial number to that of the cached SOA record. If the number has changed, the secondary servers transfer the whole zone database from the primary server.
refresh
This field specifies the interval in seconds that the secondary servers should wait between checking the SOA record of the primary server. Again, this is a decimal number with at most eight digits.
Generally, the network topology doesn't change too often, so this number should specify an interval of roughly a day for larger networks, and even more for smaller ones.
retry
This number determines the intervals at which a secondary server should retry contacting the primary server if a request or a zone refresh fails. It must not be too low, or a temporary failure of the server or a network problem could cause the secondary server to waste network resources. One hour, or perhaps one-half hour, might be a good choice.
expire
This field specifies the time in seconds after which a secondary server should finally discard all zone data if it hasn't been able to contact the primary server. You should normally set this field to at least a week (604,800 seconds), but increasing it to a month or more is also reasonable.
minimum
This field is the default time to live value for resource records that do not explicitly contain one. The ttl value specifies the maximum amount of time other nameservers may keep the RR in their cache. This time applies only to normal lookups, and has nothing to do with the time after which a secondary server should try to update the zone information.
If the topology of your network does not change frequently, a week or even more is probably a good choice. If single RRs change more frequently, you could still assign them smaller ttls individually. If your network changes frequently, you may want to set minimum to one day (86,400 seconds).
This record associates an IP address with a name. The resource data field contains the address in dotted quad notation.
For each name, there must be only one A record. The name used in this A record is considered the canonical name. All other names are aliases and must be mapped onto the canonical name using a CNAME record. If the canonical name of our were vlager, we'd have an A record that associated that name with its IP address. Since we may also want another name associated with that address, say news, we'd create a CNAME record that associates this alternate name with the canonical name. We'll talk more about CNAME records shortly.
This record is exactly the same as the A record, but is used exclusively for IPv6 addresses.
NS
NS records are used to specify a zone's primary server and all its secondary servers. An NS record points to a master nameserver of the given zone, with the resource data field containing the name of the nameserver.
You will meet NS records in two situations: the first is when you delegate authority to a subordinate zone; the second is within the master zone database of the subordinate zone itself. The sets of servers specified in both the parent and delegated zones should match.
The NS record specifies the name of the primary and secondary nameservers for a zone. These names must be resolved to an address so they can be used. Sometimes the servers belong to the domain, they are serving, which causes a "chicken-and-egg" problem; we can't resolve the address until the nameserver is reachable, but we can't reach the nameserver until we resolve its address. To solve this dilemma, we can configure special A records directly into the nameserver of the parent zone. The A records allow the nameservers of the parent domain to resolve the IP address of the delegated zone nameservers. These records are commonly called glue records because they provide the "glue" that binds a delegated zone to its parent. Refer to the "DNS Database" section earlier for an explanation of how this works.
CNAME
This record associates an alias with a 's canonical name. It provides an alternate name by which users can refer to the whose canonical name is supplied as a parameter. The canonical name is the one the master file provides an A record for; aliases are simply linked to that name by a CNAME record, but don't have any other records of their own.
PTR
This type of record is used to associate names in the in-addr.arpa domain with names. It is used for reverse mapping of IP addresses to names. The name given must be the canonical name.
MX
This RR announces a mail exchanger for a domain. Mail exchangers are discussed in Chapter 11, Section 11.5. The syntax of an MX record is
[domain] [ttl] [class] MX preference
names the MX for domain. Every MX has an integer preference associated with it. A mail transport agent that wants to deliver mail to domain tries all s that have an MX record for this domain until it succeeds. The one with the lowest preference value is tried first, and then the others, in order of increasing preference value.
HINFO
This record provides information on the system's hardware and software. Its syntax is:
[domain] [ttl] [class] HINFO hardware software
The hardware field identifies the hardware used by this . Special conventions are used to specify this. If the field contains any blanks, it must be enclosed in double quotes. The software field names the operating system software used by the system. However, for security reasons, it's not a great idea to have this information publicly available, as it provides potentially valuable information to attackers. It's very uncommon to see it used lately, but some administrators like to use it to provide spurious or humorous information about their s.
Example HINFO records to describe machines look something like:
tao 36500 IN HINFO SEGA-DREAMCAST LINUX2.6 cevad 36500 IN HINFO ATARI-104ST LINUX2.0 jedd 36500 IN HINFO TIMEX-SINCLAIR LINUX2.6
There is a special type of named configuration that we'll talk about before we explain how to build a full nameserver configuration. It is called a caching-only configuration. It doesn't really serve a domain, but acts as a relay for all DNS queries produced on your . The advantage of this scheme is that it builds up a cache so that only the first query for a particular is actually sent to the nameservers on the Internet. Any repeated request will be answered directly from the cache in your local nameserver. It's also important to note here that a cache server should not be run from the same IP address as the DNS server.
A named.conf file for a caching-only server looks like this:
// Define networks to allow queries from.
acl allowednets { 192.168.99.0/24; 192.168.44.0/24; };
options {
directory "/etc/bind"; // Working directory
allow-query { allowednets; };
};
// Root server hints
zone "." { type hint;
file "root.hint"; };
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
file "local.rev";
notify no;
};In addition to this named.conf file, you must set up the root.hint file with a valid list of root nameservers. You could copy and use Example 6.10 for this purpose, or, better yet, you could use a BIND tool called dig to get the most current version of this file. No other files are needed for a caching-only server configuration. We'll discuss dig in more detail later in this chapter, but for now, to obtain the information to create the root.hint file, you can use the following command:
vbrew# dig at e.root-servers.net . ns
Examples Example 5-6, Example 5-7, Example 5-8, and Example 5-9 give sample configuration and zone files for a nameserver at the brewery, located on vlager. Due to the nature of the network discussed (a single LAN), the example is pretty straightforward.
The root.hint cache file shown in Example 5-6 shows sample hint records for a root nameserver. A typical cache file usually describes about a dozen nameservers. You can obtain the current list of nameservers for the root domain using the dig tool as described above.
; <<>> DiG 9.2.2 <<>> at e.root-servers.net . ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21972 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;at. IN A ;; AUTHORITY SECTION: ;; Query time: 54 msec ;; SERVER: 206.13.28.12#53(206.13.28.12) ;; WHEN: Sat Jan 31 11:28:44 2004 ;; MSG SIZE rcvd: 83 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8039 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;e.root-servers.net. IN A ;; ANSWER SECTION: e.root-servers.net. 566162 IN A 192.203.230.10 ;; AUTHORITY SECTION: ROOT-SERVERS.net. 134198 IN NS a.ROOT-SERVERS.net. ROOT-SERVERS.net. 134198 IN NS f.ROOT-SERVERS.net. ROOT-SERVERS.net. 134198 IN NS j.ROOT-SERVERS.net. ROOT-SERVERS.net. 134198 IN NS k.ROOT-SERVERS.net. ;; ADDITIONAL SECTION: a.ROOT-SERVERS.net. 566162 IN A 198.41.0.4 f.ROOT-SERVERS.net. 566162 IN A 192.5.5.241 j.ROOT-SERVERS.net. 566162 IN A 192.58.128.30 k.ROOT-SERVERS.net. 566162 IN A 193.0.14.129 ;; Query time: 12 msec ;; SERVER: 206.13.28.12#53(206.13.28.12) ;; WHEN: Sat Jan 31 11:28:44 2004 ;; MSG SIZE rcvd: 196 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61551 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 479762 IN NS F.ROOT-SERVERS.NET. . 479762 IN NS B.ROOT-SERVERS.NET. . 479762 IN NS J.ROOT-SERVERS.NET. . 479762 IN NS K.ROOT-SERVERS.NET. . 479762 IN NS L.ROOT-SERVERS.NET. . 479762 IN NS M.ROOT-SERVERS.NET. . 479762 IN NS I.ROOT-SERVERS.NET. . 479762 IN NS E.ROOT-SERVERS.NET. . 479762 IN NS D.ROOT-SERVERS.NET. . 479762 IN NS A.ROOT-SERVERS.NET. . 479762 IN NS H.ROOT-SERVERS.NET. . 479762 IN NS C.ROOT-SERVERS.NET. . 479762 IN NS G.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: F.ROOT-SERVERS.NET. 566162 IN A 192.5.5.241 B.ROOT-SERVERS.NET. 566162 IN A 192.228.79.201 J.ROOT-SERVERS.NET. 566162 IN A 192.58.128.30 K.ROOT-SERVERS.NET. 566162 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 566162 IN A 198.32.64.12 M.ROOT-SERVERS.NET. 566162 IN A 202.12.27.33 I.ROOT-SERVERS.NET. 566162 IN A 192.36.148.17 E.ROOT-SERVERS.NET. 566162 IN A 192.203.230.10 D.ROOT-SERVERS.NET. 566162 IN A 128.8.10.90 A.ROOT-SERVERS.NET. 566162 IN A 198.41.0.4 H.ROOT-SERVERS.NET. 566162 IN A 128.63.2.53 C.ROOT-SERVERS.NET. 566162 IN A 192.33.4.12 G.ROOT-SERVERS.NET. 566162 IN A 192.112.36.4 ;; Query time: 17 msec ;; SERVER: 206.13.28.12#53(206.13.28.12) ;; WHEN: Sat Jan 31 11:28:44 2004 ;; MSG SIZE rcvd: 436
; ; Hosts at the brewery ; /etc/bind/zone/vbrew.com ; Origin is vbrew.com ; $TTL 3D @ IN SOA vlager.vbrew.com. janet.vbrew.com. ( 200401206 ; serial, date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds IN NS vlager.vbrew.com. ; ; local mail is distributed on vlager IN MX 10 vlager ; ; loopback address local. IN A 127.0.0.1 ; ; Virtual Brewery Ethernet vlager IN A 172.16.1.1 vlager-if1 IN CNAME vlager ; vlager is also news server news IN CNAME vlager vstout IN A 172.16.1.2 vale IN A 172.16.1.3 ; ; Virtual Winery Ethernet vlager-if2 IN A 172.16.2.1 vbardolino IN A 172.16.2.2 vchianti IN A 172.16.2.3 vbeaujolais IN A 172.16.2.4 ; ; Virtual Spirits (subsidiary) Ethernet vbourbon IN A 172.16.3.1 vbourbon-if1 IN CNAME vbourbon
; ; /etc/bind/zone/127.0.0 Reverse mapping of 127.0.0 ; Origin is 0.0.127.in-addr.arpa. ; $TTL 3D @ IN SOA vlager.vbrew.com. joe.vbrew.com. ( 1 ; serial 360000 ; refresh: 100 hrs 3600 ; retry: one hour 3600000 ; expire: 42 days 360000 ; minimum: 100 hrs ) IN NS vlager.vbrew.com. 1 IN PTR local.
; ; /etc/bind/zones/16.172.in-addr.arpa ; Origin is 16.172.in-addr.arpa. ; $TTL 3D @ IN SOA vlager.vbrew.com. joe.vbrew.com. ( 16 ; serial 86400 ; refresh: once per day 3600 ; retry: one hour 3600000 ; expire: 42 days 604800 ; minimum: 1 week ) IN NS vlager.vbrew.com. ; brewery 1.1 IN PTR vlager.vbrew.com. 2.1 IN PTR vstout.vbrew.com. 3.1 IN PTR vale.vbrew.com. ; winery 1.2 IN PTR vlager-if2.vbrew.com. 2.2 IN PTR vbardolino.vbrew.com. 3.2 IN PTR vchianti.vbrew.com. 4.2 IN PTR vbeaujolais.vbrew.com.
dig is the current nameserver query tool of choice, replacing the commonly known nslookup. It is flexible, fast, and can be used to query almost anything from a DNS server. The syntax for dig is very straightforward.
vbrew# dig nameserver name typeThe command-line parameters are defined as follows:
nameserver
This is the name of the server that you are querying. It can be entered as a name or as an IP address. If you leave this blank, dig will use the DNS server listed in the resolv.conf file.
name
This is the name of the DNS record that you want to look up.
type
This is the type of query you want to execute. Common types are ANY, MX, and TXT. If left blank, dig will default to looking for an A record.
So, using this, if we wanted to see which servers handle mail for the Virtual Brewery, we would create the following dig query:
vbrew# dig vlager.vbrew.com MX
; <<>> DiG 9.2.2 <<>> vlager.vbrew.com MX
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40590
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;vlager.vbrew.com. IN MX
;; AUTHORITY SECTION:
vbrew.com. 10794 IN SOA vlager.vbrew.com. vlager.vbrew.com. 2003080803
10800 3600 604800 86400
;; Query time: 14 msec
;; SERVER: 192.168.28.12#53(192.168.28.12)
;; WHEN: Sun Feb 1 12:19:06 2004
;; MSG SIZE rcvd: 104Another example of an interesting query type which can be useful is the BIND version query. This is easily done with dig with the following syntax:
vlager# dig @vlager.vbrew.com version.bind. CHAOS TXT
.
.
; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
VERSION.BIND. 0 CH TXT "BIND 8.2.2-P5"
.
.nslookup , while now deprecated, is still a good tool for checking the operation of your nameserver setup. It can be used both interactively with prompts and as a single command with immediate output. In the latter case, you simply invoke it as:
$ nslookup namenslookup queries the nameserver specified in resolv.conf for name. (If this file names more than one server, nslookup chooses one at random.)
The interactive mode, however, is much more exciting. Besides looking up individual s, you may query for any type of DNS record and transfer the entire zone information for a domain.
When invoked without an argument, nslookup displays the nameserver it uses and enters interactive mode. At the prompt, you may type any domain name that you want to query. By default, it asks for class A recordsthose containing the IP address relating to the domain name.
You can look for record types by issuing:
> set type= type
in which type is one of the RRs names described earlier, or ANY.
For instance, you might have the following nslookup session:
$ nslookup Default Server: tao.linux.org.au Address: 203.41.101.121 > metalab.unc.edu Server: tao.linux.org.au Address: 203.41.101.121 Name: metalab.unc.edu Address: 152.2.254.81 >
The output first displays the DNS server being queried, and then the result of the query.
If you try to query for a name that has no IP address associated with it, but other records were found in the DNS database, nslookup returns with an error message saying "No type A records found." However, you can make it query for records other than type A by issuing the set type command. To get the SOA record of unc.edu, you would issue:
> unc.edu Server: tao.linux.org.au Address: 203.41.101.121 *** No address (A) records available for unc.edu > set type=SOA > unc.edu Server: tao.linux.org.au Address: 203.41.101.121 unc.edu origin = ns.unc.edu mail addr = -reg.ns.unc.edu serial = 1998111011 refresh = 14400 (4H) retry = 3600 (1H) expire = 1209600 (2W) minimum ttl = 86400 (1D) unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net unc.edu name server = ns.unc.edu ns2.unc.edu internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1 ns.unc.edu internet address = 152.2.21.1
In a similar fashion, you can query for MX records:
> set type=MX > unc.edu Server: tao.linux.org.au Address: 203.41.101.121 unc.edu preference = 0, mail exchanger = conga.oit.unc.edu unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu unc.edu name server = ns.unc.edu unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net conga.oit.unc.edu internet address = 152.2.22.21 imsety.oit.unc.edu internet address = 152.2.21.99 ns.unc.edu internet address = 152.2.21.1 ns2.unc.edu internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1
Using a type of ANY returns all resource records associated with a given name.
A practical application of nslookup, besides debugging, is to obtain the current list of root nameservers. You can obtain this list by querying for all NS records associated with the root domain:
> set type=NS
> .
Server: tao.linux.org.au
Address: 203.41.101.121
Non-authoritative answer:
(root) name server = A.ROOT-SERVERS.NET
(root) name server = H.ROOT-SERVERS.NET
(root) name server = B.ROOT-SERVERS.NET
(root) name server = C.ROOT-SERVERS.NET
(root) name server = D.ROOT-SERVERS.NET
(root) name server = E.ROOT-SERVERS.NET
(root) name server = I.ROOT-SERVERS.NET
(root) name server = F.ROOT-SERVERS.NET
(root) name server = G.ROOT-SERVERS.NET
(root) name server = J.ROOT-SERVERS.NET
(root) name server = K.ROOT-SERVERS.NET
(root) name server = L.ROOT-SERVERS.NET
(root) name server = M.ROOT-SERVERS.NET
Authoritative answers can be found from:
A.ROOT-SERVERS.NET internet address = 198.41.0.4
H.ROOT-SERVERS.NET internet address = 128.63.2.53
B.ROOT-SERVERS.NET internet address = 128.9.0.107
C.ROOT-SERVERS.NET internet address = 192.33.4.12
D.ROOT-SERVERS.NET internet address = 128.8.10.90
E.ROOT-SERVERS.NET internet address = 192.203.230.10
I.ROOT-SERVERS.NET internet address = 192.36.148.17
F.ROOT-SERVERS.NET internet address = 192.5.5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
J.ROOT-SERVERS.NET internet address = 198.41.0.10
K.ROOT-SERVERS.NET internet address = 193.0.14.129
L.ROOT-SERVERS.NET internet address = 198.32.64.12
M.ROOT-SERVERS.NET internet address = 202.12.27.33To see the complete set of available commands, use the help command in nslookup.
There are a few other tools that can help you with your tasks as a BIND administrator. We will briefly describe two of them here. Please refer to the documentation that comes with these tools for more information on how to use them.
cvt helps you with your initial BIND configuration by converting your /etc/s file into master files for named. It generates both the forward (A) and reverse mapping (PTR) entries, and takes care of aliases. Of course, it won't do the whole job for you, as you may still want to tune the timeout values in the SOA record, for example, or add MX records. Still, it may save you a few aspirins. cvt is part of the BIND source, but can also be found as a standalone package.
After setting up your nameserver, you may want to test your configuration. Some good tools that make this job much simpler; the first is called dnswalk, which is a Perl-based package. The second is called nslint. They both examine your DNS database for common mistakes and verify that the information is consistent. Two other useful tools are , which is a general purpose DNS database query tool. You can use this tool to manually inspect and diagnose DNS database entries.
This tool is likely to be available in prepackaged form. dnswalk and nslint are available in source from http://www.visi.com/~barr/dnswalk/ and