Domain Name System (DNS) Case Insensitivity Clarification
updated by
- rfc-5890 — Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
updates
Extracted elements (15)
Case folding (subtracting 0x20 from lowercase ASCII octets before comparison) is one valid implementation approach for case insensitivity, but is not required. Implementations are free to use any method that achieves the correct matching behavior.
DNS case insensitivity applies only to ASCII labels (label type 0x0). Extended label types such as the BINARY type defined in RFC 2673 are not subject to ASCII case insensitivity conventions, because those conventions are specific to ASCII labels.
DNS case insensitivity does NOT correspond to the case folding specified in ISO-8859-1 or ISO-8859-2. For example, octets 0xDD and 0xFD do not match in DNS even though they represent upper- and lower-case 'Y' with acute accent in those encodings.
DNS label case handling is not CLASS dependent. The original DNS design intended recursive resolvers to handle unknown CLASSes, requiring uniform case insensitivity. A CLASS with case-sensitive ASCII labels would require a new label type rather than a CLASS-specific exception.
Internationalized domain name (IDN) case insensitivity varies by script and is handled entirely at the application-level transformation layer (RFC 3454, RFC 3491), not within the DNS protocol as standardized in STD 13.
When name compression (indirect labels) is used to optimize output, the case-insensitive comparison is used to determine if names match for pointer reuse. This means name compression may destroy the case that was originally preserved on input, as only one capitalization of a shared name tail is stored.
A lookup string octet with a value in the inclusive range from 0x41 to 0x5A (uppercase ASCII letters) MUST match the identical value and also match the corresponding value in the range from 0x61 to 0x7A (lowercase ASCII letters), and vice versa.
Case MUST be preserved on output and preserved when convenient on input, per STD13. However, this requirement does not apply when output is optimized using indirect (compression) labels.
When a DNS name node already exists and new input provides the same label with different case, implementations MAY retain the original case, allow new input to override, or maintain separate copies. Any retrieval capitalization will retrieve all RRs regardless of stored capitalization.
DNS label octets are 8-bit bytes; all 256 values are permitted. While many applications interpret them as ASCII, the DNS specification does not restrict labels to valid ASCII character codes.
Original DNS wire-encoded labels have two types: ASCII labels (0 to 63 octets in length) and indirect (compression) labels consisting of an offset pointer to a name elsewhere in the DNS message. The ASCII label of length zero is reserved for the root node.
A DNS name used as a case-sensitive index into a database or file system, or interpreted as binary data by an authentication or integrity system, may produce security vulnerabilities due to DNS case insensitivity. The recommended mitigation is to use a canonical form (e.g., consistently uppercase or lowercase) as described in RFC 4034, Section 6.
Storing non-DNS data (e.g., case-sensitive email local parts in RP records) into DNS with the expectation that case is always preserved is incorrect and can lead to security implications, since DNS output case may change due to name compression.
The case equivalence of DNS labels can cause user confusion if two domain names differing only in case are mistakenly believed to be different names, potentially enabling phishing or spoofing attacks.
In Master Files and human-readable ASCII contexts, octets outside the inclusive range 0x21 to 0x7E (plus 0x2E, the period) must be escaped using a backslash followed by exactly three decimal digits representing the octet value. A backslash followed by only one or two decimal digits is undefined.