DNS Guide For Network Professionals

DNS Guide for Network
Professionals
Nixu Software
Mäkelänkatu 91
FIN-00610 Helsinki
Finland
Table of contents
About this document...........................................................................................................4
Introduction.........................................................................................................................5
DNS concepts......................................................................................................................7
Authoritative name servers ............................................................................................7
BIND ...............................................................................................................................7
Caching............................................................................................................................7
Delegation .......................................................................................................................7
DNS - the Domain Name System..................................................................................8
Domains and domain names..........................................................................................8
FQDN - Fully Qualified Domain Name......................................................................10
IDN – Internationalized Domain Names.....................................................................10
IP addresses...................................................................................................................10
Primary name server.....................................................................................................11
Recursion.......................................................................................................................11
Resolvers .......................................................................................................................11
Resource records...........................................................................................................12
Reverse mappings.........................................................................................................12
The root domain............................................................................................................13
Secondary name servers ...............................................................................................13
Time to live ...................................................................................................................14
Wildcard records...........................................................................................................14
Zones .............................................................................................................................14
Zone transfers ...............................................................................................................15
Zone file and its records...............................................................................................15
More about BIND .............................................................................................................17
BIND directories and files ...........................................................................................17
Configuring BIND........................................................................................................17
Running BIND..............................................................................................................18
Standard Resource Records..............................................................................................19
A records .......................................................................................................................19
AAAA records ..............................................................................................................19
A6 records .....................................................................................................................19
CNAME records ...........................................................................................................20
DNAME records...........................................................................................................20
HINFO records .............................................................................................................21
LOC records..................................................................................................................21
MX records ...................................................................................................................21
NS records.....................................................................................................................22
PTR records ..................................................................................................................23
RP records.....................................................................................................................23
The SOA record ............................................................................................................24
SRV records..................................................................................................................25
TXT records ..................................................................................................................25
WKS records.................................................................................................................26
Administration of DNS ....................................................................................................27
Troubleshooting DNS.......................................................................................................30
The most common errors in the zone data..................................................................30
© Nixu Software Limited 2006. All Rights Reserved. 2

Troubleshooting a name server....................................................................................30
Troubleshooting secondary hosts ................................................................................31
Designing a DNS environment with the help of Nixu NameSurfer ..............................32
External vs. internal DNS ............................................................................................32
Number of clients vs. number of servers in the internal DNS...................................32
Number of servers in the external DNS ......................................................................34
Number of servers in the mixed DNS .........................................................................34
The size of zones ..........................................................................................................36
Adding a DHCP DynDNS feature to the DNS environment.....................................36
How to make a DNS environment reliable and fault-tolerant ...................................36
Best Practices (a mini-Howto).........................................................................................38
Glossary.............................................................................................................................39

About this document
Two parallel, widely used Domain Name Systems exist at present: BIND and
Windows. Nixu Software specializes in systems based on BIND, compatible with
Nixu NameSurfer. (For details on BIND, please see chapter DNS concepts).
This document aims at giving the basic information about the BIND DNS system and
describing how to implement a functional DNS environment using Nixu NameSurfer.
Special weight has been given to the explanation of the central concepts.
For additional reading, we recommend two books:
• DNS and BIND in a Nutshell (by Paul Albitz & Cricket Liu, O'Reilly &
Associates, Inc.), and
• BIND Administrator's Reference Manual
(http://www.isc.org/products/BIND/bind9.html).
Additional information is also available in the Nixu NameSurfer Reference Manual.

Introduction
Domain Name Service (DNS) was introduced in 1983 to facilitate the translation
between host names (for example, foo.bar.com) and Internet Protocol (IP) addresses
(for example, 1.2.3.4). Both are necessary to be able to connect network devices to
each other over the Internet: the host names for the users, and the IP addresses for the
devices. The situation could be compared to the use of the phone and the phone book:
it is much easier to remember a person's name than his or her phone number.
Similarly, host names were invented to spare the human memory of the trouble of
memorizing the necessary Intenet addresses.
Although names and addresses are stored (cached) locally, they are available globally
through the Internet. Caching improves system performance by shortening the query
times. The distributed host information database is responsible for translating names
into addresses, routing mail to its proper destination, and many other services (Albitz
& Liu: DNS and BIND, 2001). The architecture of DNS resembles that of Unix a
great deal in that they share the tree structure of their file systems, so basic knowledge
of Unix is a great help to the DNS user.
Figure 1: DNS Architecture
Example: What IP address corresponds to the host name NIXU.com? The client
program of the Internet host that wants this information queries it from its resolver,
which checks its cache for an answer. If it is not found there, the resolver forwards the
query to the name server host serving the Internet host. The name server checks its
database and cache for the answer. If the information is found there, the name server

returns it to the Internet host; if it is not, the name server forwards the query to the
following name server in the hierarchy, and so on.
Figure 2: Name Resolution
This distributed system was designed keeping scalability in mind – it is easy to add on
to it at various places of the network – and it can handle network errors easily: if one
of the routes is blocked, there is always a way round it.
The administration of DNS is also distributed – this is one of the major reasons why
DNS administration tools such as Nixu NameSurfer are needed. (Other good reasons
include avoiding mistakes in DNS files and displaying the data in human-readable
form.)
The main components of DNS are the name space structure, resolvers and name
servers (see chapter More concepts at the end of this document).

DNS concepts
Authoritative name servers
A name server is said to be authoritative for some given zone when it has a complete
set of data for the zone, allowing it to answer queries about the zone on its own,
without needing to consult another server.
All primary and secondary name servers are authoritative for their respective zones.
At least two of the authoritative name servers of each zone should be listed in the
zone's NS (name server) records. The zone may also have additional, "unofficial"
authoritative name servers that are not listed in NS records. The official, listed name
servers should be the same as those listed at the delegation point in the parent domain.
BIND
BIND (Berkeley Internet Name Daemon) is a common, freely redistributed, name
server implementation. Most UNIX vendors bundle a version of BIND with their
operating system. There are also versions of BIND available for Windows NT.
BIND can act simultaneously as a primary, secondary, and caching name server
providing recursive service.
As Nixu NameSurfer is a dedicated primary name server, it relies on one or more

separate BIND servers to provide secondary and caching/recursive name service.
Caching
Some name servers perform caching of DNS data. This means that they may answer
recursive DNS queries, using saved results from an earlier, similar query, instead
performing a full DNS lookup. Caching reduces network traffic and improves the
average response time.
Caching is controlled by the time-to-live (TTL) value of the DNS data.
Delegation
Domains can be delegated to organizations. Delegation means transfer of authority
and control over a domain and it is done by configuring the names of the servers
controlling the domain in the parent name server.
A delegated subdomain is a domain that is administrated separately from its parent. It
has its own set of authoritative name servers, usually different from that of the parent.

DNS - the Domain Name System
The Domain Name System (DNS) is a distributed, hierarchical database whose
primary function is to convert user-friendly domain names like www.domain.com into
numeric IP addresses like 10.211.57.180 and vice versa.
The DNS is also used for storing and retrieving mail-routing information (MX
records) and various kinds of general administrative information (for example, host
information and free-format comments).
Domains and domain names

A domain name is a way of naming a host or other network entity. For example,
www.nixu.com is a domain name referring to the WWW server of Nixu Ltd.
Domain names are organized hierarchically into domains. For example, the name
www.nixu.com belongs to the nixu.com domain, which is a subdomain of the com
domain, which in turn is a subdomain of the root domain.
Domain names and domains are analogous to file names and directories in a tree-
structured file system - they just happen to use dots instead of slashes or backslashes
as separators, and their components are written in the opposite order.
Each domain may be administered as a separate unit (a zone), which may include
none, some, or all of its subdomains.
The dot-separated components of a domain name are known as "labels". Each label
may be up to 63 characters in length, and the entire domain name is restricted to 255
characters.
Although the DNS itself does not restrict the character set of domain labels, other
software that uses domain names may have such restrictions. To avoid problems, it is
recommended that only letters, digits, and minus signs (-) be used, particularly in
domain names that have A or MX records.
Root servers
"The root name servers know where the authoritative name servers for each of the
top-level zones are. (In fact, some of the root name servers are authoritative for the
generic top-level zones.)" (Albitz & Liu, 2001) Thus, in the process of querying
names, root servers can guide the query towards the correct top-level zone, which will
help find the correct second-level zone and so on, until the whole address is resolved.
Currently, 13 root servers exist in the Internet.
Top level domains

Top-level domains represent the shares of addresses allocated to different kinds of
bodies: countries (each has its own individual label – see below; label – see chapter
More concepts), companies and organizations. They are administered by an
international organization called ICANN (Internet Corporation for Assigned Names
and Numbers, http://www.icann.org).
DNS names reflect the name space hierarchy in that the label of the topmost directory
is situated at the end of the address (example: host.company.com). Below, the labels
representing top level domains are introduced.
Originally, labels were meant for international use as follows:
• .com for commercial organizations

• .org for non-commercial organizations
• .net for network companies
• .edu for educational organizations
• .int for international organizations.
Nowadays, however, their use is less category-restricted and they are allowed for the
use of other bodies as well. In addition to these, seven new labels were introduced by
ICANN in November 2000: .aero, .biz, .coop, .info, .museum, .name, and .pro (being
gradually taken in use, see http://www.internic.net/faqs/new-tlds.html for more
information).
The following labels are reserved for the US Government:
• .gov for the US Government

• .mil for the US military.
National domain names are abbreviations according to the ISO 3166 standard, for
example,
• .uk for the United Kingdom

• .cn for China
• .fi for Finland.
Some national top-level domains have internal structures similar to common top level
domains, for example, edu.au, and tailored combinations such as ac.uk (ac = academic
community).
Subdomains
National top-level domains are adminstered by organizations which delegate

subdomains to other entities, public and private. Any subdomain must be registered
with its parent domain, which must configure the existence of this subdomain in its

zone field (see below).
FQDN - Fully Qualified Domain Name

A Fully Qualified Domain Name (FQDN) is a domain name written in its full,
unambiguous form, listing all its parent domains all the way to the root domain. For
example, www.nixu.com is a FQDN because it ends in the top-level domain com.
The opposite of a FQDN is a relative domain name like www or www.nixu , where one
or more parent domain labels have been omitted for convenience or brevity.
Nixu NameSurfer allows the use of relative domain names only in certain places
where it can determine the correct parent domain from the context. Otherwise,
FQDNs must be used.
Binary labels as specified in RFC 2673 ("Binary Labels in the Domain Name
System") might be used in Nixu NameSurfer as well as traditional labels.
Some other DNS software, BIND for example, requires you to write a trailing period
after each FQDN (as in "www.nixu.com. "). The NameSurfer WWW user interface
also allows you to include this trailing period, but does not require it. The only
exception is the root domain, which must be entered as ".", not as the empty string.
IDN – Internationalized Domain Names

In addition to the standard ASCII character set, other character sets can be used in
domain names since 2001. Some technical and policy issues regarding their use,
however, remain unsolved. Presently, the prevailing method is to translate the local
encoding into ASCII compatible encoding at the user’s computer.
So far, well over a million IDNs have been registered but no IDN standard exists yet.
The existence of IDNs will also create a demand for top level IDNs.
(In Nixu NameSurfer, the choice of IDN is a matter of a configuration option.)
IP addresses
Every host on the Internet, or on any other TCP/IP network, has a unique numeric
address, the IP address.
There are two sorts of IP addresses: IPv4 and IPv6 addresses.

An IPv4 address is a 32-bit number, usually written in "dotted quad" form, that is, as
four 8-bit decimal numbers (0-255) separated by dots: 10.123.82.255.
In the DNS, the IPv4 address of each host is stored as an A record associated with the
host's domain name.
An IPv6 address in its complete form is written in a form x:x:x:x:x:x:x:x , where

each x is at most 4 digits long hexadecimal value. A sequence of zero bits in IPv6
address might be shorten by a :: sign. For example: 1080:0:0:0:8:800:200C:417A
and FF01::101 are IPv6 addresses.
In the DNS, the complete IPv6 might be stored as an AAAA record associated with
the host's domain name. Alternatively part of the address might be stored in A6
record, which supports automatic reverse map creation, aggregation and network
renumbering.
Primary name server

A primary name server, also known as a primary master or just a primary, is a name
server where the actual master copy of the DNS data for a given zone is maintained.
Nixu NameSurfer is a primary name server.
Recursion
When looking up an "outside" domain name, it is often necessary to query several
distant name servers in turn before arriving at the final result.
For example, finding the IP address of www.nixu.com may require up to three

consecutive DNS queries: first to a root name server, then to a server authoritative for
the .com domain, and finally to a server authoritative for the .nixu.com domain.
Most resolvers are rather primitive ("stub resolvers") and are not able to perform this
relatively complicated process by themselves. Instead, the resolver asks a single,
nearby name server to perform the lookup on its behalf by sending it a recursive
query.
A name server willing to provide the service of performing lookups on the behalf of
local resolvers is called a recursive name server. Typically, recursive name servers
also perform caching. Nixu NameSurfer relies on a separate BIND server to provide
recursion and caching services.
Resolvers

Application programs usually do not talk directly to name servers. Instead, they use
an intermediate piece of software called a resolver. The resolver relays DNS queries
and their results between the applications and the name servers.
The resolver often takes the form of a subroutine library that is linked with the
application code. In some systems the resolver comes with the operating system
(UNIX, Windows 95 etc). In others, it is part of an external TCP/IP package
(Winsock, PC-TCP, etc).
When attaching a new host to the network, its resolver needs to be configured with the
IP address of one or more nearby name servers, so it knows where to send its DNS
queries. On many UNIX systems, this is done by editing the file /etc/resolv.conf .
Resource records
The data stored in the DNS are organized into resource records (RRs). Each domain
name has one or more resource records, which can be of different types for storing
different kinds of data.
The DNS RFCs specify a set of standard resource record types and their syntax (for
example, SOA, NS, A, MX, CNAME, PTR, HINFO, TXT, etc).
The DNS is designed to be extensible with new kinds of data, and new RR types are
frequently defined whenever the need arises.
Different resource record types are used for different purposes. For example, SOA
and NS are resource records used internally by DNS itself, whereas A and CNAME
records are used by application programs, and MX records are used in e-mail
delivery.
Standard resource records are described in a separate chapter below.
Reverse mappings
Reverse mapping means finding the domain name corresponding to a given IP
address. This is the opposite from the usual kind of DNS lookup, where you try to
find the IP address corresponding to a given domain name.
For IPv4 addresses (A records) reverse mappings are stored in a separate set of
subdomains called the IN-ADDR.ARPA hierarchy. An IP address is turned into the
corresponding IN-ADDR.ARPA name by reversing the order of the octets and
appending .IN-ADDR.ARPA.

For IPv6 addresses (A6 records) reverse mappings are stored in the zone defined by
prefix name. Reverse zone is derived from the prefix name by adding IP6 label in
front of prefix name.
For example, the reverse mapping of the IP address 192.168.1.2 is stored under the
name 2.1.168.192.IN-ADDR.ARPA. That name should have a PTR record which
points at the domain name of the machine with the IP address 192.168.1.2. For IPv6
address N.X.COM. A6 64 ::1234:5678:9ABC:DEF0 PREFIX.X.COM reverse map
PTR record name is \[x123456789ABCDEF0].IP6.PREFIX.X.COM.
If more than one domain name points at the same IP address, the corresponding IN-
ADDR.ARPA name may have several PTR records.
When you add or delete hosts in your forward zones, Nixu NameSurfer will
automatically try to add or delete a PTR record for the corresponding reverse map
name. This automatic updating only works when the corresponding reverse map
domain in question is maintained in the same NameSurfer server as the forward zone.
If this is not the case, a PTR record should be added or deleted manually.
You can choose not to create the reverse map automatically by unchecking the
checkbox controlling automatic reverse map creation.
Some services do not function if the reverse lookup does not succeed. If a host needs
to access all Internet services, both the domain name and the reverse pointer need to
be configured correctly.
The root domain

The hierarchical DNS name space structure begins with the root domain. The root
domain has a null label (""). In the NameSurfer WWW user interface, the name of the
root domain is displayed and entered as a single dot ".".
Secondary name servers

A secondary name server, also known simply as a secondary, slave server or slave,
is a name server, which is authoritative for a given zone but which does not have a
manually administered copy of the zone data. Instead, it obtains the zone data by
doing zone transfers from a master server (typically the primary, but sometimes
another secondary).
The secondary name server periodically queries its master server (at intervals
specified by the SOA refresh value) to see if its zone serial number has changed.
When it detects a changed serial number, it performs a zone transfer to copy the entire
contents of the zone from the master server.

For reliability, each zone should have at least two authoritative name servers. Because
there can be only one primary name server, this is accomplished by setting up at least
one secondary name server.
Time to live
Every resource record has an associated time-to-live value or TTL, which determines
how long the data should be considered valid. A caching name server may only cache
the record for the length of time given by the TTL.
Typical TTL values are on the order of a few days. Many name servers enforce a
minimum TTL of five minutes. The default TTL value for new records is taken from
the SOA MINIMUM field.
Wildcard records
Wildcard records have a domain name whose first label (the part before the first dot)
is an asterisk "*".
The data of the wildcard record are used as default values for answering DNS queries
about any name which does not exist in the wildcard record's zone.
Wildcards are most commonly used with MX records to direct mail addressed to
nonexistent names in the zone to some specific mail server. For this to work, you
must also configure your mail server to accept mail addressed to any name inside your
domain.
For example, by creating a name *.nixu.com with some suitable MX records, it

would be possible to send mail to users at xyzzy.nixu.com , foo.bar.nixu.com, or
any other nonexistent host in the nixu.com zone.
Even if you use a wildcard MX record, you still need to add individual MX record to
the domain names of all your existing hosts (because wildcard records apply to
nonexistent names only).
Wildcards match both single-label names and multiple-labels names. For example,
both a.nixu.com and b.c.d.e.nixu.com would be matched by *.nixu.com, if they
had no specific records of their own.
Zones
A zone is separately administered part of the DNS name space.

A zone is almost, but not quite, the same thing as a domain. A zone consists of a
domain together with any subdomains that have not been delegated to name servers of
their own.
In practice, the words zone and domain are often used synonymously. In the common
case of a domain that has no delegated subdomains (or no subdomains at all), they
mean exactly the same thing.
Zone transfers
A zone transfer is the mechanism used by a secondary name server to fetch an up-to-
date copy of its zone data from the primary. A zone transfer involves transferring all
the records in the zone by means of a TCP network connection.
A secondary name server will perform a zone transfer whenever it finds that its zone
data is out of date, based on comparing the SOA serial number of its own zone data
with that of the primary.
Incremental zone transfers
An incremental zone transfer (IXFR) is a more efficient way than a normal zone
transfer to propagate changes to a zone. While a normal zone transfer involves
transferring all the records in the zone, incremental transfers only a portion of the
zone, namely the changes done to zone data since the last update. In this way, the
network traffic needed for the transfer of the updated DNS data is reduced.
Zone file and its records

Domain Name Service reads in resource records the information it needs. Resource
records reside in zone files.
The syntax of zone files
Example of a zone file:

; company.com
;
@ IN SOA machine.company.com
hostmaster.company.com. (
603011405 10800 3600 345600 86400 )
IN NS machine.company.com
IN NS ns.operator.com
IN NS ns2.operator.com
;
IN MX 0 machine.company.com.
IN MX 20 smtp.operator.com.

IN MX 30 x400.operator.com
; standard stuff
localhost IN A 127.0.0.1
;
host IN A 193.209.237.24
IN HINFO "HP" "HP-UX"
IN MX 0 anothermachine.company.com.
user-hp IN CNAME host
In the above zone file, rows beginning with a semicolon are comments.
The most frequent records of a zone file represent the following types:
SOA record: Start Of Authority, the first entry in a zone file, contains the domain
name, internet class, name of resource record, primary name server, administrator's
email address (with a dot replacing the @ sign), serial number, refresh value (in
seconds), retry value (in seconds), expiration value (in seconds) and the time-to-live
value.
NS record: an entry in the zone file indicating a name server (must be a fully qualified
domain name, FQDN) of the zone. Usually, there are several NS records per zone.
A record: IPv4 address record, indicates an IP address of the specified domain name
in a zone file. If the name is given without a dot, the name server software completes
the name with the domain name of the zone file. Used for translation from DNS
names to IP addresses.
PTR record: reverse pointer indicating the domain name that the IP address contained
in the record corresponds to. Used for translation from IP addresses to DNS names, in
other words, reverse mapping (see Chapter DNS functions below). Exists only in a
reverse network zone file.
TXT record: a record that contains comments and other information in a zone file. If
the information contains white space, the comment must be within quotes.
MX record: mail exchanger record in a zone file, indicates where the e-mail addressed
to the (users of the) host/domain in question should be sent.
CNAME record: defines additional names (aliases) for a host.
RP record: Responsible Person (e-mail address where "@" is replaced by a dot),

followed by a pointer to a text file containing more information. If followed by a dot,
no additional information is available.
HINFO record: the host information record in a zone file. Indicates the host type and
the operating system type.
In addition to these, there are several others less frequent record types, such as the
AAAA address record designed for IPv6.

More about BIND
BIND (the Berkeley Internet Name Domain software) is the reference implementation
of DNS, originally developed by Paul Vixie. Most Unix operating systems contain a
BIND version, and BIND for Windows exists as well. BIND source code is freely
distributed (at ftp.isc.org ). BIND 4 is giving way to the newer versions: BIND 8,
which is already widely used, and the IPv6-compatible BIND 9, which is emerging.
The benefits of the newer versions include enhanced safety against attacks.
BIND directories and files

BIND keeps its files in a directory of its own. Usually, BIND files are placed in a
directory called /etc/namedb on the system.
The BIND configuration file is called named.conf. (For BIND 4, the configuration
file is called named.boot.) This file includes configuration options for BIND. It also
specifies for which zones BIND is primary (master), and for which zones BIND is
secondary (slave - see subchapter Secondary name servers).
Configuring BIND
The Unix name server process is named. The named of BIND reads the
/etc/named.boot (BIND 4) or /etc/named.conf (BIND 8 and 9) file at startup. In
this file, the following things must be defined:
• the zones for which this host is primary

• the zones for which this host is secondary and the location of the primary host
• the location of the list of root name servers.
The following things may be defined as well:
• the directory containing the zone files

• the name server to which queries are forwarded instead of the normal
operation.
A typical /etc/named/boot file using BIND 4 might look as follows:
; named.boot -- Name server boot file

;
;
directory /usr/local/adm/named
cache .
;
primary company.com company.com
primary foo.com foo.com
;
primary 118.197.194.in-addr.arpa 118.197.194

primary 137.209.193.in-addr.arpa 137.209.193
;
secondary test.com 1.2.3.4 1.2.3.5 test.com
Running BIND
The named process is usually started at the machine startup, when it reads the
/etc/named.boot file and the files configured in it. named usually receives queries at
UDP (User Datagram Protocol) port 53. Zone transfers (see Concepts) are performed
with TCP from port 53. There is a specific named-xfer program responsible for them.
The BIND logs go via the syslog program - see /etc/syslog.conf . BIND is
usually run with administrator rights. If data is changed, named is asked to re-read the
files.

Standard Resource Records
Below, standard resource records are described.
A records
A (Address) records define the IP addresses of hosts and other network devices.
The IP addresses are entered in the usual dotted quad notation, for example,
192.168.1.2.
Most hosts have a single IP address and therefore a single A record.
Routers (or hosts acting as routers) have multiple IP addresses, and are commonly
given more than one A record. Alternatively, each interface of the router can be given
a name of its own, each with one A record.
Nixu NameSurfer can be set up to allocate IP addresses automatically when new hosts
are added to the DNS.
By default, whenever an A record is added or deleted, Nixu NameSurfer will

automatically attempt to add or delete the corresponding reverse mapping. You can
choose not to create the reverse map automatically by unchecking the checkbox
controlling automatic reverse map creation.
AAAA records
AAAA (IPv6 address) records define the IPv6 addresses of hosts and other network
devices that use the IPv6 protocol.
The addresses may be entered in any of the formats defined in RFC1884. For
example, 1080:0:0:0:8:800:200C:417A is a valid IPv6 address.
Unlike the case of IPv4 A records and IPv6 A6 records, Nixu NameSurfer does not
allocate IPv6 addresses automatically, nor does it automatically update their reverse
mappings.
A6 records
A6 (IPv6 Address with aggregation and renumbering support) records define the
IP addresses part of hosts and other network devices.
The IPv6 addresses are entered in the form prefix_len suffix prefix_name ,
where

prefix_len is prefix length - decimal number between 0 and 128 inclusive,
suffix is address suffix in RFC 2373 form,
prefix_name is a prefix name if prefix length is not zero.
Example: 28 0:0001:CA00:: C.ISP.NET.. Most hosts have a single IPv6 address
and therefore a single A6 record.
Routers (or hosts acting as routers) have multiple IPv6 addresses, and are commonly
given more than one A6 record. Alternatively, each interface of the router can be
given a name of its own, each with one A6 record.
By default, whenever an A record is added or deleted, Nixu NameSurfer will

automatically attempt to add or delete the corresponding reverse mapping. You can
choose not to create the reverse map automatically by unchecking the checkbox
controlling automatic reverse map creation.
CNAME records
A domain name with a CNAME (Canonical Name) record acts as an alias to
another domain name, the canonical name.
Because the canonical name and its alias can belong to different zones, the CNAME
record must always be entered as a fully qualified domain name. Nixu NameSurfer
checks that the canonical name really is an existing domain name, and issues a
warning if the name does not exist.
CNAME records are useful for setting up logical names for network services so that
they can be easily relocated to a different physical host. For example, it is common to
define www.company.com as an alias for the machine running the company's WWW
server.
The DNS protocol places a number of restrictions on the use of CNAME records:
• A name with a CNAME record may not have any other records.
• Other records that "point" to domain names, such as NS, MX and PTR
records, may not point to an alias. Instead, they should point directly to the
canonical name.
DNAME records
A domain name with a DNAME (Non-Terminal DNS Name Redirection) record
acts as an alias to an entire DNS subtree (as opposed to CNAME alias which acts like
a single host alias).
Because the domain name and the DNS subtree it refers to can belong to different
zones, the DNAME record must always be entered as a fully qualified domain name.
Nixu NameSurfer checks that the subtree really is an existing domain name, and
issues a warning if the name does not exist.

DNAME records are useful in conjunction with IPv6 A6 resource record and binary
labels. It is supposed that all the delegations made for IPv6 reverse maps are made
using DNAMEs. For example, if ISP A.NET delegates part of its reverse map to the
client X.EXAMPLE, it does it using this resource record: \[x11/8].IP6.A.NET
DNAME IP6.X.EXAMPLE.
The DNS protocol places a number of restrictions on the use of DNAME records:
• A name with a DNAME record may have other records (except CNAME or
other DNAME).
• There should be no other records in the same zone which are descendants of
that name.
• It should have no other records that "point" to domain names, such as NS,
CNAME A6 and PTR.
Nixu NameSurfer checks these restrictions and does not allow creation of resource
records, which break this rule.
HINFO records
The HINFO (Host INFOrmation) record can be used to identify the CPU type and
operating system of a host.
Your installation of Nixu NameSurfer may have been set up to display a selector box
with predefined HINFO alternatives. In the selector, the CPU type and OS are shown
as two text strings separated by a slash. In this case, you can simply select one of the
predefined alternatives, or if none of the alternatives is acceptable, select [Define
new] and press the OK submit button. You will then be prompted for the CPU and
operating system type.
If there are no predefined HINFO alternatives, HINFO records are entered using a
pair of entry fields, one for the CPU type and one for the operating system.
LOC records
LOC records can be used to attach geographical locations to domain names.
Location is specified in terms of latitude, longitude, altitude, size and precision.
Nixu NameSurfer displays LOC records as a single-line text representation as

specified in RFC1876. Example: LOC 42 20 32 N 71 05 19 W 10m 1000m.
MX records
MX (Mail eXchanger) records define where e-mail addressed to a given domain
name gets delivered.

MX records make it possible to deliver e-mail addressed to hosts that do not
themselves run mail software, to hosts that are not connected to the network (and
therefore lack A records), or even to mail addresses that do not correspond to any
physical machine at all.
The MX records of a host should list one or more "mail exchanger" (MX) hosts that
are willing to receive mail on behalf of that host.
with predefined MX alternatives. In this case, you can define all the MX records of a
domain name at once, simply by selecting an entry in the selector box. Each selector
entry lists the mail exchangers as a comma-separated list, in order from most
preferred to least preferred.
If none of the alternatives is acceptable, select [Define new] and hit the OK submit
button. You will then be prompted for the names of your desired mail exchanger
hosts.
If there are no predefined MX alternatives, MX records are entered using a set of text
entry fields. Each field should contain the name of one mail exchanger, in order from
most preferred to least preferred. If there are more entry fields than mail exchanger
hosts, the leftover fields should be left blank.
The first (most preferred) mail exchanger host should be the one where the final
delivery of mail will take place (in other words, the server machine containing the
users' mailboxes). The other MXs will be used only as backups in the case when the
most preferred MX is not responding. Typically, these "fallback MXs" will simply
store the mail temporarily and re-send it to the most preferred MX when it comes
back to life.
Each mail exchanger is accompanied by a preference value. This preference value

should be a positive integer and indicates the mail exchanger's priority. The most
preferred mail exchanger should have the lowest preference value.
It is recommended that you define MX records for all your hosts. If you do this, you
should also make sure that the mail server listed in your first MX record is correctly
configured to accept mail addressed to other machines.
Nixu NameSurfer checks that the mail exchange really is an existing domain name,
and issues a warning if the name does not exist.
NS records

NS (Name Server) records are used to define a set of authoritative name servers for
a zone. These are the servers that will be consulted by "outside" resolvers and non-
authoritative name servers that want to look up information inside the zone.
There are two copies of the NS records for each zone: one in the root node of the zone
itself, and another at the point of delegation in the parent zone. These two copies must
be kept synchronized manually. Whenever changes are made to the NS records of a
zone, the administrator of the parent domain should be notified for making the
corresponding changes at the delegation point, too.
PTR records
A PTR (Pointer) record serves as a pointer to a different place in the DNS
namespace. PTR records are used in the IN-ADDR.ARPA domain to define reverse
mappings. They are not commonly used in other domains.
Because a PTR record points to a different zone from the one it resides in, it must be
entered as a fully qualified domain name.
RP records
The RP (Responsible Person) record can be used to identify the person responsible
for a given name in the DNS. For example, it may be used to identify the person
responsible for the operation of a given host, or the administrator of a subdomain.
The use of RP records is optional.
The RP record consists of two fields. The first field contains the e-mail address of the
responsible person. Nixu NameSurfer displays this address in the usual Internet
user@dom.ain format.
The second field may optionally be used to specify the location of additional, free-
format textual information about the responsible person. If used, it should contain a
domain name under which the additional information is stored in the form of one or
more TXT records. This domain name and its TXT records must to be created
separately (using the "Add: [Comment]" link on the zone page). If there is no need for
additional information, the field should contain the root domain ".". This is given as
the default.
In places where the space available for display of RP data is limited, such as the zone
page, Nixu NameSurfer displays only the first (e-mail) field.
The RP record itself is entered on the node page of the domain name whose
responsible person is being defined.
with predefined RP alternatives. In this case, you can simply select one of the

predefined alternatives, or if none of the alternatives is acceptable, select [Define
new] and hit the OK submit button. You will then be prompted for the required
information.
If there are no predefined RP alternatives, RP records are entered using a pair of text
fields, one for the e-mail address and another for the domain name with TXT records.
The SOA record

The SOA (Start Of Authority) record marks the top node of a zone. Each zone has
exactly one SOA record.
The SOA record contains various administrative information which applies to the
zone as a whole. It consists of the following fields (the names in parentheses are the
standard field names as defined in RFC1035):
Master NS (MNAME)
The full domain name of the name server where the master copy of the zone
data is maintained. If the zone is maintained using Nixu NameSurfer, this field
should contain the name of the host running the Nixu NameSurfer primary
name server.
Admin e-mail (RNAME)
The e-mail address of the administrator responsible for this zone. This must be
an Internet-style e-mail address (user@dom.ain ).
Serial # (SERIAL)
The current serial number for the zone. The serial number is used by
secondary name servers to determine whether there have been recent changes
to the zone data. The serial number is updated automatically by Nixu
NameSurfer, so there should be no need to change it by hand.
Refresh (REFRESH)
This field determines how often the secondary name servers will check the
zone for changes. The default value is 8 hours, as recommended in RFC1537.
Retry (RETRY)
If a secondary name server fails to contact its primary, it will try again after
this interval. The interval is typically a small fraction of the Refresh time, but
it should be at least an hour. The default value is 2 hours, as recommended in
RFC1537.
Expire (EXPIRE)
If a secondary name server is unable to contact its primary, it may still
continue to answer queries using the last data it was able to obtain. When it
has been unable to contact the primary the length of time given by the Expire
value, the data will expire, and the secondary name server will no longer
answer queries. The default value is 7 days, as recommended in RFC1537.
Minimum TTL (MINIMUM)
This is the minimum time-to-live (TTL) value for all the DNS data in the
zone. It also serves as a default TTL value when new records are added. The
initial default value is 1 day, as recommended in RFC1537.

SRV records
The SRV (Location of Service) resource record type can be used to to specify the
location of the servers for a specific protocol and domain name.
The domain name specifies the protocol and it is of the form _Service._Proto,
where Service is the service name, for example http, and Proto is the protocol
name, for example tcp or udp.
Resource record contents are specified as a list of whitespace-separated words:
• Priority is an unsigned integer in a range 0-65535. Smaller number stands for

higher priority. The client will always be directed to the server with the
smallest priority if one of the servers is available.
• Weight is an unsigned integer in a range 0-65535. This number specifies the
probability of this service being selected. If you have only one server for this
service it is recommended to specify weight as 0. Otherwise the probability of
a particular server being selected is proportional to the weight, which means
that a server with low weight will be selected rarely and a zero-weight server
has a very small chance of being selected.
• Port number is the number of the target port of this service.
• Target is a domain name of the service target host. Target name "." signals
that the service is not available at this domain.
For example, you can specify two web servers for a domain. In this case, the RR
name could be _http._tcp and the resource records could be
0 1 80 old-slow-machine.example.com
0 3 80 new-fast-machine.example.com
1 0 80 backup-machine.example.com
If either old-slow-machine or new-fast-machine is available, web clients will
access these machines and the faster machine is supposed to be 3 times more heavily
loaded than the old one. If both are down, clients are directed to backup machine.
Records such as
*._udp SRV 0 0 0 .
specify that no UDP-based services are available.
The functionality of this DNS feature depends very much on the client’s software. If
the client does not support SRV records, the priority and load balancing mechanism
will not function.
TXT records
TXT records can be used to attach arbitrary text strings to domain names. They can
be used for site-specific purposes, such as free-format comments for documenting the
location of a host, or the postal address of the organization the domain belongs to.

There are other record types (such as for HINFO and RP records) that may be used for
similar purposes and which may be more appropriate than TXT records when the
information to be documented is more structured than a free-format comment. Nixu
NameSurfer displays TXT records as a multi-line text area. Each line corresponds to a
separate TXT record. Because the DNS does not preserve the order of records, you
should not rely on the lines being displayed in a particular order.
WKS records
The WKS (Well Known Services) resource record type can be used to list the
services provided by a host.
It is entered as a list of whitespace-separated words:
• The host's IP address

• An IP protocol type, typically TCP or UDP
• A list of port numbers or mnemonics for the services provided. The
mnemonics are defined in RFC1010.
For example, a host with the IP address 10.0.0.1, providing Telnet and SSH services
over TCP, might have the WKS record 10.0.0.1 TCP TELNET 22 (where 22 is the
port number of the SSH protocol).
The WKS record is widely considered to be obsolete. Although the WKS record type
itself is not officially deprecated, RFC1123 states that applications "should not" rely
on its existence.
There is not much point in maintaining a record that should not be used, so unless you
have a specific need to maintain WKS records in your domain, we recommend you
simply remove any WKS records you have by erasing the WKS text field and
pressing the "OK" button.

Administration of DNS
Below, some aspects of DNS administration are introduced.
Resolver configuration
For the name service to work in a network, the hosts in the network need to be
configured to use the name servers. That involves configuring the resolvers (see
chapter More concepts) of those hosts - some host names may need to be converted
into domain names. The conversion procedure varies from system to system.
At least the following aspects in a resolver need to be configured: the local domain
name, the search list, and the name server(s) that the resolver queries. The file
concerned is /etc/resolv.conf in Unix. Windows does not have an editable
resolver configuration file but search domains can be set in it.
The behavior of the resolver is controlled by directives. The main directives of

resolv.conf are domain, search, nameserver, sortlist, and options.
DHCP (Dynamic Host Configuration Protocol) is a TCP/IP protocol that assigns PCs
and workstations temporary or permanent IP addresses (out of a pool) from centrally
administered servers. Very useful with IPv4, may become unnecessary with IPv6.
Domain name searches
There are a couple of standard Unix tools for the searches of the names to be
maintained: nslookup , dig, and host.
nslookup
nslookup comes with BIND and is widely used but has some shortcomings, which is
why it is not popular with BIND 9. It functions much like a resolver does, querying
name servers to be located. It can be run either interactively or noninteractively. For
details, please refer to the nslookup manual pages in Unix.
Example:
$ nslookup -q=mx nixu.fi

Server: ns-master.nixu.fi
Address: 194.197.118.11
nixu.fi preference = 10, mail exchanger = mail-gw.nixu.fi

nixu.fi nameserver = ns2.tele.fi
nixu.fi nameserver = ns.nixu.fi
nixu.fi nameserver = ns.tele.fi
mail-gw.nixu.fi internet address = 193.209.237.25
ns.nixu.fi internet address = 193.209.237.29

ns.tele.fi internet address = 193.210.19.19
ns.tele.fi internet address = 193.210.18.18
ns2.tele.fi internet address = 193.210.19.190
For Windows, several NSLOOKUP tools exist.
dig
Another tool is dig which also comes with all BIND versions since 4.9.7. Its syntax is
dig @name.ser.ver host.na.me rr. It is easier to use than nslookup and gives
much more output for BIND 8 and BIND 9.
Example:
$ dig nixu.fi mx
; <<>> DiG 8.3 <<>> nixu.fi mx

;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL:
5
;; QUERY SECTION:
;; nixu.fi, type = MX, class = IN
;; ANSWER SECTION:
nixu.fi. 1H IN MX 10 mail-gw.nixu.fi.
;; AUTHORITY SECTION:
nixu.fi. 1H IN NS ns2.tele.fi.
nixu.fi. 1H IN NS ns.nixu.fi.
nixu.fi. 1H IN NS ns.tele.fi.
;; ADDITIONAL SECTION:
mail-gw.nixu.fi. 1H IN A 193.209.237.25
ns.nixu.fi. 1H IN A 193.209.237.29
ns.tele.fi. 6m51s IN A 193.210.19.19
ns.tele.fi. 6m51s IN A 193.210.18.18
ns2.tele.fi. 22m28s IN A 193.210.19.190
;; Total query time: 12 msec

;; FROM: kama.nixu.fi to SERVER: default -- 194.197.118.11
;; WHEN: Fri Apr 26 14:21:49 2002
;; MSG SIZE sent: 25 rcvd: 186
host
A version of host for Unix is available via anonymous FTP from ftp.nikhef.nl as
/pub/network/host.tar.Z. It should be extracted by giving
% zcat host.tar.Z | tar -xvf -
and built with
% make

host is used to check delegation, that is, looking up the NS records for a zone on the
parent zone's name servers.
Example:
$ host -t mx nixu.fi
nixu.fi mail is handled (pri=10) by mail-gw.nixu.fi

Troubleshooting DNS
Below, some problematic situations possible in DNS usage are introduced with
suggested remedy methods.
The most common errors in the zone data

Error: NS and/or MX records point to a CNAME record.
Remedy: Make them point to a canonical name.
Error: End-dot is missing in a FQDN.

Remedy: Add the end-dot in the FQDN.
Error: SOA timers are not smart.

Remedy: Give suitable values to the timers.
Error: CNAME records contain data of other (e.g. MX) records.

Remedy: Move the data to the appropriate record.
Error: The SOA name server and/or the admin e-mail address point(s) to an invalid
address.
Remedy: Correct the address(es).
Only syntax errors are reported in syslogs, whereas most of the common errors are
semantic. For more information on the subject, see RFC 1912 (http://www.cis.ohio-
state.edu/cgi-bin/rfc/rfc1912.html).
Troubleshooting a name server

Some of the below situations are not relevant to the ordinary DNS user but a DNS
administrator should know how to handle them.
Problem: The name server cannot find any external hosts.

Remedy: Check the root cache (for example, /etc/namedb/db.root - depends on the
system). Without it, the name server cannot function correctly.
Problem: The root cache is OK. The name server still cannot find external hosts.
Remedy: Check that the UDP port 53 is not blocked in the router or in the firewall.
Also the return packets must be able to pass.
Problem: Old data is coming out from an unidentified source.

Remedy: Check the expiration values in the SOA record of the zone.

Troubleshooting secondary hosts
Problem: The secondary host cannot get any data from the primary host.
Remedy: Check that TCP port 53 is not blocked in a router or in a firewall. Normal
name service queries use UDP port 53, but zone transfers use TCP.
Problem: The secondary host got data from the primary host first, but no recent
changes are transferred.
Remedy: Check in the primary host that the SOA serial number has been incremented
and that it is larger than the serial number of the secondary host.
Problem: The SOA serial number of the primary host has been incremented but the
secondary host still cannot load data.
Remedy: Check for any syntax errors in the data. Syntax errors may cause named-xfer
to exit abnormally.

Designing a DNS environment with the
help of Nixu NameSurfer
In the implementation of DNS, the first steps are to define
§ the number of hosts that will be using the service,
§ the estimated size of DNS data in total,
§ the primary need for DNS, and
§ the limitations that the current network design sets.
Having gone through these steps, the administrator usually has a fairly good idea
about the architecture suitable for the network. Below, we will go through the setup
calculations.
External vs. internal DNS

There are three varieties of the DNS concept: DNS for internal use, DNS for external
(usually ISP environments) use and a mixture of these.
1. Internal DNS is usually a company’s own DNS resolution service, used

between hosts and servers within the company network. In this type of DNS,
private IP addresses, 10.0.0.0, 192.168.0.0 or similar, can be used. DNS can
also be implemented totally using the Windows Name Service. (This
document assumes, though, that Windows name service is NOT the primary
name service.)
2. External DNS is meant to be available to the Internet, so the hosts and IP
addresses are public. This type of installation is usually either a large
company’s public DNS version, or an ISP’s DNS database consisting of their
customers’ DNS. The implementation of the installation usually depends on
the case-specific area and volume. Very heavily loaded DNS servers should be
distributed, for example, geographically.
3. Mixed DNS can be implemented in two ways: either all data is public and is
used both internally and externally, or DNS Views can be implemented.
NameSurfer DNS Views enables the coexistence of two versions of one zone.
The version given to the client depends on its IP address in the NameSurfer
environment.
Number of clients vs. number of servers in the

internal DNS
In a normal IP-based network, every node in the network uses DNS for name
resolution. The number of nodes in the network equals the number of nodes using the
DNS service, and the total number of DNS servers depends on this number. For
example, a network with only one class C of hosts (256 pieces) should need no more
than two DNS servers. At the same time, two is usually the minimum – most

Registries recommend two DNS servers for every domain, as this is also a matter of
High Availability.
If a network has, for example, 10 000 nodes, name servers should be more powerful
and one or two extra servers would be good to have.
Using DHCP, it is fairly easy to divide a large network and make half of the hosts use
the DNS servers 1 and 2, and the rest use the DNS servers 3 and 4.
Some very large DNS environments, for example, a worldwide corporation, could
also split their DNS for maximal reliability, manageability and performance. For
example, Europe.company.tld (tld = top level domain) could be one DNS tree and
Americas.company.tld could be another one. Both trees would be independent and
they would have separate Masters and Secondaries.
Figure 3 shows an example of a split DNS structure. NOTE: This network

architecture also works as load balancer for an external DNS.
Figure 3: Split DNS Structure

Number of servers in the external DNS
In ISP environments, DNS service is usually one the most important services to keep
up and running. The system is usually made fault-tolerant by cloning the DNS
servers.
Figure 4 shows the usual ISP DNS configuration:
Figure 4: The Usual ISP DNS Configuration
Number of servers in the mixed DNS

A mixed DNS environment can use either one of the previous two architectures,
depending on its use. There are also two new design options to choose from:
1. NameSurfer DNS Views

2. Two separate environments.
NameSurfer DNS Views (see chapter External vs. internal DNS) is defined in Nixu
NameSurfer and requires at least two BIND servers: one for internal DNS and another
for external DNS. Depending on which BIND makes the zone transfer, Nixu
NameSurfer returns one of the two zone versions.
The diagram below shows the basic structure of NameSurfer DNS Views:
Figure 5: NameSurfer DNS Views
If NameSurfer DNS Views cannot be used, a mixed environment can be created by

grouping all external hosts under a certain domain name and by placing the
secondaries in the external network. Internal hosts are under a different domain name,
which has separate DNS servers. For example, company.com is the external domain
name containing all public DNS data, and internal.company.com is another domain
used internally, and is not visible to the outside world.

The size of zones
If the total number of RRs exceeds 200-300 kRR, it might be reasonable to split the
zone into smaller zones, to avoid delays and problems during updates and transfers
and to make administration easier.
Adding a DHCP DynDNS feature to the DNS

environment
With Nixu NameSurfer, ISC DHCPD is delivered. It supports standard dynamic DNS
updates (see RFC2136) with or without TSIG keys. DHCPD performs dynamic DNS
updates to Nixu NameSurfer via BIND secondaries, not directly. The use of DHCPD
in DNS updates is, above all, a security issue – if clients make their own DNS updates
and access is not restricted, someone might erase all DNS data either accidentally or
on purpose.
How to make a DNS environment reliable and

fault-tolerant
DNS itself is a fault-tolerant system since every DNS data entry is available at least
on two separate servers. Therefore, only a network outage breaks the whole DNS. As
a safeguard against network outages, it is recommended to allocate DNS servers to
different segments and make sure they have several routes to the Internet. Secondary
servers can also be made fault-tolerant using a front-end clustering component, which
also offers load balancing. For the clustering software, Nixu recommends StoneSoft
WebCluster.
For the whole DNS system to be reliable, even the Master DNS server should be
replicated so that not only queries but also modifications are possible always. Nixu
NameSurfer offers one option for this: the HA module. It is based on replicating the
Primary NameSurfer server and using the Solid High Availability option on
databases. Figure 6 (below) shows the logical structure of HA-environment.
For more information on High Availability, please refer to the NameSurfer

homepages at: http://www.nixu.com/products/namesurfer/download/.

Figure 6: Hot StandBy

Best Practices (a mini-Howto)
This chapter describes some usual situation administrators face in their everyday life
with DNS and NameSurfer. This is not meant as a strict manual but more like
“recommended solutions”.
Q: I want to change the ip address of my NameSurfer Primary Server, what must be

considered? What is the easiest solution?
A: Changing the ip-address of the master server is pretty easy, but you must take care
of the servers and services pointing to the old ip-address. Here are the steps:
• First you change the physical ip-address in the Master Server OS

• Then you go through the Configuration files server.conf, shellui.conf and
webui.conf and change the primary_addr value. Restart NameSurfer.
• Also check that the DNS-name for the Master server resolves to the new ip-
address for correct notifications etc.
• For each Secondary pointing to this Master, change master ip-address value
• For secondaries managed by NameSurfer using Remote Secondary function
the best way is to remove the REMSEC-records from each zone and re-add
them. This procedure uses the new value when re-adding the zone-lines into
secondaries’ configuration.
• If the amount of zones is very high, manual delete/add of REMSEC records
takes time so Bulk Changes can be used, in 5.2.1 and later versions changes
can be limited to only Zone Root records such as REMSEC
• For other Secondaries, go through configuration manually and change the
master ip-address
Q: I want my Secondaries to use BIND running on the Master server as their Master
server rather than quering Namesurfer Primary Server directly, how do I configure
this?
A: You should configure the local BIND on Master server to be Secondary for each
zone. After this works, configure each secondary to use port 53 instead of 8054 for
the master server. If the secondaries are managed by NameSurfer, this configuration
option can be made permanent in BIND Configuration / <secondary name> /
Configuration Preferences / “Default Master Port”.
Q: I want my AD-network or other DDNS-environment to be able to make DynDNS-

updates to NameSurfer but I have BIND servers between the client and NameSurfer.
How do I get the updates to NameSurfer?
A: AD-Clients send their updates to the hostname written in MNAME-field of that

Zone client belongs to. They cannot send their updates to other ports than 53 so a
forwarder must be used. Here are the steps needed:
• Enable NameSurfer to accept insecure DDNS-updates by writing “true” into
server.conf configuration file option allow_insecure_updates. Enter the ip-
address range to allow_insecure_updates_from field.
• Restart NameSurfer, you may test DDNS-updates with a test-client or
nsupdate
• Edit the configuration file of the NameServer mentioned in MNAME of AD-
network, for example ns.dc.company.tld.
• For zone dc.company.tld add this configuration
• allow-update-forwarding { ip-range_for_clients; };
• Restart BIND, test the DDNS-update, check logs for errors.
Q: I want to use NameSurfer DNS Views functionality to split a zone I have to

different customers / networks, what must I do?
A: First create the DNS Views in NameSurfer UI and assign ip-address ranges for
them matching the clients they might have. Clients not matching to either will receive
a copy of zone in default-view if it exists. Then go inside the zone you need to have
two versions, and make a copy of it using “copy zone” to the other view. (or views).
Then edit the REMSEC-records, zone root records, possibly NS-records also so that
each secondary points to correct version and gets notified of the right changes. Check
that each secondary get a right version, and you’re finished.
Q: I want to use TSIG keys to make secure DDNS-updates to NameSurfer Primary,

what must I do?
A: NameSurfer accepts TSIG-signed DDNS-updates by default, you just need to add

the key you are using to NameSurfer Database. This key must have the same type,
name and value as the updater has. The key must also have the “can be used for
dynamic DNS updates” checkbox selected. After this, everyone having this key can
make any DNS changes to NameSurfer. The key can also be limited to certain zones
or views if needed!
Glossary
For the definition of the main DNS concepts, please see chapter DNS Concepts in this
document.
absolute domain name: A domain name not relative to any other domain, only to the
root. Specifies a node's location in the hierarchy unambiguously. Also called as Fully
Qualified Domain Name. Should technically end in a dot. Maximum length: 254
characters.
alias: One host can have several names, aliases. The aliases cannot have resource
records other than the canonical name of the file has.
A record: Address record, indicates the IP address of the specified domain name in a
zone file. If without a dot in the end, the name server software completes the name
with the domain name of the zone file. Length: 32 bits.

A6 record: The official IPv6 address record supported by BIND from version 9.0.0
onwards. See Nixu NameSurfer help or RFC 2874.
AAAA record (pronounced "quad A"): The early IPv6 address record, 128 bits (see
Nixu NameSurfer help or RFCs 1884 and 1886).
ARIN: American Registry for Internet Numbers, takes care of the administration of
the IP address space
canonical name: The original name of a host, to which aliases point.
CIDR (Classless Interdomain Routing): If CIDR is applied, instead of a set number

of octets, any number of initial contiguous bits in an IP address can be used as
network identifier in IPv4(?). The number of network-identifying bits in an address is
indicated after a slash.
client: A machine that asks a server to perform tasks for it.
CNAME: The resource record type defining aliases.
DHCP (Dynamic Host Configuration Protocol): A TCP/IP protocol that assigns

PCs and workstations temporary or permanent IP addresses (out of a pool) from
centrally administered servers. Replaced Bootp.
dig: A troubleshooting tool for sending DNS queries and printing the results of a
query. See chapter Domain name searches.
DNAME record: The official IPv6 reverse mapping address record supported by
BIND from version 9.0.0 onwards. See RFC 2672.
domain: Subtree of a the naming tree, a group of hosts whose domain names are
within the domain (can be an individual host as well). Each domain can be
administered by a different organization. Domains can be divided into subdomains.
domain name: Identifies the position of a domain in the name space, a sequence of
labels from the domain to the root (.), separated by dots. Each domain has a domain
name which is unique within the same parent domain. The domain name equals with
the name of the top node of the domain. A domain name actually represents a network
address, hardware information, and mail routing information.
domain name space: Hierarchical construction of domain names with the root on the
top of it. Below the root, is its child, the top level, whose child in turn is the first level,
parent to the second level and so on.
HINFO record: The host information record in a zone file. Indicates the host type
and the operating system type.
host: A computer or any other network device where services or clients reside - thus,
it has an IP address.

IETF (Internet Engineering Task Force): An organization open to anyone
interested in the Internet. Among other things, the organization's home page at
http://www.ietf.org/ includes a link to RFCs.
InterNIC (Internet Network Information Center): The organization that used to

handle the primary name service for the root domain and to register domains under
the international top-level domains, which now is the responsibility of ICANN
(Internet Corporation for Assigned Names and Numbers).
ip6.int: Reverse mapping name space for IPv6 addresses (see RFC 1886).
IPv4: Internet Protocol version 4, or TCP/IP, still currently the prevalent version of
the Internet Protocol, with 32-bit-long addresses in dotted-octet format
(xxx.xxx.xxx.xxx).
IPv6: Internet Protocol version 6, 128-bit addressing. An IPv6 address consists of

eight sets of hexadecimal digits, four digits in each, separated by semicolons
(xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx). The initial zeros of each group of four
can be left out, though, and unbroken sequences of zeros can be marked as "::". For
details, please see RFC 1752.
iterative query: In an iterative query, a name server gives the best answer it has to
the querier and does not query further from other name servers.
label: A name corresponding to a level (node) in the domain hierarchy. Labels are
separated by dots in a domain name and their maximum length is 63 characters.
Formally, there is no limit as to the number of labels in a name.
MX record: Mail exchanger record in a zone file, indicates where the e-mail
addressed to a user at the host/domain in question should be sent.
name server: A program containing information about a segment of the domain name
space and making it available to clients (resolvers). Receives queries from resolvers
and from other name servers in the world and answers them on the basis of the
contents of its database (authoritative reply) and cache (non-authoritative reply). If it
has no information on the queried name, it asks another name server. Needs the
correct list of root name servers. Roles: primary master - secondary master (slave) -
caching only - recursive. Any server can have any combination of these roles.
name space: The tree-like structure resembling a file system architecture where
'parent' directories are divided into 'children' and where 'siblings' in the same 'family'
must all have different names.
NLA (Next-Level Aggregator): A network that connects site network(s) to an IPv6

internet.
node: The hierarchical top of a domain, or a subtree of the domain name space.
NS record: An entry in the zone file that indicates a name server (must be a FQDN)
of the zone.

nslookup: A name server utility program, shipped with the BIND code. The only tool
available for a standard Window installation. Being replaced by other programs (dig,
host).
port: The logical interface between a process or program and a communications or

transmissions facility.
PTR record: Reverse pointer indicating the domain name that the IP address
contained in the record corresponds to. Used only in a reverse network zone file.
recursive query: The name server receiving a recursive query may not refer the
querier to another name server but must provide an answer to the query itself,
possibly by forwarding the query to other name servers.
registry: An organization responsible for the maintenance of the data files of a top-
level domain.
resolver: Often a library routine that accepts name server requests from client
programs and checks whether it has the requested information in its own cache. If not,
it creates queries and sends them across a network to a name server. Every networked
host must have a resolver. The default name server(s) must be configured to the host's
TCP/IP software. In the Unix system, the configuration file is /etc/resolv.conf.
reverse (inverse) query/lookup: Translation from an IP address into a domain name.
RFC: Request For Comments, technical and organizational notes or memos about the
Internet published in the Internet standards process. For a list of RFCs, see
http://www.ietf.org/rfc.html.
RIPE: Réseaux IP Européens, administration of IP addresses in Europe.
root name server: A name server with the knowledge about the whereabouts of the
authoritative name servers of each of the top-level zones. 13 root name servers exist
globally.
RP record: Responsible Person (e-mail address), followed by a pointer to a text file

containing more information. If followed by a dot, no additional information is
available.
SLA (Site-Level Aggregator): IPv6 bits that correspond to the subnet bits of IPv4
and designate the subnet level in an IP address.
SOA record: Start Of Authority, the first entry in a zone file, contains the domain
name, internet class, name of resource record, the name of the primary name server,
administrator's e-mail address (with a dot replacing the @ sign), serial number,
refresh value (in seconds), retry value (in seconds), expiration value (in seconds) and
the time-to-live value.
syslog: The log system of Unix operating system.

TCP: Transmission Control Protocol, provides delivery of bytes to a remote or local
user.
TLA (Top-Level Aggregator): At the core of an IPv6 internet, "networks that

connect directly to the backbone of the internet and provide connectivity to Next-
Level Aggregators". (Albitz & Liu, 2001)
TSIG: Transaction Signature, authentication method for DNS messages. To the

message to be sent, a TSIG record is added. This record contains a secret (hash value)
shared with the receiver of the message. For a complete specification, please see RFC
2845.
TXT record: A record that contains comments and other information in a zone file.
UDP: User Datagram Protocol, provides delivery of data between hosts without
confirmation (thus, not fully reliable).

DNS Guide For Network Professionals

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

DNS Guide For Network Professionals

Enviado por

Direitos autorais:

Formatos disponíveis

DNS Guide for Network

© Nixu Software Limited 2006. All Rights Reserved. 2

© Nixu Software Limited 2006. All Rights Reserved. 3

For additional reading, we recommend two books:

Additional information is also available in the Nixu NameSurfer Reference Manual.

© Nixu Software Limited 2006. All Rights Reserved. 4

Figure 1: DNS Architecture

© Nixu Software Limited 2006. All Rights Reserved. 5

Figure 2: Name Resolution

© Nixu Software Limited 2006. All Rights Reserved. 6

As Nixu NameSurfer is a dedicated primary name server, it relies on one or more

© Nixu Software Limited 2006. All Rights Reserved. 7

Domains and domain names

Top level domains

© Nixu Software Limited 2006. All Rights Reserved. 8

Originally, labels were meant for international use as follows:

• .com for commercial organizations

The following labels are reserved for the US Government:

• .gov for the US Government

• .uk for the United Kingdom

National top-level domains are adminstered by organizations which delegate

© Nixu Software Limited 2006. All Rights Reserved. 9

FQDN - Fully Qualified Domain Name

IDN – Internationalized Domain Names

(In Nixu NameSurfer, the choice of IDN is a matter of a configuration option.)

There are two sorts of IP addresses: IPv4 and IPv6 addresses.

© Nixu Software Limited 2006. All Rights Reserved. 10

An IPv6 address in its complete form is written in a form x:x:x:x:x:x:x:x , where

Primary name server

Nixu NameSurfer is a primary name server.

For example, finding the IP address of www.nixu.com may require up to three

© Nixu Software Limited 2006. All Rights Reserved. 11

Standard resource records are described in a separate chapter below.

© Nixu Software Limited 2006. All Rights Reserved. 12

The root domain

Secondary name servers

© Nixu Software Limited 2006. All Rights Reserved. 13

For example, by creating a name *.nixu.com with some suitable MX records, it

© Nixu Software Limited 2006. All Rights Reserved. 14

Incremental zone transfers

Zone file and its records

The syntax of zone files

Example of a zone file:

© Nixu Software Limited 2006. All Rights Reserved. 15

CNAME record: defines additional names (aliases) for a host.

RP record: Responsible Person (e-mail address where "@" is replaced by a dot),

© Nixu Software Limited 2006. All Rights Reserved. 16

BIND directories and files

• the zones for which this host is primary

The following things may be defined as well:

• the directory containing the zone files

A typical /etc/named/boot file using BIND 4 might look as follows:

; named.boot -- Name server boot file

© Nixu Software Limited 2006. All Rights Reserved. 17

© Nixu Software Limited 2006. All Rights Reserved. 18

Most hosts have a single IP address and therefore a single A record.

By default, whenever an A record is added or deleted, Nixu NameSurfer will

© Nixu Software Limited 2006. All Rights Reserved. 19

By default, whenever an A record is added or deleted, Nixu NameSurfer will

© Nixu Software Limited 2006. All Rights Reserved. 20

Nixu NameSurfer displays LOC records as a single-line text representation as

© Nixu Software Limited 2006. All Rights Reserved. 21

Each mail exchanger is accompanied by a preference value. This preference value