Skip to main content

6. Name Server Implementation

This chapter discusses implementation considerations for DNS name servers.

6.1. Architecture​

The optimal structure for the name server will depend on the host operating system and whether the name server is integrated with resolver operations, either by supporting recursive service, or by sharing its database with a resolver.

This section discusses implementation considerations for a name server which shares a database with a resolver, but most of these concerns are present in any name server.

6.1.1. Control​

A name server must employ multiple concurrent activities, whether they are implemented as separate tasks in the host's OS or multiplexing inside a single name server program.

Requirements:

  • UDP Non-Blocking: It is simply not acceptable for a name server to block the service of UDP requests while it waits for TCP data for refreshing or query activities

  • Parallel Processing: A name server should not attempt to provide recursive service without processing such requests in parallel, though it may choose to:

    • Serialize requests from a single client
    • Regard identical requests from the same client as duplicates

  • Non-Blocking Zone Operations: A name server should not substantially delay requests while it:

    • Reloads a zone from master files
    • Incorporates a newly refreshed zone into its database

6.1.2. Database​

While name server implementations are free to use any internal data structures they choose, the suggested structure consists of three major parts:

Suggested Database Structure​

1. Catalog Data Structure:

  • Lists the zones available to this server
  • Contains a "pointer" to the zone data structure
  • Main purpose: find the nearest ancestor zone, if any, for arriving standard queries

2. Zone Data Structures:

  • Separate data structures for each of the zones held by the name server
  • Contains authoritative data for the zone

3. Cache Data Structure:

  • A data structure for cached data
  • May have separate caches for different classes

Implementation Considerations​

Tree Structure: All of these data structures can be implemented in an identical tree structure format, with different data chained off the nodes in different parts:

  • In the catalog: data is pointers to zones
  • In zone and cache data structures: data will be RRs

Query Processing Requirements: When designing the tree framework, the designer should recognize that:

  • Query processing will need to traverse the tree using case-insensitive label comparisons
  • In real data, a few nodes have a very high branching factor (100-1000 or more)
  • The vast majority have a very low branching factor (0-1)

Case-Insensitive Storage Solution​

One way to solve the case problem is to store the labels for each node in two pieces:

  1. A standardized-case representation of the label where all ASCII characters are in a single case
  2. A bit mask that denotes which characters are actually of a different case

Branching Factor Optimization​

The branching factor diversity can be handled by:

  • Using a simple linked list for a node until the branching factor exceeds some threshold
  • Transitioning to a hash structure after the threshold is exceeded

Important: Hash structures used to store tree sections must ensure that hash functions and procedures preserve the casing conventions of the DNS.

Benefits of Separate Structures​

The use of separate structures for the different parts of the database is motivated by several factors:

1. Catalog Stability:

  • The catalog structure can be an almost static structure
  • Need change only when the system administrator changes the zones supported by the server
  • Can also store parameters used to control refreshing activities

2. Atomic Zone Replacement:

  • Individual data structures for zones allow a zone to be replaced simply by changing a pointer in the catalog
  • Zone refresh operations can build a new structure and, when complete, splice it into the database via a simple pointer replacement
  • Critical: When a zone is refreshed, queries should not use old and new data simultaneously

3. Data Precedence:

  • With the proper search procedures, authoritative data in zones will always "hide", and hence take precedence over, cached data

4. Error Isolation:

  • Errors in zone definitions that cause overlapping zones may cause erroneous responses to queries
  • Problem determination is simplified
  • The contents of one "bad" zone can't corrupt another

5. Cache Management:

  • Since the cache is most frequently updated, it is most vulnerable to corruption during system restarts
  • It can also become full of expired RR data
  • In either case, it can easily be discarded without disturbing zone data

Crash Recovery​

A major aspect of database design is selecting a structure which allows the name server to deal with crashes of the name server's host.

State information which a name server should save across system crashes:

  • The catalog structure (including the state of refreshing for each zone)
  • The zone data itself

6.1.3. Time​

Both the TTL data for RRs and the timing data for refreshing activities depends on 32 bit timers in units of seconds.

Time Representation​

Conceptual Model:

  • Inside the database, refresh timers and TTLs for cached data conceptually "count down"
  • Data in the zone stays with constant TTLs

Recommended Implementation Strategy:

Store time in two ways: as a relative increment and as an absolute time.

One way to do this is to use:

  • Positive 32 bit numbers for one type
  • Negative numbers for the other

Usage:

  • The RRs in zones use relative times
  • The refresh timers and cache data use absolute times
  • Absolute numbers are taken with respect to some known origin and converted to relative values when placed in the response to a query
  • When an absolute TTL is negative after conversion to relative, then the data is expired and should be ignored

6.2. Standard Query Processing​

The major algorithm for standard query processing is presented in RFC-1034.

Special Cases and Rules​

QCLASS= Processing*:

  • When processing queries with QCLASS=*, or some other QCLASS which matches multiple classes
  • The response should never be authoritative unless the server can guarantee that the response covers all classes

Duplicate RR Handling:

  • When composing a response, RRs which are to be inserted in the additional section, but duplicate RRs in the answer or authority sections, may be omitted from the additional section

Truncation Policy:

  • When a response is so long that truncation is required
  • The truncation should start at the end of the response and work forward in the datagram
  • Thus if there is any data for the authority section, the answer section is guaranteed to be unique

SOA MINIMUM Field:

  • The MINIMUM value in the SOA should be used to set a floor on the TTL of data distributed from a zone
  • This floor function should be done when the data is copied into a response
  • This will allow future dynamic update protocols to change the SOA MINIMUM field without ambiguous semantics

6.3. Zone Refresh and Reload Processing​

Error Handling​

In spite of a server's best efforts, it may be unable to:

  • Load zone data from a master file due to syntax errors, etc.
  • Refresh a zone within its expiration parameter

In this case: The name server should answer queries as if it were not supposed to possess the zone.

Zone Transfer Consistency​

If a master is sending a zone out via AXFR, and a new version is created during the transfer:

  • The master should continue to send the old version if possible
  • In any case, it should never send part of one version and part of another
  • If completion is not possible, the master should reset the connection on which the zone transfer is taking place

6.4. Inverse Queries (Optional)​

Inverse queries are an optional part of the DNS.

Support Requirements​

  • Name servers are not required to support any form of inverse queries
  • If a name server receives an inverse query that it does not support, it returns an error response with the "Not Implemented" error set in the header
  • While inverse query support is optional, all name servers must be at least able to return the error response

6.4.1. The Contents of Inverse Queries and Responses​

Inverse queries reverse the mappings performed by standard query operations:

  • While a standard query maps a domain name to a resource
  • An inverse query maps a resource to a domain name

Example:

  • A standard query might bind a domain name to a host address
  • The corresponding inverse query binds the host address to a domain name

Format​

Inverse queries take the form of:

  • A single RR in the answer section of the message
  • An empty question section
  • The owner name of the query RR and its TTL are not significant

Response​

The response carries questions in the question section which identify all names possessing the query RR WHICH THE NAME SERVER KNOWS.

Important Limitations:

  • Since no name server knows about all of the domain name space, the response can never be assumed to be complete
  • Thus inverse queries are primarily useful for database management and debugging activities
  • Inverse queries are NOT an acceptable method of mapping host addresses to host names; use the IN-ADDR.ARPA domain instead

Case-Insensitive Comparisons​

Where possible, name servers should provide case-insensitive comparisons for inverse queries:

  • An inverse query asking for an MX RR of Venera.isi.edu should get the same response as a query for VENERA.ISI.EDU
  • An inverse query for HINFO RR IBM-PC UNIX should produce the same result as an inverse query for IBM-pc unix

Note: This cannot be guaranteed because name servers may possess RRs that contain character strings but the name server does not know that the data is character.

Processing Results​

When a name server processes an inverse query, it either returns:

  1. Zero, one, or multiple domain names for the specified resource as QNAMEs in the question section
  2. An error code indicating that the name server doesn't support inverse mapping of the specified resource type

Response Modification​

When the response to an inverse query contains one or more QNAMEs:

  • The owner name and TTL of the RR in the answer section which defines the inverse query is modified to exactly match an RR found at the first QNAME

Caching Restrictions​

RRs returned in the inverse queries cannot be cached using the same mechanism as is used for the replies to standard queries.

Reason: A name might have multiple RRs of the same type, and only one would appear. For example, an inverse query for a single address of a multiply homed host might create the impression that only one address existed.

6.4.2. Inverse Query and Response Example​

The overall structure of an inverse query for retrieving the domain name that corresponds to Internet address 10.1.0.52:

Query:

+-----------------------------------------+
|  Header   | OPCODE=IQUERY, ID=997       |
+-----------------------------------------+
| Question  | <empty>                     |
+-----------------------------------------+
|  Answer   | <anyname> A IN 10.1.0.52    |
+-----------------------------------------+
| Authority | <empty>                     |
+-----------------------------------------+
|Additional | <empty>                     |
+-----------------------------------------+

Explanation:

  • This query asks for a question whose answer is the Internet style address 10.1.0.52
  • Since the owner name is not known, any domain name can be used as a placeholder (and is ignored)
  • A single octet of zero, signifying the root, is usually used because it minimizes the length of the message
  • The TTL of the RR is not significant

Response:

+-----------------------------------------+
|  Header   | OPCODE=RESPONSE, ID=997     |
+-----------------------------------------+
| Question  | QTYPE=A, QCLASS=IN,         |
|           | QNAME=VENERA.ISI.EDU        |
+-----------------------------------------+
|  Answer   | VENERA.ISI.EDU A IN         |
|           | 10.1.0.52                   |
+-----------------------------------------+
| Authority | <empty>                     |
+-----------------------------------------+
|Additional | <empty>                     |
+-----------------------------------------+

Note: The QTYPE in a response to an inverse query is the same as the TYPE field in the answer section of the inverse query. Responses to inverse queries may contain multiple questions when the inverse is not unique. If the question section in the response is not empty, then the RR in the answer section is modified to correspond to be an exact copy of an RR at the first QNAME.

6.4.3. Inverse Query Processing​

Name servers that support inverse queries can support these operations through exhaustive searches of their databases, but this becomes impractical as the size of the database increases.

Alternative Approach: Invert the database according to the search key.

Recommendation for Large Servers​

For name servers that support multiple zones and a large amount of data, the recommended approach is:

  • Separate inversions for each zone
  • When a particular zone is changed during a refresh, only its inversions need to be redone

Note: Support for transfer of this type of inversion may be included in future versions of the domain system, but is not supported in this version.

6.5. Completion Queries and Responses​

The optional completion services described in RFC-882 and RFC-883 have been deleted.

Redesigned services may become available in the future.

Next: 7. Resolver Implementation

Last updated on