Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
obsoletes
Extracted elements (27)
Cumulative application of regular expressions (applying each rewrite to the output of the previous one) was explicitly prohibited because experience showed such use to be extremely fault-sensitive, error-prone, and difficult to debug.
DNS administrators are advised to use the 'default delimiter' feature of DDDS regular expressions (where the first character of the regexp is the delimiter, e.g., '!') to minimize backslash usage and reduce zone file errors.
Regular expressions were chosen for the REGEXP field for their compactness-to-expressivity ratio, allowing a great deal of information to be encoded in a relatively small DNS packet. This was the original motivation for the NAPTR record in the URN Working Group.
The PREFERENCE field is separated from ORDER to allow domain administrators to direct clients toward more capable hosts or lighter-weight protocols among otherwise equivalent rules, while ORDER enforces mandatory processing sequence. DNS SRV or multiple A records are recommended for load balancing rather than PREFERENCE.
The REPLACEMENT field exists as a historical optimization for DNS name compression when the substitution is a simple domain-name replacement. It is otherwise functionally equivalent to using REGEXP and avoids the need to send a full regular expression.
Additional section processing requires upgraded DNS servers, and it will take many years before applications can expect to see relevant records in the additional information section. Applications must not rely on it.
Backslashes in REGEXP master file entries must be doubled (entered twice in a zone file to appear once in a query response). This double-backslash requirement may not have been tested by all DNS server implementors, creating a potential interoperability hazard.
When multiple Applications share this Database (e.g., ENUM and URI Resolution), collision between NAPTR records in the same domain can be avoided by using separate sub-zones, anchoring regular expressions to Application-specific strings, or using distinct Flags/Services values.
A client MUST process multiple NAPTR records in the order specified by the ORDER field; it MUST NOT simply use the first record that provides a known Service Parameter combination.
Applications MUST NOT require that records of any type be in the Additional Information section of any DNS response in order for clients to function; all applications must handle responses from nameservers that never fill in the Additional Information section.
If a record is returned with values in both REGEXP and REPLACEMENT fields, it is considered to be in error and SHOULD be either ignored or an error returned.
Once a match is found, the client MUST NOT consider records with a different ORDER value, but MAY process records with the same ORDER but different PREFERENCE values.
Substitution expressions MUST NOT be written where they depend on a specific POSIX locale, as this would prevent them from being universally applicable.
The REGEXP field's regular expressions MUST NOT be used cumulatively; they MUST only be applied to the original string held by the client, never to a domain name produced by a previous NAPTR rewrite.
When falling back to previously retrieved sets of Rules, the application MUST ensure that none of the records it is relying on have expired (per their DNS TTL). If even a single record has expired, the application is required to start over at the beginning of the algorithm.
An Application using this DDDS Database must define: the domain that First Well Known Rule Keys belong to, the allowed values for Services and Protocols fields, and the expected output and Flag encoding of terminal rewrite rules.
Rule insertion is performed by adding NAPTR records to the appropriate DNS zone. Only the entity with administrative control of a zone can specify Rules for Keys within that zone.
The DNS DDDS Database uses domain-names as Keys. A lookup request is a standard DNS query for NAPTR RRs at the given domain-name, and the response is a series of NAPTR records representing the Rules.
The NAPTR DNS Resource Record (type code 35) serves as the Rule encoding mechanism for the DDDS DNS Database. It contains six fields: ORDER, PREFERENCE, FLAGS, SERVICES, REGEXP, and REPLACEMENT, and is retrieved by querying DNS for NAPTR RRs at a domain-name Key.
Regular expressions in NAPTR records should be checked for sanity and not blindly passed to an interpreter such as Perl, since arbitrary code can be included and subsequently executed.
The NAPTR record can be signed and validated using DNSSEC procedures. This Database makes identifiers from other namespaces subject to the same attacks as normal domain names, which may be a new exposure since those identifiers were not previously easily resolvable.
The FLAGS field is a <character-string> containing single characters from A-Z and 0-9 (case-insensitive) that control rewriting and interpretation. The field may be empty; which flags are terminal is defined by the Application.
The ORDER field is a 16-bit unsigned integer specifying the mandatory processing order of NAPTR records from lowest to highest. Records with the same ORDER value are treated as equivalent rules selected by PREFERENCE.
The PREFERENCE field is a 16-bit unsigned integer (0–65535) that orders NAPTR records with equal ORDER values, with lower values processed first. It is equivalent to the Priority value in the DDDS Algorithm.
The REGEXP field is a <character-string> containing a substitution expression applied to the original client string to construct the next domain name to look up. It and the REPLACEMENT field are mutually exclusive.
The REPLACEMENT field is a <domain-name> specifying the next domain to query when the regular expression is a simple replacement. Any value MUST be a fully qualified domain-name and name compression MUST NOT be used for this field.
The SERVICES field is a <character-string> specifying the Service Parameters applicable to the delegation path. Its allowed values are defined by the Application Specification using this Database.