Skip to main content

6. Canonical Form and Order of Resource Records

This section defines a canonical form for resource records, a canonical ordering of DNS names, and a canonical ordering of resource records within an RRset. A canonical name order is needed to construct the NSEC name chain. A canonical RR form and ordering within an RRset are needed to construct and verify RRSIG RRs.

6.1. Canonical DNS Name Order \​

For the purposes of DNS security, owner names are ordered by treating individual labels as unsigned left-justified octet strings. When octet strings are compared, the absence of an octet sorts before a zero-valued octet, and uppercase US-ASCII letters are treated as if they were lowercase US-ASCII letters.

To compute the canonical ordering of a set of DNS names, start by sorting the names according to their most significant (rightmost) labels. For names in which the most significant label is identical, continue sorting according to their next most significant label, and so forth.

For example, the following names are sorted in canonical DNS name order. The most significant label is "example". At this level, "example" sorts first, followed by names ending in "a.example", then by names ending in "z.example". The names within each level are sorted in the same way.

          example
          a.example
          yljkjljk.a.example
          Z.a.example
          zABC.a.EXAMPLE
          z.example
          \001.z.example
          *.z.example
          \200.z.example

6.2. Canonical RR Form \​

For the purposes of DNS security, the canonical form of an RR is the wire format of the RR where:

  1. every domain name in the RR is fully expanded (no DNS name compression) and fully qualified;

  2. all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters;

  3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters;

  4. if the owner name of the RR is a wildcard name, the owner name is in its original unexpanded form, including the "*" label (no wildcard substitution); and

  5. the RR's TTL is set to its original value as it appears in the originating authoritative zone or the Original TTL field of the covering RRSIG RR.

6.3. Canonical RR Ordering Within an RRset \​

For the purposes of DNS security, RRs with the same owner name, class, and type are sorted by treating the RDATA portion of the canonical form of each RR as a left-justified unsigned octet sequence in which the absence of an octet sorts before a zero octet.

[RFC2181] specifies that an RRset is not allowed to contain duplicate records (multiple RRs with the same owner name, class, type, and RDATA). Therefore, if an implementation detects duplicate RRs when putting the RRset into canonical form, it MUST treat this as a protocol error. If the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset.

Related Chapter Navigation:

Last updated on