Red Hat LINUX 7.2 - OFFICIAL LINUX CUSTOMIZATION GUIDE Guida di Installazione Scaricare il pdf (Pagina 221)

Chapter 17.

Berkeley Internet Name Domain (BIND)

Today, the Internet and almost all local networks depend upon a working and reliable Domain Name

Service (DNS), which is used to resolve names of systems into IP addresses and vice versa.

In order to facilitate DNS on your network, a nameserver is required to translate these names into the

IP addresses necessary to make the connection. In addition, a nameserver can translate IP addresses

back into a system’s name, commonly called a reverse lookup.

This chapter discusses BIND, the structure of its conﬁguration ﬁles, and how it may be locally or

remotely administered.

For BIND conﬁguration instructions using the GUI BIND Conﬁguration Tool, please see Ofﬁcial Red

Hat Linux Customization Guide. Note that, if you are using the BIND Conﬁguration Tool, you should

not manually edit your BIND conﬁguration ﬁles because any manual changes will be overwritten by

the BIND Conﬁguration Tool.

17.1. Introduction to DNS and BIND

Systems using IP networks must know the IP address of a remote machine in order to connect to it.

However, most users prefer to use names of machines, such as hostname or a fully qualiﬁed domain

name (FQDN), to specify a system when connecting to it. In addition, many programs utilize domain

names in their conﬁguration ﬁles when referring to a remote system, in order to allow IP addresses to

be changed without modifying the system’s name, among other reasons. The service that facilitates

this is caused DNS, and it is normally implemented using centralized servers that are authoritative for

some domains and refer to other DNS servers for information they do not already know.

DNS is made possible through the use of nameserver daemons that perform the IP/name translation.

A client application will request information from the nameserver, usually connecting to it on the

server’s port 53. The nameserver will attempt to resolve the FQDN based on its resolver library,

which may contain authoritative information about the host requested or cached data about that name

from an earlier query. If the nameserver does not already have the answer in its resolver library, it will

turn to other nameservers, called root nameservers, to determine which nameservers are authoritative

for the FQDN in question. Then, with that information, it will query the authoritative nameservers for

that name to determine the IP address. If performing a reverse lookup, the same procedure is used,

except the query is made with an unknown IP address rather than a name.

17.1.1. Zones

On the Internet, the FQDN of a host can be broken down into different sections, and these sections are

organized in a hierarchy much like a tree, with a main trunk, primary branches, secondary branches,

and so forth. Consider the following FQDN:

bill.sales.domain.com

Figure 17-1. Example of a fully qualiﬁed domain name

When looking at how a FQDN is resolved to ﬁnd the IP address that relates to a particular system,

you must read the name from right to left, with each level of the hierarchy divided by dots (.). In this

example, the com deﬁnes the top level domain for this FQDN. The domain name is a sub-domain

under com, with sales as a sub-domain under domain. The name furthest left in a FQDN is the

hostname, identifying a particular machine.

1 2 ... 216 217 218 219 220 221 222 223 224 225 226 ... 281 282

Nessun commento

Red Hat LINUX 7.2 - OFFICIAL LINUX CUSTOMIZATION GUIDE Guida di Installazione Pagina 221