Compare unknown data bit for bit
04Record equality is needed by operations such as DNS Dynamic Update. For the same unknown type, RDATA equality compares every bit; it does not interpret embedded text as a domain name.
Generic text \# 3 014100 and \# 3 014100 decodes identically; more visibly, \# 1 af and \# 1 AF both decode to octet AF. Hexadecimal letter case is not an embedded name’s character case.
Source for this drawing: RFC 3597 · Read RFC section 6 ↗
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.
Unknown-type RDATA is equal when bitwise equal. New RR specifications MUST NOT introduce type-specific equality rules that make known and unknown servers disagree.
- Unknown-type RDATA is equal when bitwise equal. New RR specifications MUST NOT introduce type-specific equality rules that make known and unknown servers disagree.
- Embedded names in those opaque fields compare case-sensitively. An embedded A and a are different octets; converting a hexadecimal spelling from upper to lower case does not change the decoded octets.
- The examples hold owner, class and type fixed. DNS owner-name comparison rules are separate; this is not a claim that DNS lookups become case-sensitive.
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 ↗