Summary

  • In strict DNS presentation, a fully qualified name ends with the root-label dot; in ordinary display, that dot is usually omitted. The two forms can name the same DNS node without being interchangeable inputs to every application policy.
  • A DNSOP draft in Working Group Last Call tells applications to store and display fully qualified names without the final dot and warns against generic string handling. A Last Call reviewer asked for a more executable rule for comparing dotted and undotted forms.
  • curl’s CVE-2026-8924 supplies bounded running-code evidence: a trailing-dot mismatch let a cookie domain evade a Public Suffix List check. The lesson is not that a dot grants authority, but that normalization order belongs in the security contract.

Consider example.co.uk and example.co.uk.. The second spelling makes the DNS root label explicit. RFC 9499 calls the explicit spelling the strict presentation format, while describing the dot as optional in the common display format. A resolver can therefore reach the same name tree node from either representation. A cookie jar, certificate matcher, cache, database or authorization service does not inherit that equivalence by magic.

That seam is now inside an active standards discussion. On 24 August, the IETF DNSOP Working Group placed draft-ietf-dnsop-integration-04 in Working Group Last Call, ending 7 September. The document is Informational in intent. It describes a “responsible DNS integration” as one that uses global-DNS names consistently without damaging DNS security, stability or resiliency. Its checklist covers lifecycle, control validation, completeness, synchronization, protocol evolution, management interfaces and record support.

The draft already contains an important instruction. Applications should normally store and display fully qualified domain names without the final dot, unless they need network-local search domains. It also says that display, normalization, comparison, encoding and decoding need special handling and cannot be left to generic string operations. Those two statements identify the hazard. They do not yet constitute a testable normalization contract for every downstream control.

Paul Wouters made that distinction explicit in Last Call. He did not object to publication, but said the draft lacked much of the technical advice application developers need. His examples included comparison with and without a trailing dot, DNS case insensitivity, A-label and U-label comparison, negative caching, dangling aliases and preservation of the original query name through alias processing. Wes Hardaker supported publication while saying the document supplies context more than immediate help. Tim Wicinski also supported progression and observed that the later checklist items border on operational considerations.

These are individual comments, not a Working Group decision.

The trailing-dot example is unusually useful because running code has already exposed the cost of an unspecified order. curl’s official advisory for CVE-2026-8924, published on 24 June, describes a low-severity flaw fixed in 8.21.0. With Public Suffix List support enabled, a server could set a cookie for a trailing-dot domain such as co.uk. while curl handled a URL hostname such as example.co.uk.. The suffix check failed to contain the cookie as intended, allowing it to be sent to unrelated domains. The affected range was curl 7.46.0 through 8.20.0.

The failure did not require DNS to resolve the two forms to different places. It arose because the application’s security boundary was evaluated against a representation that had not been reconciled with the form expected by the policy mechanism. curl also notes that a trailing dot cannot be carried in TLS SNI. One input could therefore pass through DNS, cookie and TLS layers under different textual rules even when an operator thought it was “the same hostname.” An earlier curl advisory, CVE-2022-30115, documented a separate HSTS mismatch around the same presentation distinction.

That history is corroboration, not proof that every stack repeats the defect.

Case and internationalized names make the contract wider. RFC 4343 requires case-insensitive comparison for ordinary DNS ASCII labels, yet warns that a DNS name may become a case-sensitive database key or authentication input outside DNS. RFC 5890 distinguishes the Unicode U-label from its ASCII-compatible A-label and explicitly leaves the final-dot convention outside its scope. “Lowercase the string” is not a complete answer; neither is “strip the dot” after a policy decision has already been made.

A defensible integration should record at least five states. First is the raw input, including whether a terminal root label was explicit and whether local search expansion was permitted. Second is the parsed DNS label sequence and a canonical form suitable for the decision being made. Third is the policy context: the Public Suffix List version, IDNA profile, certificate rules, cookie rules or cache namespace actually consulted. Fourth is the decision—same name, allowed scope, validated control, accepted certificate or authorized action. Fifth is the observed effect, such as a stored cookie, a transmitted credential or a rejected request.

Those receipts prevent a common collapse. DNS equivalence does not prove registrant control. Domain-control validation does not establish a certificate for every service. A certificate does not authorize every application action. A cookie-domain match does not prove the intended recipient used the cookie. Each result belongs to the layer that produced it.

The Last Call closes with a useful asymmetry. The draft is right to tell developers that names need special processing. The operational record is right to ask exactly when that processing happens. If the canonical form appears only after an access-control, suffix, origin or credential decision, the application has not normalized its security boundary. It has merely normalized the audit log.

Sources