Build canonical data without guessing names
05DNS Security Extensions (DNSSEC) use a canonical, predictable byte representation for signatures. Transporting unknown data and verifying a signature are separate operations. The later RFC4034 §6 defines the canonical rules used in this comparison.
Separate synthetic unknown-type RRset holds [80], [41 00] and [41]. Unsigned canonical order is [41], [41 00], [80]. The shorter prefix comes first, and 80 is greater than41; no signature verdict follows.
Source for this drawing: RFC 3597 · Read RFC section 7 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The DNSSEC record-format update supplies canonical form and ordering. Verified erratum1063 also identifies the erroneous HINFO entries: HINFO/TXT character strings are not embedded domain names. This guide uses typed NS and opaque-string comparisons, not the old list as a parser.
Read the updated RFC section ↗The canonical owner name is fully expanded and lowercased according to DNS ASCII rules. Unknown-type RDATA is not scanned for plausible names or downcased.
- The canonical owner name is fully expanded and lowercased according to DNS ASCII rules. Unknown-type RDATA is not scanned for plausible names or downcased.
- Specified older known types, such as NS (name server), do lowercase embedded DNS names in canonical RDATA. RFC4034 §6.2 adds the later DNSSEC context; it does not require lowercasing arbitrary opaque bytes.
- Verified erratum1063 identifies HINFO in the old lists as erroneous: HINFO and TXT contain no embedded domain names to lowercase. Their character-string payload must not be treated as DNS name data.
- For one owner/class/type RRset (a set of records), canonical RDATA ordering is unsigned lexicographic octet order; absence of an octet sorts before a zero octet. This picture does not calculate or validate a signature.
Offline bounded examples, not a complete DNS server, master-file parser or DNSSEC validator. Hexadecimal pairs represent octets (eight-bit bytes). Layouts are schematic unless marked otherwise. Generic data transport neither understands an application nor authenticates it.
Read the RFC section ↗