Solaris

DNS CONCEPTS AND IMPLEMENTATION

The domain name system is a global network of servers that translate host names likehttp://www.unixmatrix.blogspot.com/ into numerical IP (Internet Protocol) addresses, like 10.15.25.0, which computers on the Net use to communicate with each other. Without DNS, we'd all be memorizing long numbers instead of intuitive URLs or email addresses.

The domain name space

In order to understand how a DNS server works, you should be familiar with what is called the domain name space. Domain Name Space looks like this:

Fig 1.1

Each node on the tree represents a domain. Everything below a node falls into its domain. One domain can be part of another domain. For example, the machine chichi is part of the .us domain as well as the .com domain.
The Internet's Domain Name Service (DNS) is just a specific implementation of the Name Server concept optimized for the prevailing conditions on the Internet.

DNS OVERVIEW

From the history of name servers three needs emerged:
1. The need for a hierarchy of names.
2. The need to spread the operational loads on our name servers
3. The need to delegate the administration of our name servers.

DOMAINS AND DELEGATIONS

The Domain Name System uses a tree (or hierarchical) name structure. At the top of the tree is the root followed by the Top Level Domains (TLDs) then the domain-name and any number of lower levels each separated with a dot.

NOTE: The root of the tree is represented most of the time as a silent dot ('.')

Top Level Domains (TLDs) are split into two types:
1. Generic Top Level Domains (gTLD) .com, .edu, .net, .org, .mil etc.
2. Country Code Top Level Domain (ccTLD) e.g. .us, .ca, .tv , .uk etc.
Country Code TLDs (ccTLDs) use a standard two letter sequence defined by ISO 3166.
The following figure shows this:

Fig 5.2

What is commonly called a 'Domain Name' is actually a combination of a domain-name and a TLD and is written from LEFT to RIGHT with the lowest level in the hierarchy on the left and the highest level on the right.

domain-name.tld e.g. example.com

In the case of the gTLDs e.g. .com, .net etc. the user part of the delegated name - the name the user registered - is called a Second Level Domain (SLD), it is the second level in the hierarchy. The user part is frequently simply referred to as the SLD. So the Domain name in the example above can be re-defined to consist of:

sld.tld e.g. example.com

The term Second Level Domain (SLD) is much less useful with ccTLDs where the user registered part is frequently the Third Level Domain e.g.:

example.co.in

example.com.br

The term Second Level Domain (SLD) provides technical precision but can be confusing - unless the precision is required we will continue to use the generic term Domain Name or simply Domain to the whole name e.g. a Domain Name is example.com or example.co.in.

Authority and Delegation

The concepts of Delegation and Authority lie at the core of the domain name system hierarchy. The Authority for the root domain lies with Internet Corporation for Assigned Numbers and Names (ICANN). Since 1998 ICANN, a non-profit organisation, has assumed this responsibility from the US government.
The gTLDs are authoritatively administered by ICANN and delegated to a series of accredited registrars. The ccTLDs are delegated to the individual countries for administration purposes. Figure 5.2 above shows how any authority may in turn delegate to lower levels in the hierarchy, in other words it may delegate anything for which it is authoritative. Each layer in the hierarchy may delegate the authoritative control to the next lower level.

Countries with more centralized governments, like India and others, have opted for functional segmentation in their delegation models e.g. .co = company, .ac = academic etc.). Thus mycompany.co.in is the 'Domain Name' of 'mycompany' registered as a company from the UK registration authority.
By reading a domain name from RIGHT to LEFT you can track its delegation. This unit of delegation is usually referred to as a 'zone' in standards documentation.

DNS ORGANISATION AND STRUCTURE

The Internet's DNS exactly maps the 'Domain Name' delegation structure described above. There is a DNS server running at each level in the delegated hierarchy and the responsibility for running the DNS lies with the AUTHORITATIVE control at that level.
Figure 5.3 shows this diagrammatically.

Figure 5.3 DNS mapped to Domain Delegation

The Root Servers (Root DNS) are the responsibility of ICANN but operated by a consortium under a delegation agreement. ICANN created the Root Servers Systems Advisory Committee (RSSAC) to provide advice and guidance as to the operation and development of this critical resource. The IETF was requested by the RSSAC to develop the engineering standards for operation of the Root-Servers. This request resulted in the publication of RFC 2870.
There are currently (mid 2003) 13 root-servers world-wide.

The Root-Servers are known to every public DNS server in the world.
The TLD servers (ccTLD and gTLD) are operated by a variety of agencies and registrars under a fairly complex set of agreements by Registry Operators.

The Authority and therefore the responsibility for the User (or 'Domain Name') DNS servers lie with the owner of the domain. In many cases this responsibility is delegated by the owner of the Domain to an ISP, Web Hosting Company or increasingly a registrar. Many companies, however, elect to run their own DNS servers and even delegate the Authority and responsibility for sub-domain DNS servers to separate parts of the organisation.

When any DNS cannot answer (resolve) a request for a domain name from a host e.g. example.com the query is passed to a root-server which will direct the query to the appropriate TLD DNS server which will in turn direct it to the appropriate Domain (User) DNS server.

DNS QUERIES

The major task carried out by a DNS server is to respond to queries (questions) from a local or remote resolver or other DNS acting on behalf of a resolver. A query would be something like 'what is the IP address of abc.example.com'.
A DNS server may receive such a query for any domain. DNS servers may be configured to be authoritative for some (if any) domains, slaves, caching, forwarding or many other combinations for others.
Most of the queries that a DNS server will receive will be for domains for which it has no knowledge i.e. for which it has no local zone files. The DNS software typically allows the name server to respond in different ways to queries about which it has no knowledge.
There are three types of queries defined for DNS:
1. A recursive query - the complete answer to the question is always returned. DNS servers are not required to support recursive queries.
2. An Iterative (or non-recursive) query - where the complete answer MAY be returned. AllDNS servers must support Iterative queries.
3. An Inverse query - where the user wants to know the domain name given a resource record.

Note: The process called Reverse Mapping (returns a host name given an IP address) does not use Inverse queries but instead uses Recursive and Iterative (non-recursive) queries using the special domain name IN-ADDR.ARPA. Historically reverse IP mapping was not mandatory. Many systems however now use reverse mapping for security and simple authentication schemes so proper implementation and maintenance is now practically essential.

Recursive Queries

A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries and either the resolver (or another DNS acting recursively on behalf of another resolver) negotiate use of recursive service using bits in the query headers.

There are three possible responses to a recursive query:

1.The answer to the query accompanied by any CNAME records (aliases) that may be useful. The response will indicate whether the data is authoritative or cached.
2.An error indicating the domain or host does not exist (NXDOMAIN). This response may also contain CNAME records that pointed to the non-existing host.
3.A temporary error indication - e.g. can't access other DNS's due to network error etc.
In a recursive query a DNS server will, on behalf of the client (resolver), chase the trail of DNS across the universe to get the real answer to the question. The journeys of a simple query such as 'what is the IP address of xyz.example.com' to a DNS server which supports recursive queries but is not authoritative for example.com could look something like this:

1.Resolver on a host sends query 'what is the IP address of xyz.example.com' to locally configured DNS server.
2.DNS server looks up xyz.example.com in local tables (its cache) - not found
3.DNS sends query to a root-server for the IP of xyz.example.com
4.The root-server replies with a referral to the TLD servers for .com
5.The DNS server sends query 'what is the IP address xyz.example.com' to .com TLD server.
6.The TLD server replies with a referral to the name servers for example.com
7.The DNS server sends query 'what is the IP address xyz.example.com' to name server for example.com.
8.Zone file defines a CNAME record which shows xyz is aliased to abc. DNS returns both the CNAME and the A record for abc.
9.Send response abc=x.x.x.x (with CNAME record xyz=abc) to original client resolver. Transaction complete.

Iterative (non-recursive) Queries

An Iterative (or non-recursive) query is one where the DNS server may provide a partial answer to the query (or give an error). DNS servers must support non-recursive queries.

There are four possible responses to a non-recursive query:
1.The answer to the query accompanied by any CNAME records (aliases) that may be useful. The response will indicate whether the data is authoritative or cached.
2.An error indicating the domain or host does not exist (NXDOMAIN). This response may also contain CNAME records that pointed to the non-existing host.
3.A temporary error indication - e.g. can't access other DNS's due to network error etc...
4.A referral; the name and IP address (es) or one or more name server(s) that are closer to the requested domain name. This may, or may not be, the authoritative name server for the target domain.
The journeys of a simple query such as 'what is the IP address of xyz.example.com' to a DNS server which supports Iterative (non-recursive) queries but is not authoritative for example.com could look something like this:
1.Resolver on a host sends query 'what is the IP address xyz.example.com' to locally configured DNS server.
2.DNS server looks up xyz.example.com in local tables (its cache) - not found
3.The DNS replies with a referral containing the root-servers
4.Resolver sends query to a root-server for the IP of xyz.example.com
5.The root-server replies with a referral to the TLD servers for .com
6.The Resolver sends query 'what is the IP address xyz.example.com' to .com TLD server.
7.The TLD server replies with a referral to the name servers for example.com
8.The Resolver sends query 'what is the IP address xyz.example.com' to name server for example.com.
9.Zone file defines a CNAME record which shows xyz is aliased to abc. DNS returns both the CNAME and the A record for abc.
10.Transaction complete.

Note: The above sequence is highly artificial since the resolver on Windows a most *nix systems is a stub resolver - which is defined in the standards to be a minimal resolver which cannot follow referrals. If you reconfigure your local PC or Workstation to point to a DNS server that only supports Iterative queries - it will not work.

Inverse Queries

An Inverse query maps a resource record to a domain. An example Inverse query would be 'what is the domain name for this MX record'. Inverse query support is optional and it is permitted for the DNS server to return a response Not Implemented.
Inverse queries are NOT used to find a host name given an IP address. This process is called Reverse Mapping (Look-up) uses recursive and Iterative (non-recursive) queries with the special domain name IN-ADDR.ARPA.

Zone Updates

The initial design of DNS allowed for changes to be propagated using Zone Transfer (AXFR) but the world of the Internet was simpler and more sedate in those days (1987). The desire to speed up the process of zone update propagation while minimizing resources used has resulted in a number of changes to this aspect of DNS design and implementation from simple - but effective - tinkering such as Incremental Zone Transfer (IXFR) and Notify messages to the concept of Dynamic Updates which is still not widely deployed.
Warning While zone transfers are generally essential for the operation of DNS systems they are also a source of threat. A slave DNS can become poisoned if it accepts zone updates from a malicious source. Care should be taken during configuration to ensure that, as a minimum, the 'slave' will only accept transfers from known sources.

Full Zone Update (AXFR)

The original DNS specifications (RFC 1034 & RFC 1035) envisaged that slave (or secondary) DNS servers would 'poll' the 'master'. The time between such 'polling' is determined by the REFRESH value on the domain's SOA Resource Record

The polling process is accomplished by the 'slave' sending a query to the 'master' and requesting the latest SOA record. If the SERIAL number of the record is different from the current one maintained by the 'slave' a zone transfer (AXFR) is requested. This is why it is vital to very disciplined about updating the SOA serial number every time anything changes in ANY of the zone records.
Zone transfers are always

Incremental Zone Update (IXFR)

Transferring very large zone files can take a long time and waste bandwidth and other resources. This is especially wasteful if only a single record has been changed! RFC 1995 introduced Incremental Zone Transfers (IXFR) which as the name suggests allows the 'slave' and 'master' to transfer only those records that have changed.
The process works as for AXFR. The 'slave' sends a query for the domain's SOA Resource Record every REFRESH interval. If the SERIAL value of the SOA record has changed the 'slave' requests a Zone Transfer and indicates whether or not it is capable of accepting an Incremental Transfer (IXFR). If both 'master' and 'slave' support the feature an Incremental Transfer (IXFR) takes place otherwise a Full Zone Transfer (AXFR) takes place. Incremental Zone transfers use TCP on port 53 (normal DNS queries operations use UDP on port 53).
The default mode for BIND when acting as a 'slave' is to use IXFR unless it is configured not to using the request-ixfr parameter in the server or options section of the named.conf file.
The default mode for BIND when acting as a 'master' is to use IXFR only when the zone is dynamic. The use of IXFR is controlled using the provide-ixfr parameter in the server or options section of the named.conf file.
Notify (NOTIFY)
RFC 1912 recommends a REFRESH interval of up to 12 hours on the REFRESH interval of an SOA Resource Record. This means that changes to the 'master' DNS may not be visible at the 'slave' DNS for up to 12 hours. In a dynamic environment this may be unacceptable.

RFC 1996 introduced a scheme whereby the master will send a NOTIFY message to the slaveDNS systems that a change MAY have occurred in the domain records. The 'slave' on receipt of the NOTIFY will request the latest SOA Resource Record and if the SERIAL value is different will attempt a Zone Transfer using either a full Zone Transfer (AXFR) or an Incremental Transfer (IXFR).
NOTIFY behavior in BIND is controlled by notify, also-notify and notify-source parameters in the zone or options statements of the named.conf file.

Dynamic Update

The classic method of updating Zone Resource Records is to manually edit the zone file and then stop and start the name server to propagate the changes. When the volume of changes reaches a certain level this can become operationally unacceptable - especially considering that in organizations which handle large numbers of Zone Files, such as service providers, BIND itself can take a long time to restart at it plows through very large numbers of zone statements.
The 'holy grail' of DNS is to provide a method of dynamically changing the DNS records while DNS continues to service requests.
There are two architectural approaches to solving this problem:
Allow 'run-time' updating of the Zone Records from an external source/application.
Directly feed BIND (say via one of its two APIs) from a database which can be dynamically updated.
RFC 2136 takes the first approach and defines a process where zone records can be updated from an external source. The key limitation in this specification is that a new domain cannot be added dynamically. All other records within an existing zone can be added, changed or deleted. In fact this limitation is also true for both of BIND's APIs as well.

Part of this specification the term Primary Master is coined to describe the Name Server defined in the SOA Resource Record for the zone. The significance of this term is that when dynamically updating records it is essential to update only one server even though there may be multiple master servers for the zone. In order to solve this problem a 'boss' server must be selected, this 'boss' server termed the Primary Master has no special characteristics other than it is defined as the Name Server in the SOA record and may appear in an allow-updateclause to control the update process.
While normally associated with Secure DNS features (TSIG - RFC 2845 & TKEY - RFC 2930) Dynamic DNS (DDNS) does not REQUIRE TSIG/TKEY. However there is a good reason to associate the two specifications when you consider that by enabling Dynamic DNS you are opening up the possibility of master zone file corruption or poisoning. Simple IP address protection (ACL) can be configured into BIND but this provides - at best - limited protection. For that reason serious users of Dynamic DNS will always use TSIG/TKEY procedures to authenticate incoming requests.
Dynamic Updating is defaulted to deny from all hosts. Control of Dynamic Update is provided by the BIND allow-update (usable with and without TSIG/TKEY) and update-policy (only usable with TSIG/TKEY) clauses in the zone or options statements of the named.conf file.
There are a number of Open Source tools which will initiate Dynamic DNS updates these include dnsupdate (not the same as DNSUpdate) and dnsupdate which is distributed withbind-utils.

Alternative Dynamic DNS Approaches

As noted above the major limitation in the standard Dynamic DNS (RFC 2136) approach is that new domains cannot be created dynamically.

BIND-DLZ takes a much more radical approach and using a serious patch to BIND allows replacement of all zone files with a single zone file which defines a database entry. The database support, which includes most of the major databases (MySQL, PostgreSQL, BDB and LDAP among others) allows the addition of new domains as well as changes to pre-existing domains without the need to stop and start BIND. As with all things in life there is a trade-off and performance can drop precipitously. Current work being carried (early 2004) out with a High performance Berkeley DB (BDB) is showing excellent results approaching raw BIND performance.