DNS Guide for Network Professionals[1]

DNS Guide for Network Professionals

Nixu Software Mäkelänkatu 91 FIN-00610 Helsinki Finland

© Nixu Software Limited 2006. All Rights Reserved.

2

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


3

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


4

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.


5

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


6

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).


7

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.


8

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


9

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


10

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.


11

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


12

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.


13

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.


14

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.


15

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.


16

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.


17

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


18

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.


19

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


20

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.


21

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.


22

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. Your installation of Nixu NameSurfer may have been set up to display a selector box 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


23

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 [email protected] 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. Your installation of Nixu NameSurfer may have been set up to display a selector box with predefined RP alternatives. In this case, you can simply select one of the


24

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 ([email protected]).

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.


25

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.


26

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.


27

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


28

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


29

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


30

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.


31

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.


32

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


33

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


34

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.


35

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.


36

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/.


37

Figure 6: Hot StandBy


38

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.


39

• 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.


40

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.


41

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.


42

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.


43

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).

Documents

DNS Guide for Network Professionals[1]