Summary

  • RFC 3403 stored DDDS rules in DNS NAPTR records, but the order in which records appeared in a response was not their rule order. Clients had to sort by ORDER and use PREFERENCE only among records in the same authority layer.
  • Once a rule matched, a client could not drift into a different ORDER merely because another record arrived first or offered a familiar service. Optional Additional data, valid DNSSEC and a successful terminal lookup remained separate evidence.

A DNS response can look like a list. Records appear one after another on a wire, in a packet capture and in diagnostic output. RFC 3403 demanded that a DDDS client resist the visual suggestion. A set of NAPTR records was not a program in arrival order. The program had to be reconstructed from fields inside the records.

Published on the Standards Track in October 2002, RFC 3403 defined the Domain Name System as a DDDS rule database. A database key was a valid DNS domain name. A client queried that name for NAPTR resource records, type code 35, and received candidate rules. The document superseded RFC 2915 and RFC 2168 as the formal NAPTR specification.

The ORDER field recovered the delegation sequence. Lower values were processed before higher values. Two records sharing an ORDER were treated as the same rule for authority purposes, even if they offered different services or transports. Once a match was found, the client was not allowed to continue into another ORDER, apart from the explicit complex-service-selection exception defined by the DDDS algorithm.

That rule made arrival order evidentially weak. A server, cache, library or packet path could present the RRset in a different sequence without changing its meaning. A client that simply accepted the first known Services combination would silently replace the zone administrator's ordered rule structure with a transport accident.

PREFERENCE operated at a lower level. It corresponded to Priority in the DDDS algorithm and sorted alternatives with equal ORDER, lowest first. A client could consider a less preferred alternative for a reason such as poor support for the preferred protocol. It could not use that flexibility to cross the authority boundary into a different ORDER after matching.

RFC 3403 also denied PREFERENCE the role of load balancer. It communicated quality or preference among rules considered equivalent from an authority standpoint. If an application needed traffic distribution among otherwise equal services, DNS already offered mechanisms such as SRV or multiple A records. Treating a preference as a weight would invent a randomization contract that the record did not contain.

Each NAPTR also carried Flags, Services, REGEXP and REPLACEMENT. Flags and Services had no universal meaning in the database specification; the paired Application specification had to define them, including which flags were terminal. A client recognizing the letters was not evidence that it understood the application using them.

REGEXP and REPLACEMENT together represented the DDDS substitution expression, but they were mutually exclusive forms. REGEXP held an expression applied to the original application string. REPLACEMENT held a fully qualified domain name for a simple replacement and prohibited DNS name compression. A record populating both fields was erroneous and should be ignored or produce an error.

This syntax created a second ordering problem between administration and execution. Zone files use backslash escaping, while the expression received by the client contains the result after DNS master-file parsing. RFC 3403 warned that a backslash often had to be entered twice to appear once in the response. An operator reviewing only a zone-file source or only a packet could miss a transformation between the two.

Text interpretation also mattered. NAPTR character fields used UTF-8. Outside the ASCII-equivalent range, substitution had to treat input as code points, not a series of bytes. Expressions could not depend on a particular POSIX locale because a rule whose meaning changed with the client's locale would cease to be universally applicable.

The database could host more than one DDDS application, producing collision risk. RFC 3403 described three boundaries: put applications in separate zones, anchor expressions to application-distinguishing input, or rely on application-specific Flags and Services so irrelevant rules were ignored. Merely co-locating records at one DNS name did not make them one application.

Additional-section processing was an optimization, not a dependency. A server could attach relevant A or SRV RRsets carrying the same authenticity as the answer. An application could use them. But every application had to function with nameservers that never supplied Additional data. Absence therefore meant “perform the next query,” not “the NAPTR answer is incomplete.”

TTL constrained reuse. If a client fell back to previously retrieved rules after a bad delegation path or server failure, it had to verify that every relied-on record remained valid. Expiry of even one rule required starting the DDDS algorithm over. Combining a fresh NAPTR with an expired earlier rule would create an ordered program that had not existed at one time.

The RFC's advice on lookup failure was deliberately conservative. After a rewrite led to a failed lookup, clients were strongly encouraged to report failure rather than back up and pursue other rewrite paths. Backtracking could make a deterministic delegation graph behave like an opportunistic search tree and conceal the authority at which the path failed.

DNSSEC could sign and validate NAPTR like other DNS records. That established authenticity properties of the DNS data under the DNSSEC chain. It did not prove that a regular expression was safe, that the client sorted correctly, that Services matched the intended Application, or that the downstream endpoint worked. RFC 3403 separately warned against blindly passing expressions to environments capable of executing arbitrary code.

The IANA DNS Parameters registry still records NAPTR as resource-record type 35, evidence of coordinated assignment rather than correct processing or deployment. The RFC Editor currently lists one editorial erratum, ID 2868, held for document update. It removes a duplicated word in the Services description; it changes none of the ordering semantics.

An operational receipt must therefore preserve the query key, complete RRset, DNSSEC state, TTLs, packet order, the sorted ORDER groups, within-group PREFERENCE, Flags, Services, REGEXP or REPLACEMENT validity, UTF-8 interpretation, zone-file-to-wire expression, service rejection, selected record, Additional data actually used, next query and terminal consumer outcome.

Lu Heng's Minimum Initial Specification principle explains the division. RFC 3403 standardized the minimum DNS representation and processing boundary while applications retained their own service meanings. Running-Code Primacy supplies the proof: shuffle the returned RRset, omit Additional data, vary client locale, expire one dependency and compare the selected rule. A conforming result should follow authority fields, not presentation.

RFC 3403 turned a DNS set into an ordered act without pretending that DNS transport had supplied the order. The first record in a packet was only the first one seen. The first rule was the one the contract said came first.

Sources