--- wikisrc/guide/dns.mdwn 2013/03/09 00:15:25 1.1
+++ wikisrc/guide/dns.mdwn 2013/03/21 11:11:20 1.3
@@ -1,338 +1,342 @@
+**Contents**
+
+[[!toc levels=3]]
+
# The Domain Name System
-Use of the Domain Name System has been discussed in previous chapters, without
-going into detail on the setup of the server providing the service. This chapter
-describes setting up a simple, small domain with one Domain Name System (DNS)
-nameserver on a NetBSD system. It includes a brief explanation and overview of
-the DNS; further information can be obtained from the DNS Resources Directory
+Use of the Domain Name System has been discussed in previous chapters, without
+going into detail on the setup of the server providing the service. This chapter
+describes setting up a simple, small domain with one Domain Name System (DNS)
+nameserver on a NetBSD system. It includes a brief explanation and overview of
+the DNS; further information can be obtained from the DNS Resources Directory
(DNSRD) at [http://www.dns.net/dnsrd/](http://www.dns.net/dnsrd/).
## DNS Background and Concepts
-The DNS is a widely used *naming service* on the Internet and other TCP/IP
-networks. The network protocols, data and file formats, and other aspects of the
-DNS are Internet Standards, specified in a number of RFC documents, and
-described by a number of other reference and tutorial works. The DNS has a
-distributed, client-server architecture. There are reference implementations for
-the server and client, but these are not part of the standard. There are a
+The DNS is a widely used *naming service* on the Internet and other TCP/IP
+networks. The network protocols, data and file formats, and other aspects of the
+DNS are Internet Standards, specified in a number of RFC documents, and
+described by a number of other reference and tutorial works. The DNS has a
+distributed, client-server architecture. There are reference implementations for
+the server and client, but these are not part of the standard. There are a
number of additional implementations available for many platforms.
### Naming Services
-Naming services are used to provide a mapping between textual names and
-configuration data of some form. A *nameserver* maintains this mapping, and
+Naming services are used to provide a mapping between textual names and
+configuration data of some form. A *nameserver* maintains this mapping, and
clients request the nameserver to *resolve* a name into its attached data.
-The reader should have a good understanding of basic hosts to IP address mapping
+The reader should have a good understanding of basic hosts to IP address mapping
and IP address class specifications, see
[[Name Service Concepts|guide/net-intro#nsconcepts]].
-In the case of the DNS, the configuration data bound to a name is in the form of
-standard *Resource Records* (RRs). These textual names conform to certain
+In the case of the DNS, the configuration data bound to a name is in the form of
+standard *Resource Records* (RRs). These textual names conform to certain
structural conventions.
### The DNS namespace
-The DNS presents a hierarchical name space, much like a UNIX filesystem,
+The DNS presents a hierarchical name space, much like a UNIX filesystem,
pictured as an inverted tree with the *root* at the top.
- TOP-LEVEL .org
- |
- MID-LEVEL .diverge.org
- ______________________|________________________
- | | |
+ TOP-LEVEL .org
+ |
+ MID-LEVEL .diverge.org
+ ______________________|________________________
+ | | |
BOTTOM-LEVEL strider.diverge.org samwise.diverge.org wormtongue.diverge.org
-The system can also be logically divided even further if one wishes at different
-points. The example shown above shows three nodes on the diverge.org domain, but
-we could even divide diverge.org into subdomains such as
-"strider.net1.diverge.org", "samwise.net2.diverge.org" and
-"wormtongue.net2.diverge.org"; in this case, 2 nodes reside in
+The system can also be logically divided even further if one wishes at different
+points. The example shown above shows three nodes on the diverge.org domain, but
+we could even divide diverge.org into subdomains such as
+"strider.net1.diverge.org", "samwise.net2.diverge.org" and
+"wormtongue.net2.diverge.org"; in this case, 2 nodes reside in
"net2.diverge.org" and one in "net1.diverge.org".
-There are directories of names, some of which may be sub-directories of further
-names. These directories are sometimes called *zones*. There is provision for
-symbolic links, redirecting requests for information on one name to the records
-bound to another name. Each name recognised by the DNS is called a *Domain
-Name*, whether it represents information about a specific host, or a directory
+There are directories of names, some of which may be sub-directories of further
+names. These directories are sometimes called *zones*. There is provision for
+symbolic links, redirecting requests for information on one name to the records
+bound to another name. Each name recognised by the DNS is called a *Domain
+Name*, whether it represents information about a specific host, or a directory
of subordinate Domain Names (or both, or something else).
-Unlike most filesystem naming schemes, however, Domain Names are written with
-the innermost name on the left, and progressively higher-level domains to the
-right, all the way up to the root directory if necessary. The separator used
+Unlike most filesystem naming schemes, however, Domain Names are written with
+the innermost name on the left, and progressively higher-level domains to the
+right, all the way up to the root directory if necessary. The separator used
when writing Domain Names is a period, ".".
-Like filesystem pathnames, Domain Names can be written in an absolute or
-relative manner, though there are some differences in detail. For instance,
-there is no way to indirectly refer to the parent domain like with the UNIX `..`
-directory. Many (but not all) resolvers offer a search path facility, so that
-partially-specified names can be resolved relative to additional listed
-sub-domains other than the client's own domain. Names that are completely
-specified all the way to the root are called *Fully Qualified Domain Names* or
-*FQDN*s. A defining characteristic of an FQDN is that it is written with a
-terminating period. The same name, without the terminating period, may be
-considered relative to some other sub-domain. It is rare for this to occur
-without malicious intent, but in part because of this possibility, FQDNs are
+Like filesystem pathnames, Domain Names can be written in an absolute or
+relative manner, though there are some differences in detail. For instance,
+there is no way to indirectly refer to the parent domain like with the UNIX `..`
+directory. Many (but not all) resolvers offer a search path facility, so that
+partially-specified names can be resolved relative to additional listed
+sub-domains other than the client's own domain. Names that are completely
+specified all the way to the root are called *Fully Qualified Domain Names* or
+*FQDN*s. A defining characteristic of an FQDN is that it is written with a
+terminating period. The same name, without the terminating period, may be
+considered relative to some other sub-domain. It is rare for this to occur
+without malicious intent, but in part because of this possibility, FQDNs are
required as configuration parameters in some circumstances.
-On the Internet, there are some established conventions for the names of the
-first few levels of the tree, at which point the hierarchy reaches the level of
-an individual organisation. This organisation is responsible for establishing
+On the Internet, there are some established conventions for the names of the
+first few levels of the tree, at which point the hierarchy reaches the level of
+an individual organisation. This organisation is responsible for establishing
and maintaining conventions further down the tree, within its own domain.
### Resource Records
-Resource Records for a domain are stored in a standardised format in an ASCII
-text file, often called a *zone file*. The following Resource Records are
-commonly used (a number of others are defined but not often used, or no longer
-used). In some cases, there may be multiple RR types associated with a name, and
+Resource Records for a domain are stored in a standardised format in an ASCII
+text file, often called a *zone file*. The following Resource Records are
+commonly used (a number of others are defined but not often used, or no longer
+used). In some cases, there may be multiple RR types associated with a name, and
even multiple records of the same type.
#### Common DNS Resource Records
- * *A: Address* -- This record contains the numerical IP address associated with
+ * *A: Address* -- This record contains the numerical IP address associated with
the name.
- * *CNAME: Canonical Name* -- This record contains the Canonical Name (an FQDN
- with an associated A record) of the host name to which this record is bound.
- This record type is used to provide name aliasing, by providing a link to
- another name with which other appropriate RR's are associated. If a name has
- a CNAME record bound to it, it is an alias, and no other RR's are permitted
+ * *CNAME: Canonical Name* -- This record contains the Canonical Name (an FQDN
+ with an associated A record) of the host name to which this record is bound.
+ This record type is used to provide name aliasing, by providing a link to
+ another name with which other appropriate RR's are associated. If a name has
+ a CNAME record bound to it, it is an alias, and no other RR's are permitted
to be bound to the same name.
- It is common for these records to be used to point to hosts providing a
- particular service, such as an FTP or HTTP server. If the service must be
- moved to another host, the alias can be changed, and the same name will reach
+ It is common for these records to be used to point to hosts providing a
+ particular service, such as an FTP or HTTP server. If the service must be
+ moved to another host, the alias can be changed, and the same name will reach
the new host.
- * *PTR: Pointer* -- This record contains a textual name. These records are
- bound to names built in a special way from numerical IP addresses, and are
- used to provide a reverse mapping from an IP address to a textual name. This
+ * *PTR: Pointer* -- This record contains a textual name. These records are
+ bound to names built in a special way from numerical IP addresses, and are
+ used to provide a reverse mapping from an IP address to a textual name. This
is described in more detail in [[Reverse Resolution|guide/dns#bg-reverse]].
- * *NS: Name Server* -- This record type is used to *delegate* a sub-tree of the
- Domain Name space to another nameserver. The record contains the FQDN of a
- DNS nameserver with information on the sub-domain, and is bound to the name
- of the sub-domain. In this manner, the hierarchical structure of the DNS is
- established. Delegation is described in more detail in
+ * *NS: Name Server* -- This record type is used to *delegate* a sub-tree of the
+ Domain Name space to another nameserver. The record contains the FQDN of a
+ DNS nameserver with information on the sub-domain, and is bound to the name
+ of the sub-domain. In this manner, the hierarchical structure of the DNS is
+ established. Delegation is described in more detail in
[[Delegation|guide/dns#bg-delegation]].
- * *MX: Mail eXchange* -- This record contains the FQDN for a host that will
- accept SMTP electronic mail for the named domain, together with a priority
- value used to select an MX host when relaying mail. It is used to indicate
- other servers that are willing to receive and spool mail for the domain if
- the primary MX is unreachable for a time. It is also used to direct email to
- a central server, if desired, rather than to each and every individual
+ * *MX: Mail eXchange* -- This record contains the FQDN for a host that will
+ accept SMTP electronic mail for the named domain, together with a priority
+ value used to select an MX host when relaying mail. It is used to indicate
+ other servers that are willing to receive and spool mail for the domain if
+ the primary MX is unreachable for a time. It is also used to direct email to
+ a central server, if desired, rather than to each and every individual
workstation.
- * *HINFO: Host Information* -- Contains two strings, intended for use to
- describe the host hardware and operating system platform. There are defined
- strings to use for some systems, but their use is not enforced. Some sites,
+ * *HINFO: Host Information* -- Contains two strings, intended for use to
+ describe the host hardware and operating system platform. There are defined
+ strings to use for some systems, but their use is not enforced. Some sites,
because of security considerations, do not publicise this information.
- * *TXT: Text* -- A free-form text field, sometimes used as a comment field,
- sometimes overlaid with site-specific additional meaning to be interpreted by
+ * *TXT: Text* -- A free-form text field, sometimes used as a comment field,
+ sometimes overlaid with site-specific additional meaning to be interpreted by
local conventions.
- * *SOA: Start of Authority* -- This record is required to appear for each zone
- file. It lists the primary nameserver and the email address of the person
- responsible for the domain, together with default values for a number of
- fields associated with maintaining consistency across multiple servers and
+ * *SOA: Start of Authority* -- This record is required to appear for each zone
+ file. It lists the primary nameserver and the email address of the person
+ responsible for the domain, together with default values for a number of
+ fields associated with maintaining consistency across multiple servers and
caching of the results of DNS queries.
### Delegation
-Using NS records, authority for portions of the DNS namespace below a certain
-point in the tree can be delegated, and further sub-parts below that delegated
-again. It is at this point that the distinction between a domain and a zone
-becomes important. Any name in the DNS is called a domain, and the term applies
-to that name and to any subordinate names below that one in the tree. The
-boundaries of a zone are narrower, and are defined by delegations. A zone starts
-with a delegation (or at the root), and encompasses all names in the domain
+Using NS records, authority for portions of the DNS namespace below a certain
+point in the tree can be delegated, and further sub-parts below that delegated
+again. It is at this point that the distinction between a domain and a zone
+becomes important. Any name in the DNS is called a domain, and the term applies
+to that name and to any subordinate names below that one in the tree. The
+boundaries of a zone are narrower, and are defined by delegations. A zone starts
+with a delegation (or at the root), and encompasses all names in the domain
below that point, excluding names below any subsequent delegations.
-This distinction is important for implementation - a zone is a single
-administrative entity (with a single SOA record), and all data for the zone is
-referred to by a single file, called a *zone file*. A zone file may contain more
-than one period-separated level of the namespace tree, if desired, by including
-periods in the names in that zone file. In order to simplify administration and
-prevent overly-large zone files, it is quite legal for a DNS server to delegate
+This distinction is important for implementation - a zone is a single
+administrative entity (with a single SOA record), and all data for the zone is
+referred to by a single file, called a *zone file*. A zone file may contain more
+than one period-separated level of the namespace tree, if desired, by including
+periods in the names in that zone file. In order to simplify administration and
+prevent overly-large zone files, it is quite legal for a DNS server to delegate
to itself, splitting the domain into several zones kept on the same server.
### Delegation to multiple servers
-For redundancy, it is common (and often administratively required) that there be
-more than one nameserver providing information on a zone. It is also common that
-at least one of these servers be located at some distance (in terms of network
-topology) from the others, so that knowledge of that zone does not become
-unavailable in case of connectivity failure. Each nameserver will be listed in
-an NS record bound to the name of the zone, stored in the parent zone on the
-server responsible for the parent domain. In this way, those searching the name
-hierarchy from the top down can contact any one of the servers to continue
+For redundancy, it is common (and often administratively required) that there be
+more than one nameserver providing information on a zone. It is also common that
+at least one of these servers be located at some distance (in terms of network
+topology) from the others, so that knowledge of that zone does not become
+unavailable in case of connectivity failure. Each nameserver will be listed in
+an NS record bound to the name of the zone, stored in the parent zone on the
+server responsible for the parent domain. In this way, those searching the name
+hierarchy from the top down can contact any one of the servers to continue
narrowing their search. This is occasionally called *walking the tree*.
-There are a number of nameservers on the Internet which are called *root
-nameservers*. These servers provide information on the very top levels of the
-domain namespace tree. These servers are special in that their addresses must be
-pre-configured into nameservers as a place to start finding other servers.
-Isolated networks that cannot access these servers may need to provide their own
+There are a number of nameservers on the Internet which are called *root
+nameservers*. These servers provide information on the very top levels of the
+domain namespace tree. These servers are special in that their addresses must be
+pre-configured into nameservers as a place to start finding other servers.
+Isolated networks that cannot access these servers may need to provide their own
root nameservers.
### Secondaries, Caching, and the SOA record
-In order to maintain consistency between these servers, one is usually
-configured as the *primary* server, and all administrative changes are made on
-this server. The other servers are configured as *secondaries*, and transfer the
-contents of the zone from the primary. This operational model is not required,
-and if external considerations require it, multiple primaries can be used
-instead, but consistency must then be maintained by other means. DNS servers
-that store Resource Records for a zone, whether they be primary or secondary
-servers, are said to be *authoritative* for the zone. A DNS server can be
+In order to maintain consistency between these servers, one is usually
+configured as the *primary* server, and all administrative changes are made on
+this server. The other servers are configured as *secondaries*, and transfer the
+contents of the zone from the primary. This operational model is not required,
+and if external considerations require it, multiple primaries can be used
+instead, but consistency must then be maintained by other means. DNS servers
+that store Resource Records for a zone, whether they be primary or secondary
+servers, are said to be *authoritative* for the zone. A DNS server can be
authoritative for several zones.
-When nameservers receive responses to queries, they can *cache* the results.
-This has a significant beneficial impact on the speed of queries, the query load
-on high-level nameservers, and network utilisation. It is also a major
+When nameservers receive responses to queries, they can *cache* the results.
+This has a significant beneficial impact on the speed of queries, the query load
+on high-level nameservers, and network utilisation. It is also a major
contributor to the memory usage of the nameserver process.
-There are a number of parameters that are important to maintaining consistency
-amongst the secondaries and caches. The values for these parameters for a
+There are a number of parameters that are important to maintaining consistency
+amongst the secondaries and caches. The values for these parameters for a
particular domain zone file are stored in the SOA record. These fields are:
#### Fields of the SOA Record
- * *Serial* -- A serial number for the zone file. This should be incremented any
- time the data in the domain is changed. When a secondary wants to check if
- its data is up-to-date, it checks the serial number on the primary's SOA
+ * *Serial* -- A serial number for the zone file. This should be incremented any
+ time the data in the domain is changed. When a secondary wants to check if
+ its data is up-to-date, it checks the serial number on the primary's SOA
record.
- * *Refresh* -- A time, in seconds, specifying how often the secondary should
- check the serial number on the primary, and start a new transfer if the
+ * *Refresh* -- A time, in seconds, specifying how often the secondary should
+ check the serial number on the primary, and start a new transfer if the
primary has newer data.
- * *Retry* -- If a secondary fails to connect to the primary when the refresh
- time has elapsed (for example, if the host is down), this value specifies, in
+ * *Retry* -- If a secondary fails to connect to the primary when the refresh
+ time has elapsed (for example, if the host is down), this value specifies, in
seconds, how often the connection should be retried.
- * *Expire* -- If the retries fail to reach the primary within this number of
- seconds, the secondary destroys its copies of the zone data file(s), and
- stops answering requests for the domain. This stops very old and potentially
+ * *Expire* -- If the retries fail to reach the primary within this number of
+ seconds, the secondary destroys its copies of the zone data file(s), and
+ stops answering requests for the domain. This stops very old and potentially
inaccurate data from remaining in circulation.
- * *TTL* -- This field specifies a time, in seconds, that the resource records
- in this zone should remain valid in the caches of other nameservers. If the
- data is volatile, this value should be short. TTL is a commonly-used acronym,
+ * *TTL* -- This field specifies a time, in seconds, that the resource records
+ in this zone should remain valid in the caches of other nameservers. If the
+ data is volatile, this value should be short. TTL is a commonly-used acronym,
that stands for "Time To Live".
### Name Resolution
-DNS clients are configured with the addresses of DNS servers. Usually, these are
-servers which are authoritative for the domain of which they are a member. All
-requests for name resolution start with a request to one of these local servers.
+DNS clients are configured with the addresses of DNS servers. Usually, these are
+servers which are authoritative for the domain of which they are a member. All
+requests for name resolution start with a request to one of these local servers.
DNS queries can be of two forms:
- * A *recursive* query asks the nameserver to resolve a name completely, and
- return the result. If the request cannot be satisfied directly, the
- nameserver looks in its configuration and caches for a server higher up the
- domain tree which may have more information. In the worst case, this will be
- a list of pre-configured servers for the root domain. These addresses are
- returned in a response called a *referral*. The local nameserver must then
+ * A *recursive* query asks the nameserver to resolve a name completely, and
+ return the result. If the request cannot be satisfied directly, the
+ nameserver looks in its configuration and caches for a server higher up the
+ domain tree which may have more information. In the worst case, this will be
+ a list of pre-configured servers for the root domain. These addresses are
+ returned in a response called a *referral*. The local nameserver must then
send its request to one of these servers.
- * Normally, this will be an *iterative* query, which asks the second nameserver
- to either respond with an authoritative reply, or with the addresses of
- nameservers (NS records) listed in its tables or caches as authoritative for
- the relevant zone. The local nameserver then makes iterative queries, walking
- the tree downwards until an authoritative answer is found (either positive or
+ * Normally, this will be an *iterative* query, which asks the second nameserver
+ to either respond with an authoritative reply, or with the addresses of
+ nameservers (NS records) listed in its tables or caches as authoritative for
+ the relevant zone. The local nameserver then makes iterative queries, walking
+ the tree downwards until an authoritative answer is found (either positive or
negative) and returned to the client.
-In some configurations, such as when firewalls prevent direct IP communications
-between DNS clients and external nameservers, or when a site is connected to the
-rest of the world via a slow link, a nameserver can be configured with
-information about a *forwarder*. This is an external nameserver to which the
-local nameserver should make requests as a client would, asking the external
-nameserver to perform the full recursive name lookup, and return the result in a
+In some configurations, such as when firewalls prevent direct IP communications
+between DNS clients and external nameservers, or when a site is connected to the
+rest of the world via a slow link, a nameserver can be configured with
+information about a *forwarder*. This is an external nameserver to which the
+local nameserver should make requests as a client would, asking the external
+nameserver to perform the full recursive name lookup, and return the result in a
single query (which can then be cached), rather than reply with referrals.
### Reverse Resolution
-The DNS provides resolution from a textual name to a resource record, such as an
-A record with an IP address. It does not provide a means, other than exhaustive
-search, to match in the opposite direction; there is no mechanism to ask which
+The DNS provides resolution from a textual name to a resource record, such as an
+A record with an IP address. It does not provide a means, other than exhaustive
+search, to match in the opposite direction; there is no mechanism to ask which
name is bound to a particular RR.
-For many RR types, this is of no real consequence, however it is often useful to
-identify by name the host which owns a particular IP address. Rather than
-complicate the design and implementation of the DNS database engine by providing
-matching functions in both directions, the DNS utilises the existing mechanisms
-and creates a special namespace, populated with PTR records, for IP address to
-name resolution. Resolving in this manner is often called *reverse resolution*,
+For many RR types, this is of no real consequence, however it is often useful to
+identify by name the host which owns a particular IP address. Rather than
+complicate the design and implementation of the DNS database engine by providing
+matching functions in both directions, the DNS utilises the existing mechanisms
+and creates a special namespace, populated with PTR records, for IP address to
+name resolution. Resolving in this manner is often called *reverse resolution*,
despite the inaccurate implications of the term.
The manner in which this is achieved is as follows:
- * A normal domain name is reserved and defined to be for the purpose of mapping
- IP addresses. The domain name used is `in-addr.arpa.` which shows the
- historical origins of the Internet in the US Government's Defence Advanced
+ * A normal domain name is reserved and defined to be for the purpose of mapping
+ IP addresses. The domain name used is `in-addr.arpa.` which shows the
+ historical origins of the Internet in the US Government's Defence Advanced
Research Projects Agency's funding program.
- * This domain is then subdivided and delegated according to the structure of IP
- addresses. IP addresses are often written in *decimal dotted quad notation*,
- where each octet of the 4-octet long address is written in decimal, separated
- by dots. IP address ranges are usually delegated with more and more of the
- left-most parts of the address in common as the delegation gets smaller.
- Thus, to allow delegation of the reverse lookup domain to be done easily,
- this is turned around when used with the hierarchical DNS namespace, which
+ * This domain is then subdivided and delegated according to the structure of IP
+ addresses. IP addresses are often written in *decimal dotted quad notation*,
+ where each octet of the 4-octet long address is written in decimal, separated
+ by dots. IP address ranges are usually delegated with more and more of the
+ left-most parts of the address in common as the delegation gets smaller.
+ Thus, to allow delegation of the reverse lookup domain to be done easily,
+ this is turned around when used with the hierarchical DNS namespace, which
places higher level domains on the right of the name.
- * Each byte of the IP address is written, as an ASCII text representation of
- the number expressed in decimal, with the octets in reverse order, separated
- by dots and appended with the in-addr.arpa. domain name. For example, to
- determine the hostname of a network device with IP address 11.22.33.44, this
- algorithm would produce the string `44.33.22.11.in-addr.arpa.` which is a
- legal, structured Domain Name. A normal nameservice query would then be sent
+ * Each byte of the IP address is written, as an ASCII text representation of
+ the number expressed in decimal, with the octets in reverse order, separated
+ by dots and appended with the in-addr.arpa. domain name. For example, to
+ determine the hostname of a network device with IP address 11.22.33.44, this
+ algorithm would produce the string `44.33.22.11.in-addr.arpa.` which is a
+ legal, structured Domain Name. A normal nameservice query would then be sent
to the nameserver asking for a PTR record bound to the generated name.
-
+
* The PTR record, if found, will contain the FQDN of a host.
-One consequence of this is that it is possible for mismatch to occur. Resolving
-a name into an A record, and then resolving the name built from the address in
-that A record to a PTR record, may not result in a PTR record which contains the
-original name. There is no restriction within the DNS that the "reverse" mapping
-must coincide with the "forward" mapping. This is a useful feature in some
-circumstances, particularly when it is required that more than one name has an A
+One consequence of this is that it is possible for mismatch to occur. Resolving
+a name into an A record, and then resolving the name built from the address in
+that A record to a PTR record, may not result in a PTR record which contains the
+original name. There is no restriction within the DNS that the "reverse" mapping
+must coincide with the "forward" mapping. This is a useful feature in some
+circumstances, particularly when it is required that more than one name has an A
record bound to it which contains the same IP address.
-While there is no such restriction within the DNS, some application server
-programs or network libraries will reject connections from hosts that do not
+While there is no such restriction within the DNS, some application server
+programs or network libraries will reject connections from hosts that do not
satisfy the following test:
- * the state information included with an incoming connection includes the IP
+ * the state information included with an incoming connection includes the IP
address of the source of the request.
* a PTR lookup is done to obtain an FQDN of the host making the connection
- * an A lookup is then done on the returned name, and the connection rejected if
+ * an A lookup is then done on the returned name, and the connection rejected if
the source IP address is not listed amongst the A records that get returned.
-This is done as a security precaution, to help detect and prevent malicious
-sites impersonating other sites by configuring their own PTR records to return
+This is done as a security precaution, to help detect and prevent malicious
+sites impersonating other sites by configuring their own PTR records to return
the names of hosts belonging to another organisation.
## The DNS Files
-Now let's look at actually setting up a small DNS enabled network. We will
-continue to use the examples mentioned in [Chapter 24, *Setting up TCP/IP on
-NetBSD in practice*](chap-net-practice.html "Chapter 24. Setting up TCP/IP on
+Now let's look at actually setting up a small DNS enabled network. We will
+continue to use the examples mentioned in [Chapter 24, *Setting up TCP/IP on
+NetBSD in practice*](chap-net-practice.html "Chapter 24. Setting up TCP/IP on
NetBSD in practice"), i.e. we assume that:
* Our IP networking is working correctly
* We have IPNAT working correctly
* Currently all hosts use the ISP for DNS
-Our Name Server will be the `strider` host which also runs IPNAT, and our two
-clients use "strider" as a gateway. It is not really relevant as to what type of
-interface is on "strider", but for argument's sake we will say a 56k dial up
+Our Name Server will be the `strider` host which also runs IPNAT, and our two
+clients use "strider" as a gateway. It is not really relevant as to what type of
+interface is on "strider", but for argument's sake we will say a 56k dial up
connection.
So, before going any further, let's look at our `/etc/hosts` file on "strider"
@@ -345,17 +349,17 @@ before we have made the alterations to u
192.168.1.2 samwise sam
192.168.1.3 wormtongue worm
-This is not exactly a huge network, but it is worth noting that the same rules
+This is not exactly a huge network, but it is worth noting that the same rules
apply for larger networks as we discuss in the context of this section.
-The other assumption we want to make is that the domain we want to set up is
-`diverge.org`, and that the domain is only known on our internal network, and
-not worldwide. Proper registration of the nameserver's IP address as primary
-would be needed in addition to a static IP. These are mostly administrative
+The other assumption we want to make is that the domain we want to set up is
+`diverge.org`, and that the domain is only known on our internal network, and
+not worldwide. Proper registration of the nameserver's IP address as primary
+would be needed in addition to a static IP. These are mostly administrative
issues which are left out here.
-The NetBSD operating system provides a set of config files for you to use for
-setting up DNS. Along with a default `/etc/named.conf`, the following files are
+The NetBSD operating system provides a set of config files for you to use for
+setting up DNS. Along with a default `/etc/named.conf`, the following files are
stored in the `/etc/namedb` directory:
* `localhost`
@@ -363,18 +367,18 @@ stored in the `/etc/namedb` directory:
* `loopback.v6`
* `root.cache`
-You will see modified versions of these files in this section, and I strongly
+You will see modified versions of these files in this section, and I strongly
suggest making a backup copy of the original files for reference purposes.
-*Note*: The examples in this chapter refer to BIND major version 8, however, it
-should be noted that format of the name database and other config files are
-almost 100% compatible between version. The only difference I noticed was that
+*Note*: The examples in this chapter refer to BIND major version 8, however, it
+should be noted that format of the name database and other config files are
+almost 100% compatible between version. The only difference I noticed was that
the `$TTL` information was not required.
### /etc/named.conf
-The first file we want to look at is `/etc/named.conf`. This file is the config
-file for bind (hence the catchy name). Setting up system like the one we are
+The first file we want to look at is `/etc/named.conf`. This file is the config
+file for bind (hence the catchy name). Setting up system like the one we are
doing is relatively simple. First, here is what mine looks like:
options {
@@ -418,71 +422,71 @@ doing is relatively simple. First, here
file "root.cache";
};
-Note that in my `named.conf` the root (".") section is last, that is because
-there is another domain called diverge.org on the internet (I happen to own it)
-so I want the resolver to look out on the internet last. This is not normally
+Note that in my `named.conf` the root (".") section is last, that is because
+there is another domain called diverge.org on the internet (I happen to own it)
+so I want the resolver to look out on the internet last. This is not normally
the case on most systems.
-Another very important thing to remember here is that if you have an internal
-setup, in other words no live internet connection and/or no need to do root
-server lookups, comment out the root (".") zone. It may cause lookup problems if
-a particular client decides it wants to reference a domain on the internet,
+Another very important thing to remember here is that if you have an internal
+setup, in other words no live internet connection and/or no need to do root
+server lookups, comment out the root (".") zone. It may cause lookup problems if
+a particular client decides it wants to reference a domain on the internet,
which our server couldn't resolve itself.
-Looks like a pretty big mess, upon closer examination it is revealed that many
-of the lines in each section are somewhat redundant. So we should only have to
+Looks like a pretty big mess, upon closer examination it is revealed that many
+of the lines in each section are somewhat redundant. So we should only have to
explain them a few times.
Lets go through the sections of `named.conf`:
#### options
-This section defines some global parameters, most noticeable is the location of
-the DNS tables, on this particular system, they will be put in `/etc/namedb` as
+This section defines some global parameters, most noticeable is the location of
+the DNS tables, on this particular system, they will be put in `/etc/namedb` as
indicated by the "directory" option.
Following are the rest of the params:
- * `allow-transfer` -- This option lists which remote DNS servers acting as
- secondaries are allowed to do zone transfers, i.e. are allowed to read all
- DNS data at once. For privacy reasons, this should be restricted to secondary
+ * `allow-transfer` -- This option lists which remote DNS servers acting as
+ secondaries are allowed to do zone transfers, i.e. are allowed to read all
+ DNS data at once. For privacy reasons, this should be restricted to secondary
DNS servers only.
- * `allow-query` -- This option defines hosts from what network may query this
- name server at all. Restricting queries only to the local network
- (192.168.1.0/24) prevents queries arriving on the DNS server's external
+ * `allow-query` -- This option defines hosts from what network may query this
+ name server at all. Restricting queries only to the local network
+ (192.168.1.0/24) prevents queries arriving on the DNS server's external
interface, and prevent possible privacy issues.
- * `listen-on port` -- This option defined the port and associated IP addresses
- this server will run
- [named(8)](http://netbsd.gw.com/cgi-bin/man-cgi?named+8+NetBSD-5.0.1+i386)
- on. Again, the "external" interface is not listened here, to prevent queries
+ * `listen-on port` -- This option defined the port and associated IP addresses
+ this server will run
+ [named(8)](http://netbsd.gw.com/cgi-bin/man-cgi?named+8+NetBSD-5.0.1+i386)
+ on. Again, the "external" interface is not listened here, to prevent queries
getting received from "outside".
-The rest of the `named.conf` file consists of `zone`s. A zone is an area that
-can have items to resolve attached, e.g. a domain can have hostnames attached to
-resolve into IP addresses, and a reverse-zone can have IP addresses attached
-that get resolved back into hostnames. Each zone has a file associated with it,
-and a table within that file for resolving that particular zone. As is readily
-apparent, their format in `named.conf` is strikingly similar, so I will
+The rest of the `named.conf` file consists of `zone`s. A zone is an area that
+can have items to resolve attached, e.g. a domain can have hostnames attached to
+resolve into IP addresses, and a reverse-zone can have IP addresses attached
+that get resolved back into hostnames. Each zone has a file associated with it,
+and a table within that file for resolving that particular zone. As is readily
+apparent, their format in `named.conf` is strikingly similar, so I will
highlight just one of their records:
#### zone diverge.org
- * `type` -- The type of a zone is usually of type "master" in all cases except
- for the root zone `.` and for zones that a secondary (backup) service is
+ * `type` -- The type of a zone is usually of type "master" in all cases except
+ for the root zone `.` and for zones that a secondary (backup) service is
provided - the type obviously is "secondary" in the latter case.
- * `notify` -- Do you want to send out notifications to secondaries when your
+ * `notify` -- Do you want to send out notifications to secondaries when your
zone changes? Obviously not in this setup, so this is set to "no".
- * `file` -- This option sets the filename in our `/etc/namedb` directory where
- records about this particular zone may be found. For the "diverge.org" zone,
+ * `file` -- This option sets the filename in our `/etc/namedb` directory where
+ records about this particular zone may be found. For the "diverge.org" zone,
the file `/etc/namedb/diverge.org` is used.
### /etc/namedb/localhost
-For the most part, the zone files look quite similar, however, each one does
+For the most part, the zone files look quite similar, however, each one does
have some unique properties. Here is what the `localhost` file looks like:
1|$TTL 3600
@@ -498,28 +502,28 @@ have some unique properties. Here is wha
Line by line:
- * *Line 1*: This is the Time To Live for lookups, which defines how long other
- DNS servers will cache that value before discarding it. This value is
+ * *Line 1*: This is the Time To Live for lookups, which defines how long other
+ DNS servers will cache that value before discarding it. This value is
generally the same in all the files.
- * *Line 2*: This line is generally the same in all zone files except
- `root.cache`. It defines a so-called "Start Of Authority" (SOA) header, which
- contains some basic information about a zone. Of specific interest on this
- line are "strider.diverge.org." and "root.diverge.org." (note the trailing
- dots!). Obviously one is the name of this server and the other is the contact
- for this DNS server, in most cases root seems a little ambiguous, it is
- preferred that a regular email account be used for the contact information,
- with the "@" replaced by a "." (for example, mine would be
+ * *Line 2*: This line is generally the same in all zone files except
+ `root.cache`. It defines a so-called "Start Of Authority" (SOA) header, which
+ contains some basic information about a zone. Of specific interest on this
+ line are "strider.diverge.org." and "root.diverge.org." (note the trailing
+ dots!). Obviously one is the name of this server and the other is the contact
+ for this DNS server, in most cases root seems a little ambiguous, it is
+ preferred that a regular email account be used for the contact information,
+ with the "@" replaced by a "." (for example, mine would be
"jrf.diverge.org.").
- * *Line 3*: This line is the serial number identifying the "version" of the
- zone's data set (file). The serial number should be incremented each time
- there is a change to the file, the usual format is to either start with a
- value of "1" and increase it for every change, or use a value of "YYYYMMDDNN"
- to encode year (YYYY), month (MM), day (DD) and change within one day (NN) in
+ * *Line 3*: This line is the serial number identifying the "version" of the
+ zone's data set (file). The serial number should be incremented each time
+ there is a change to the file, the usual format is to either start with a
+ value of "1" and increase it for every change, or use a value of "YYYYMMDDNN"
+ to encode year (YYYY), month (MM), day (DD) and change within one day (NN) in
the serial number.
- * *Line 4*: This is the refresh rate of the server, in this file it is set to
+ * *Line 4*: This is the refresh rate of the server, in this file it is set to
once every 8 hours.
* *Line 5*: The retry rate.
@@ -528,22 +532,22 @@ Line by line:
* *Line 7*: The minimum Time To Live.
- * *Line 8*: This is the Nameserver line, which uses a "NS" resource record to
- show that "localhost" is the only DNS server handing out data for this zone
- (which is "@", which indicates the zone name used in the `named.conf` file,
+ * *Line 8*: This is the Nameserver line, which uses a "NS" resource record to
+ show that "localhost" is the only DNS server handing out data for this zone
+ (which is "@", which indicates the zone name used in the `named.conf` file,
i.e. "diverge.org") is, well, "localhost".
- * *Line 9*: This is the localhost entry, which uses an "A" resource record to
- indicate that the name "localhost" should be resolved into the IP-address
+ * *Line 9*: This is the localhost entry, which uses an "A" resource record to
+ indicate that the name "localhost" should be resolved into the IP-address
127.0.0.1 for IPv4 queries (which specifically ask for the "A" record).
- * *Line 10*: This line is the IPv6 entry, which returns ::1 when someone asks
- for an IPv6-address (by specifically asking for the AAAA record) of
+ * *Line 10*: This line is the IPv6 entry, which returns ::1 when someone asks
+ for an IPv6-address (by specifically asking for the AAAA record) of
"localhost.".
### /etc/namedb/zone.127.0.0
-This is the reverse lookup file (or zone) to resolve the special IP address
+This is the reverse lookup file (or zone) to resolve the special IP address
127.0.0.1 back to "localhost":
1| $TTL 3600
@@ -556,18 +560,18 @@ This is the reverse lookup file (or zone
8| IN NS localhost.
9| 1.0.0 IN PTR localhost.
-In this file, all of the lines are the same as the localhost zonefile with
-exception of line 9, this is the reverse lookup (PTR) record. The zone used here
-is "@" again, which got set to the value given in `named.conf`, i.e.
-"127.in-addr.arpa". This is a special "domain" which is used to do
-reverse-lookup of IP addresses back into hostnames. For it to work, the four
-bytes of the IPv4 address are reserved, and the domain "in-addr.arpa" attached,
-so to resolve the IP address "127.0.0.1", the PTR record of
+In this file, all of the lines are the same as the localhost zonefile with
+exception of line 9, this is the reverse lookup (PTR) record. The zone used here
+is "@" again, which got set to the value given in `named.conf`, i.e.
+"127.in-addr.arpa". This is a special "domain" which is used to do
+reverse-lookup of IP addresses back into hostnames. For it to work, the four
+bytes of the IPv4 address are reserved, and the domain "in-addr.arpa" attached,
+so to resolve the IP address "127.0.0.1", the PTR record of
"1.0.0.127.in-addr.arpa" is queried, which is what is defined in that line.
### /etc/namedb/diverge.org
-This zone file is populated by records for all of our hosts. Here is what it
+This zone file is populated by records for all of our hosts. Here is what it
looks like:
1| $TTL 3600
@@ -585,27 +589,27 @@ looks like:
13| www IN CNAME samwise.diverge.org.
14| worm IN A 192.168.1.3
-There is a lot of new stuff here, so lets just look over each line that is new
+There is a lot of new stuff here, so lets just look over each line that is new
here:
- * *Line 9*: This line shows our mail exchanger (MX), in this case it is
- "strider". The number that precedes "strider.diverge.org." is the priority
- number, the lower the number their higher the priority. The way we are setup
+ * *Line 9*: This line shows our mail exchanger (MX), in this case it is
+ "strider". The number that precedes "strider.diverge.org." is the priority
+ number, the lower the number their higher the priority. The way we are setup
here is if "strider" cannot handle the mail, then "samwise" will.
- * *Line 11*: CNAME stands for canonical name, or an alias for an existing
- hostname, which must have an A record. So we have aliased `www.diverge.org`
+ * *Line 11*: CNAME stands for canonical name, or an alias for an existing
+ hostname, which must have an A record. So we have aliased `www.diverge.org`
to `samwise.diverge.org`.
-The rest of the records are simply mappings of IP address to a full name (A
+The rest of the records are simply mappings of IP address to a full name (A
records).
### /etc/namedb/1.168.192
-This zone file is the reverse file for all of the host records, to map their IP
-numbers we use on our private network back into hostnames. The format is similar
-to that of the "localhost" version with the obvious exception being the
-addresses are different via the different zone given in the `named.conf` file,
+This zone file is the reverse file for all of the host records, to map their IP
+numbers we use on our private network back into hostnames. The format is similar
+to that of the "localhost" version with the obvious exception being the
+addresses are different via the different zone given in the `named.conf` file,
i.e. "0.168.192.in-addr.arpa" here:
1|$TTL 3600
@@ -622,8 +626,8 @@ i.e. "0.168.192.in-addr.arpa" here:
### /etc/namedb/root.cache
-This file contains a list of root name servers for your server to query when it
-gets requests outside of its own domain that it cannot answer itself. Here are
+This file contains a list of root name servers for your server to query when it
+gets requests outside of its own domain that it cannot answer itself. Here are
first few lines of a root zone file:
;
@@ -659,42 +663,42 @@ first few lines of a root zone file:
;
...
-This file can be obtained from ISC at and usually comes
-with a distribution of BIND. A `root.cache` file is included in the NetBSD
+This file can be obtained from ISC at and usually comes
+with a distribution of BIND. A `root.cache` file is included in the NetBSD
operating system's "etc" set.
-This section has described the most important files and settings for a DNS
-server. Please see the BIND documentation in `/usr/src/dist/bind/doc/bog` and
-[named.conf(5)](http://netbsd.gw.com/cgi-bin/man-cgi?named.conf+5+NetBSD-5.0.1+i386)
+This section has described the most important files and settings for a DNS
+server. Please see the BIND documentation in `/usr/src/dist/bind/doc/bog` and
+[named.conf(5)](http://netbsd.gw.com/cgi-bin/man-cgi?named.conf+5+NetBSD-5.0.1+i386)
for more information.
## Using DNS
-In this section we will look at how to get DNS going and setup "strider" to use
+In this section we will look at how to get DNS going and setup "strider" to use
its own DNS services.
-Setting up named to start automatically is quite simple. In `/etc/rc.conf`
-simply set `named=yes`. Additional options can be specified in `named_flags`,
-for example, I like to use `-g nogroup -u nobody`, so a non-root account runs
+Setting up named to start automatically is quite simple. In `/etc/rc.conf`
+simply set `named=yes`. Additional options can be specified in `named_flags`,
+for example, I like to use `-g nogroup -u nobody`, so a non-root account runs
the "named" process.
-In addition to being able to startup "named" at boot time, it can also be
-controlled with the `ndc` command. In a nutshell the `ndc` command can stop,
-start or restart the named server process. It can also do a great many other
-things. Before use, it has to be setup to communicate with the "named" process,
-see the [ndc(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ndc+8+NetBSD-5.0.1+i386)
-and
-[named.conf(5)](http://netbsd.gw.com/cgi-bin/man-cgi?named.conf+5+NetBSD-5.0.1+i386)
-man pages for more details on setting up communication channels between "ndc"
+In addition to being able to startup "named" at boot time, it can also be
+controlled with the `ndc` command. In a nutshell the `ndc` command can stop,
+start or restart the named server process. It can also do a great many other
+things. Before use, it has to be setup to communicate with the "named" process,
+see the [ndc(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ndc+8+NetBSD-5.0.1+i386)
+and
+[named.conf(5)](http://netbsd.gw.com/cgi-bin/man-cgi?named.conf+5+NetBSD-5.0.1+i386)
+man pages for more details on setting up communication channels between "ndc"
and the "named" process.
-Next we want to point "strider" to itself for lookups. We have two simple steps,
-first, decide on our resolution order. On a network this small, it is likely
-that each host has a copy of the hosts table, so we can get away with using
-`/etc/hosts` first, and then DNS. However, on larger networks it is much easier
-to use DNS. Either way, the file where order of name services used for
-resolution is determined is `/etc/nsswitch.conf` (see
-[[`nsswitch.conf`|guide/net-practice#ex-nsswitch]]. Here is part of a typical
+Next we want to point "strider" to itself for lookups. We have two simple steps,
+first, decide on our resolution order. On a network this small, it is likely
+that each host has a copy of the hosts table, so we can get away with using
+`/etc/hosts` first, and then DNS. However, on larger networks it is much easier
+to use DNS. Either way, the file where order of name services used for
+resolution is determined is `/etc/nsswitch.conf` (see
+[[`nsswitch.conf`|guide/net-practice#ex-nsswitch]]. Here is part of a typical
`nsswitch.conf`:
...
@@ -703,23 +707,23 @@ resolution is determined is `/etc/nsswit
netgroup: files [notfound=return] nis
...
-The line we are interested in is the "hosts" line. "files" means the system uses
-the `/etc/hosts` file first to determine ip to name translation, and if it can't
+The line we are interested in is the "hosts" line. "files" means the system uses
+the `/etc/hosts` file first to determine ip to name translation, and if it can't
find an entry, it will try DNS.
-The next file to look at is `/etc/resolv.conf`, which is used to configure DNS
-lookups ("resolution") on the client side. The format is pretty self explanatory
+The next file to look at is `/etc/resolv.conf`, which is used to configure DNS
+lookups ("resolution") on the client side. The format is pretty self explanatory
but we will go over it anyway:
domain diverge.org
search diverge.org
nameserver 192.168.1.1
-In a nutshell this file is telling the resolver that this machine belongs to the
-"diverge.org" domain, which means that lookups that contain only a hostname
-without a "." gets this domain appended to build a FQDN. If that lookup doesn't
-succeed, the domains in the "search" line are tried next. Finally, the
-"nameserver" line gives the IP addresses of one or more DNS servers that should
+In a nutshell this file is telling the resolver that this machine belongs to the
+"diverge.org" domain, which means that lookups that contain only a hostname
+without a "." gets this domain appended to build a FQDN. If that lookup doesn't
+succeed, the domains in the "search" line are tried next. Finally, the
+"nameserver" line gives the IP addresses of one or more DNS servers that should
be used to resolve DNS queries.
To test our nameserver we can use several commands, for example:
@@ -727,7 +731,7 @@ To test our nameserver we can use severa
# host sam
sam.diverge.org has address 192.168.1.2
-As can be seen, the domain was appended automatically here, using the value from
+As can be seen, the domain was appended automatically here, using the value from
`/etc/resolv.conf`. Here is another example, the output of running
`host www.yahoo.com`:
@@ -742,32 +746,32 @@ As can be seen, the domain was appended
www.yahoo.akadns.net has address 68.142.226.55
www.yahoo.akadns.net has address 68.142.226.32
-Other commands for debugging DNS besides
-[host(1)](http://netbsd.gw.com/cgi-bin/man-cgi?host+1+NetBSD-5.0.1+i386) are
-[nslookup(8)](http://netbsd.gw.com/cgi-bin/man-cgi?nslookup+8+NetBSD-5.0.1+i386)
+Other commands for debugging DNS besides
+[host(1)](http://netbsd.gw.com/cgi-bin/man-cgi?host+1+NetBSD-5.0.1+i386) are
+[nslookup(8)](http://netbsd.gw.com/cgi-bin/man-cgi?nslookup+8+NetBSD-5.0.1+i386)
and
-[dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386). Note
+[dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386). Note
that
[ping(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ping+8+NetBSD-5.0.1+i386)
-is *not* useful for debugging DNS, as it will use whatever is configured in
+is *not* useful for debugging DNS, as it will use whatever is configured in
`/etc/nsswitch.conf` to do the name-lookup.
-At this point the server is configured properly. The procedure for setting up
-the client hosts are easier, you only need to setup `/etc/nsswitch.conf` and
+At this point the server is configured properly. The procedure for setting up
+the client hosts are easier, you only need to setup `/etc/nsswitch.conf` and
`/etc/resolv.conf` to the same values as on the server.
## Setting up a caching only name server
-A caching only name server has no local zones; all the queries it receives are
-forwarded to the root servers and the replies are accumulated in the local
-cache. The next time the query is performed the answer will be faster because
-the data is already in the server's cache. Since this type of server doesn't
-handle local zones, to resolve the names of the local hosts it will still be
+A caching only name server has no local zones; all the queries it receives are
+forwarded to the root servers and the replies are accumulated in the local
+cache. The next time the query is performed the answer will be faster because
+the data is already in the server's cache. Since this type of server doesn't
+handle local zones, to resolve the names of the local hosts it will still be
necessary to use the already known `/etc/hosts` file.
-Since NetBSD supplies defaults for all the files needed by a caching only
-server, it only needs to be enabled and started and is immediately ready for
-use! To enable named, put `named=yes` into `/etc/rc.conf`, and tell the system
+Since NetBSD supplies defaults for all the files needed by a caching only
+server, it only needs to be enabled and started and is immediately ready for
+use! To enable named, put `named=yes` into `/etc/rc.conf`, and tell the system
to use it adding the following line to the `/etc/resolv.conf` file:
# cat /etc/resolv.conf
@@ -779,8 +783,8 @@ Now we can start named:
### Testing the server
-Now that the server is running we can test it using the
-[nslookup(8)](http://netbsd.gw.com/cgi-bin/man-cgi?nslookup+8+NetBSD-5.0.1+i386)
+Now that the server is running we can test it using the
+[nslookup(8)](http://netbsd.gw.com/cgi-bin/man-cgi?nslookup+8+NetBSD-5.0.1+i386)
program:
$ nslookup
@@ -808,16 +812,16 @@ If you repeat the query a second time, t
Name: www.NetBSD.org
Address: 204.152.190.12
-As you've probably noticed, the address is the same, but the message
-`Non-authoritative answer` has appeared. This message indicates that the answer
-is not coming from an authoritative server for the domain NetBSD.org but from
+As you've probably noticed, the address is the same, but the message
+`Non-authoritative answer` has appeared. This message indicates that the answer
+is not coming from an authoritative server for the domain NetBSD.org but from
the cache of our own server.
The results of this first test confirm that the server is working correctly.
-We can also try the
-[host(1)](http://netbsd.gw.com/cgi-bin/man-cgi?host+1+NetBSD-5.0.1+i386) and
-[dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386) commands,
+We can also try the
+[host(1)](http://netbsd.gw.com/cgi-bin/man-cgi?host+1+NetBSD-5.0.1+i386) and
+[dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386) commands,
which give the following result.
$ host www.NetBSD.org
@@ -846,10 +850,10 @@ which give the following result.
;; Total query time: 14 msec
;; FROM: miyu to SERVER: 127.0.0.1
;; WHEN: Thu Nov 25 22:59:36 2004
- ;; MSG SIZE sent: 32 rcvd: 175
+ ;; MSG SIZE sent: 32 rcvd: 175
-As you can see
-[dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386) gives
-quite a bit of output, the expected answer can be found in the "ANSWER SECTION".
+As you can see
+[dig(1)](http://netbsd.gw.com/cgi-bin/man-cgi?dig+1+NetBSD-5.0.1+i386) gives
+quite a bit of output, the expected answer can be found in the "ANSWER SECTION".
The other data given may be of interest when debugging DNS problems.