Summary

  • DNS compares ASCII letters without regard to case, but implementations often return the question in the same capitalization they received. The 2008 DNS-0x20 proposal tried to turn that exact echo into temporary transaction identity.
  • Each eligible letter could add one guessed bit, yet the protection depended on letter count, unmodified passage through servers and middleboxes, careful cache handling and downgrade-resistant fallback. It did not authenticate DNS data and never became a final RFC.

One name, two tests

Imagine a resolver sending a name whose letters alternate unpredictably between upper and lower case. The authoritative server does not need to understand the pattern. For lookup purposes, the mixed-case question and an all-lowercase question identify the same place. But when the response returns, the resolver can impose a second test: did the question section come back in exactly the pattern it sent?

Those are not contradictory rules. The server applies semantic equivalence to find data. The resolver applies byte-level memory to match one response to one outstanding request. A blind forger may know the name being queried and still have to guess a presentation choice that did not exist until that query was made.

That distinction is the heart of the proposal called DNS-0x20. It did not add a new DNS field. It tried to make temporary use of information the original protocol had already declared irrelevant to name identity.

The old specification left a narrow seam

RFC 1035, published in 1987, says comparisons in the DNS protocol are case-insensitive. A name written with capital letters and the same name written without them are identical for DNS purposes. Yet the document also says original case should be preserved whenever possible and that loss of case-sensitive data should be minimized.

This was a practical compromise. Case could not safely divide the namespace into parallel objects: users and software needed one stable name. At the same time, preserving the spelling supplied by an operator or requester was useful presentation behavior. Identity was folded; representation was not always erased.

RFC 4343 later narrowed the rule. The equivalence concerns ASCII A-Z and a-z; it is not a license to apply arbitrary language-specific case transformations or to confuse DNS wire comparison with IDNA processing. The clarification also warns that capitalization returned in a response is not guaranteed. Shared storage can retain only one rendering, and name compression can make an output label borrow its representation from somewhere else in the message.

The seam was therefore real but conditional: case did not select the RRset, while case sometimes survived the trip.

A query could spend the seam once

The March 2008 Internet-Draft Use of Bit 0x20 in DNS Labels proposed randomizing the case bit of each ASCII letter in the question name. The numerical name 0x20 comes from the bit that separates uppercase and lowercase ASCII letters. To the responder, every resulting pattern remained the same DNS name. To the requester, each pattern could be a different challenge for the lifetime of that query.

The proposal relied on a common response behavior: authoritative servers generally copied the question section from request to response. The draft's authors reported that the implementations they tested did this exactly, although the DNS specifications of the time did not require exact case copying. A resolver could remember the original mixed-case question, compare it with the returned question, and discard a response whose case bits differed even if the transaction ID and other fields looked right.

This added another coordinate to the resolver's response-matching state. RFC 5452 describes a forged-answer defense in terms of the whole outstanding-query tuple: question, identifier, addresses and ports, class and type must correspond. A fully random 16-bit transaction ID still gives a blind guess a finite target; unpredictable source ports can enlarge it. DNS-0x20 tried to enlarge it again using bits already riding inside QNAME.

It was additive, not substitutive. A resolver that randomized case but used predictable identifiers and ports had not acquired authenticity. It had merely changed the arithmetic of a race.

Not every name carried the same budget

The extra challenge space was proportional to eligible letters. Each ASCII letter could carry at most one randomized case bit. Digits and hyphens offered none. A short name with six letters could expose only six such choices; a longer letter-rich name could expose more.

This asymmetry matters because the mechanism's security claim is concrete rather than ceremonial. There is no uniform “0x20 enabled” strength. The effective contribution depends on the queried name, on whether the case choices are actually unpredictable, and on whether the response path preserves them. Counting configured support without counting surviving bits would confuse a feature flag with a control.

Nor do non-ASCII labels simply multiply the budget. RFC 4343 keeps the DNS ASCII comparison rule distinct from internationalized-name transformations. Applying a locale's ideas about uppercase and lowercase to a wire name would change the problem rather than extend this mechanism.

Exact echo was an accidental dependency

The expired draft described exact question copying as nearly universal in its 2008 tests, but it also found implementations that normalized questions to lowercase. Forwarders, inspection devices or other intermediaries could do the same. Such a component might preserve the meaning of the lookup perfectly while destroying the per-query challenge.

That creates a revealing compatibility problem. The semantic contract says the response can still concern the right name. The defensive contract says the response is unusable because a remembered pattern was lost. A resolver cannot solve the conflict by pretending both tests mean the same thing.

A mismatch is also ambiguous evidence. It may be a blind forgery. It may be a server or middlebox that folds case. It may be a software defect. The proposal recommended logging mismatches and trying other authoritative addresses. It did not turn a changed capital letter into proof of attack.

The challenge had to vanish before the cache

The most instructive part of DNS-0x20 is not the randomization. It is the cleanup.

DNS messages use compression pointers. Names in the answer, authority and additional sections can point back into the question section rather than repeating the same labels. If a resolver validated a randomized question and then decompressed or cached the rest of the message unchanged, the temporary case pattern could migrate into stored data and later responses.

The draft therefore told the requester to remember the original question and restore it after verification but before decompressing the other sections. Ephemeral transaction identity had to be removed at the boundary of durable state. Otherwise, a defense intended for one exchange could pollute presentation across many later exchanges and even interfere with other checks.

That requirement exposes a general systems rule: when representational slack becomes a nonce, the system must say exactly when it stops being a nonce. Generation without erasure is not a complete design.

Fallback could erase the very benefit

Strict checking protects the challenge but can make a case-folding authority appear unreachable. Immediate permissive fallback protects availability but gives an attacker a possible downgrade: cause enough mismatches and induce the resolver to stop checking the bits.

The draft proposed a more expensive inference. Try the zone's other authoritative servers. If all fail, repeat the sequence with fresh identifiers and other randomized elements, preferably in a different server order. Only after repeated responses correctly echo the other unpredictable fields while consistently changing case would it be reasonable to treat the case channel as incompatible.

This was not a free solution. Retries cost time and queries, and a server that strips case could receive several times the traffic. Random generation also exposes more output for analysis. The control therefore traded forgery cost against latency, load and the risk of attacker-influenced fallback.

DNSSEC deliberately spends case in another way

DNSSEC marks the boundary most clearly. RFC 4034 defines canonical RR form for signing and verification. It expands compressed names and converts relevant uppercase ASCII letters to lowercase. Signatures need every verifier to construct the same octet sequence, not to preserve a requester's transient typography.

DNS-0x20 and DNSSEC can therefore touch the same letters for opposite reasons. The former depends on a random presentation pattern surviving one round trip. The latter removes presentation differences to authenticate canonical data. Guessing resistance is not origin authentication, and a correct echo does not prove that an RRset was authorized by the zone.

A proposal about the value of discarded distinctions

The DNS-0x20 document expired in September 2008. It should not be cited as a final DNS standard or as proof that every present-day path supports the technique. Its historical value lies elsewhere.

It showed that a protocol's ignored distinctions are not always empty. A distinction can be irrelevant to the protocol's equivalence rule yet useful as temporary local state. But extracting that value creates obligations: measure how many bits exist, verify every dependency, remove the state before caching, distinguish mismatch from attack, and prevent compatibility fallback from becoming a remote switch.

Capital letters did not become authority. For one query, under the right conditions, they became a question that an unseen reply had to answer.

Sources and limits

This account relies on RFC 1035, RFC 4343, RFC 5452, RFC 4034 and the March 2008 DNS-0x20 Internet-Draft. The draft's implementation observations describe its authors' tests at that time; these sources do not establish current deployment share, product defaults or a universal compatibility rate.