domain−name •
To specify a domain type: inhshesoidchaos, in − internet •
type •
To specify a zone authority: masterslavestubhint, master − primary, slave − secondary, hint − root zone .
•
file pathname •
To specify the name of the database file •
masters ip−addr; ip−addr; …
• To specify the primary server servers for the zone
•
check−names warnfailignore
• To control the way the check of valid host names is provided
•
allow−update address−match−list
• To prevent unauthorized zone update
•
allow−transfer address−match−list
• To prevent unauthorized zone transfer
•
max−transfer−time−in number
• To limit the duration of a zone transfer
•
notify yesno •
To control the automatic notification of secondary name servers upon DNS database changes
•
also−notify ip−addr; ip−addr;…
• To control the automatic notification of specified name servers
upon DNS database changes •
Some of the listed BIND 8.X.X features also existed in the BIND 4.X.X version; their configuration format is now changed. However, a majority of them are new and were introduced in the BIND
8.X.X version.
16.3.2.1 Subdomains and Parenting
Once a domain reaches a certain size, the need to distribute the management of parts of the domain to various organizational units can become a reality. This need could also exist for other,
nontechnical requirements, primarily for business−related reasons. In that case, the domain would be divided into a certain number of child subdomains, and this procedure is known as parenting.
Good parenting involves a sensible delegation of the new subdomains to create new zones. A corresponding relationship between the name servers for the parent and child zones is also
assumed. Simply put, each child zone must be advertised within the parent zone; otherwise, nobody will know there is a new child zone. The parent−child zone relationship is actually the core of DNS,
and we already pointed to this requirement for a successful name service; everything starts from the root name servers that are the top−parents within DNS space.
This process is slightly easier to administer if the same administration team handles both the parent and child zones. However, if different organizations are involved, a certain level of coordination
394
We already know that there are basically two different types of zones: one for a hostname−to−IP address lookup, and one for a reverse IP address−to−hostname lookup these are known as
in−addr.arpa zones. The administration of the two zone types is independent. As a matter of fact, DNS will even function for most applications even if the in−addr.arpa zone is not set properly many
applications do not check hostnames for reverse IP addresses.
Generally, it is easier to administer the first zone type; there are no serious restrictions in handling them:
There is no explicit limit in the number of participating hosts. •
The subdomain and host name rules are so flexible that it is easy to adapt to current parenting needs.
• Participating hosts can belong to different subnetworks IP subdomains.
• This is not the case with the second zone type, where:
A restricted number of hosts could belong to the zone. For example, the in−addr.arpa zone for each Class C IP address can have up to 254 hosts the address 0 identifies the network,
and 255 is the broadcast address. •
There is not a lot of freedom in in−addr.arpa naming; practically everything is predefined. •
The hosts within certain in−addr.arpa zones can be split among different domains that belong to different organizations, and are administered by different people. It is very
common today to assign only a portion of the available IP addresses within the network to a certain customer — this is basically how ISP organizations Internet service providers work.
•
While the same team usually administers the parenting and delegation of hostnames which always means an easier coordination of required activities, it is almost a rule that someone else manages
the parent in−addr.arpa zone today this is usually your ISP. The consequence is that in real life, the hostnames−to−IP address administration is usually done satisfactorily, while the in−addr.arpa
administration is trickier and can be more difficult. In the following text, we will focus on parenting from the standpoint of the in−addr.arpa administration and try to make this topic more clear through
corresponding examples.
Originally, each in−addr.arpa zone covered one Class IP address; this also meant that the size and subnetting possibilities varied among the Class A, B, and C IP zones. Obviously, larger
in−addr.arpa zones offer more possibilities for subnetting; they can be subnetted on an octet or non−octet boundary. Class C networks can be subnetted only on a non−octet boundary.
To subnet a Class B network on an octet boundary means to create Class C sized subnetworks, with a network mask 255.255.255.0, i.e., 24 network bits and 8 host bits. For example, the Class B
network 146.98.0.0 also identified as 146.9516; the network IP address is left of the slash character, and the number of network bits is to the right can be subnetted between the third and
fourth octet of the IP address. Newly created subnetworks can be assigned to a different organizational unit division, or department, or etc.. For example, one such subnetwork is
146.98.8.0 alternatively identified as 146.98.88 and could be delegated to another DNS administration team for maintenance.
Subnetting on an octet boundary is easier to administer, because the corresponding in−addr.arpa zone can be uniquely identified in a condensed way; in the previous example, the zone
8.98.146.in−addr.arpa uniquely identified all hosts within that subdomain. It is enough to advertise
395
8.98.146.in−addr.arpa 86400 IN NS ns1.ph.myschool.scps.edu. 8.98.146.in−addr.arpa 86400 IN NS ns2.ph.myschool.scps.edu.
This means that the authoritative answers for this zone can be obtained from the new name servers, and not from the name servers that handle the parent zone 98.146.in−addr.arpa. Of
course, the new name servers must be set as a primary and a secondary server for the new zone; this situation assumes the appropriate setup of the configuration file named.boot BIND 4.X.X, or
named.conf BIND 8.X.X and the corresponding database file.
Subnetting on a non−octal boundary requires more administrative work, simply because we cannot specify all subnetted hosts within a single standard in−addr.arpa entry; subnetted hosts are now
split among multiple in−addr.arpa zones and maintained by different name servers. The issue is how to extract certain hosts from the standard in−addr.arpa zone, put them into the new
nonstandard in−addr.arpa zone, and delegate the DNS administration to the new name servers.
Let us suppose a Class C network 193.95.110.0 alternately, 193.95.11024 is subnetted in such a way that IP addresses in the range of 193.95.110.16 to 193.95.110.47 form a separate zone. The
problem is that we cannot put these hosts in any widely known and understandable standard in−addr.arpa zone that will uniquely identify just those hosts, and then handle such a zone; the
smallest in−addr.arpa zone corresponds to the Class C network, and we need only a portion of that. How do we provide an appropriate name service that will reflect the naming and maintenance by
those who own and use the hosts in that address range?
Basically, there are three ways to solve this problem: The first way is to leave the DNS administration within the parent zone and coordinate the
subdomain DNS policy with the parent zone administration team; in practice this could be quite annoying, especially if frequent DNS changes are expected.
1. The second way is to delegate each in−addr.arpa name within this range in the parent zone
to the new name servers. This works, but sometimes it can be a very time−consuming job. It m e a n s , i n o u r e x a m p l e , t o s p e c i f y t h e f o l l o w i n g e n t r i e s i n t h e p a r e n t z o n e
110.95.193.in−addr.arpa:
16.110.95.193.in−addr.arpa. 86400 IN NS ns1.unixadm.com. 16.110.95.193.in−addr.arpa. 86400 IN NS ns2.unixadm.com.
17.110.95.193.in−addr.arpa. 86400 IN NS ns1.unixadm.com. 17.110.95.193.in−addr.arpa. 86400 IN NS ns2.unixadm.com.
And so on for other in−addr.arpa names in the specified range until the last one…
47.110.95.193.in−addr.arpa. 86400 IN NS ns1.unixadm.com. 47.110.95.193.in−addr.arpa. 86400 IN NS ns2.unixadm.com.
Besides that, the new name servers ns1.unixadm.com and ns2.unixadm.com must be set, and configured for each individual IP address listed in the parent zone.
2.
The third way is the recommended one. The only way to group specified in−addr.arpa names into a new nonstandard in−addr.arpa zone is to make them aliases to the new
in−addr.arpa names that belong to the new nonstandard in−addr.arpa zone. To accomplish this, the new in−addr.arpa names should be attached as canonical names to the existing
ones. Once this is done, we can treat the new nonstandard in−addr.arpa zone as any other 3.
396
I n o u r e x a m p l e , w e w i l l i n t r o d u c e t h e n e w n o n s t a n d a r d i n − a d d r . a r p a z o n e 16−47.110.95.193.in−addr.arpa and delegate to the new name servers ns1.unixadm.com. and
ns2.unixadm.com.:
16−47.110.95.193.in−addr.arpa. 86400 IN NS ns1.unixadm.com. 16−47.110.95.193.in−addr.arpa. 86400 IN NS ns2.unixadm.com.
Also, the new in−addr.arpa names that are parts of the newly introduced in−addr.arpa zone should be attached as canonical names:
16.110.95.193.in−addr.arpa. IN CNAME 16.16−47.110.95.193.in−addr.arpa. 17.110.95.193.in−addr.arpa. IN CNAME 17.16−47.110.95.193.in−addr.arpa.
18.110.95.193.in−addr.arpa. IN CNAME 18.16−47.110.95.193.in−addr.arpa. .....
..... 47.110.95.193.in−addr.arpa. IN CNAME 47.16−47.110.95.193.in−addr.arpa.
The new name servers ns1.unixadm.com and ns2.unixadm.com must also be set; however, their configuration is quite standard, and the newly introduced zone 16−47.110.95.193.in−addr.arpa is
treated as any other standard in−addr.arpa zone.
The selected name for the new in−addr.arpa zone is arbitrary; it is recommended that it be a logical one, but this is not a requirement. However, the same name must be used in the parent zone and
the new name servers.
16.4 Using nslookup
nslookup is a debugging tool provided as part of the BIND software package. It allows anyone to directly query name servers and retrieve any of the information known to the DNS. It is very helpful
for determining if the servers are running correctly. A brief review of nslookup follows.
nslookup is a program to query Internet domain name servers. If a name server is not configured, nslookup uses NIS if NIS is configured. Otherwise the local host table, etchosts, is used.
nslookup has two modes: interactive and noninteractive. Interactive mode allows the user to query a name server for information about various hosts and domains, or to print a list of hosts in the
domain. Noninteractive mode is used to query a name server for information about one host or domain.
The format of the nslookup command is:
nslookup [−option …] [−[server]]
Interactive mode is entered in the following cases: No arguments are given
• The first argument is a hyphen −. The optional second argument is a host name or Internet
address of a name server. •
Noninteractive mode is used when the name of the host to be looked up is given as the first 397
