Summary

  • draft-levine-dnsextlang-14 proposes describing DNS RRTYPE syntax in TXT records so servers and provisioning systems can support many new types from configuration data. It is an individual Internet-Draft, not an RFC or a deployed IANA service.
  • The draft separates ordinary table-driven types from types that require special processing, but a published X flag only signals that extra code is needed. It does not provide that code or prove that a particular server has it.
  • DNSSEC can authenticate the origin and integrity of a definition under a validator's trust policy. Safe execution still needs version reconciliation, local-override disclosure, parser tests, wire conversion, isolated loading, authoritative query readback and rollback evidence.

An operator receives a small TXT RRset from an authenticated DNS path. It says that a new record has a symbolic name, a numeric type and five fields. The signature validates. The syntax looks ordinary. A provisioning screen can already render the five prompts. None of those facts answers the last question before a production reload: will this exact serving binary turn this exact text into the expected octets, preserve them through storage and transfer, and return the intended answer without activating a code path it does not possess?

The distinction matters because the proposal is designed to remove a release boundary. Today a new RRTYPE may require changes in authoritative servers and in the provisioning systems that create their master files. Revision 14 of An Extension Language for the DNS proposes a table-driven alternative. A stanza defines the symbolic type, its assigned number, flags and field sequence. Software can retrieve the stanza from DNS, or read an optional local file, and use it to parse human-friendly master-file syntax into binary RDATA. The reverse path can turn transferred zone data back into readable records. Provisioning tools can generate forms and reject malformed input.

That is useful compression of implementation work. It does not eliminate implementation. It relocates part of it from compiled releases into data that a parser interprets.

Two names describe one type, until they do not

The proposed publication design gives every stanza two lookup paths. One TXT record is named by the numeric type below RRTYPE.ARPA; another is named by the symbolic type below RRNAME.ARPA. The draft says they are identical, or one may be a CNAME to the other. Language-prefixed variants can carry localized human descriptions, while an unprefixed record remains the default.

This is convenient for discovery from either direction. It is also the first reconciliation boundary. If both names are independent RRsets, clients can observe different generations during an update. One cache can hold an older numeric definition while another has refreshed the symbolic definition. A language-specific record can move before the default alias. The draft says the records are identical but does not specify which one wins if they are not.

The directory text exposes the same unfinished edge. The prose places the list at _LIST.RRTYPE.ARPA; its example names _LIST.RRNAME.ARPA. That is a correctable draft inconsistency, not an operational choice that each implementation should silently make. Until later text closes it, a client needs to record which name it queried and must not treat discovery as proof that a consistent definition exists.

Ordinary DNS caching adds time to this authority problem. TTL tells a consumer when to refresh; it does not make every cache switch versions at once. RFC 8767 also defines carefully bounded conditions under which a resolver may retain and serve stale data after authoritative refresh fails. This does not mean the extension-language draft requires stale use. It means a deployment receipt must be able to distinguish authoritative current data, live cached data and a stale fallback rather than reducing all three to “fetched from DNS”.

The optional local file is a fourth version surface. It is explicitly useful for debugging and overrides. That local choice is valuable: an operator should not need a central publication event to test or contain a fault. But the override must have a visible hash and precedence rule. Otherwise two servers with the same software version and the same DNS answer can execute different schemas while their dashboards report the same input.

DNSSEC authenticates an RRset, not a decision

The draft's security section identifies spoofed imported definitions as a threat and DNSSEC as one defense. The wording is appropriately narrow. RFC 4033 describes DNSSEC as origin authentication and data integrity for DNS RRsets, linked to trust anchors and authentication chains. A secure validation result supports the claim that the signed zone published those bytes and that they were not altered undetectably on the way to the validator.

It does not certify the semantics of a field declaration. It does not compare the numeric and symbolic copies. It does not say that an implementation recognizes every field type, that length arithmetic is safe, that a database adapter preserves ordering, or that the operator meant to activate the result. The validator's local trust policy is itself part of the evidence.

Calling a validated stanza “trusted code” therefore collapses three separate acts. Publication identifies an asserted definition. Authentication establishes provenance and integrity. Activation grants the definition influence over a running service. Each act has a different authority and a different failure mode.

This is not an argument for ignoring DNSSEC. An unauthenticated remote schema is the weaker starting point. It is an argument for making the signature do exactly the job it can prove, so the remaining checks cannot hide behind it.

The X flag is a stop sign, not a plug-in

The proposal marks an RRTYPE with X when it needs extra server processing, citing DNAME and DNSSEC as examples. The purpose is to let a server reject a zone containing such a type when it lacks the required behavior. Other flags say whether the type applies only to the IN class or any class, and whether it is obsolete or experimental.

These flags are declarations. X does not deliver executable logic. It does not identify the module, version or conformance tests that satisfy the requirement. A server can understand the record's wire shape while remaining unable to perform its type-specific function. The safe result is a bounded error, not a green “schema loaded” state.

The boundary already has a useful precedent. RFC 3597 requires unknown types to be handled transparently and defines the generic TYPEnn \# length hex master-file representation. Unknown types receive no additional-section processing. A new specification may define type-specific processing, but only a server that knows the type can perform it. The extension language therefore improves human syntax, templates and table-driven conversion; it does not invent the ability to carry opaque unknown RDATA, and it cannot turn generic carriage into special behavior.

This baseline gives an operator a safe fallback. If the readable schema cannot be reconciled or the server lacks a required capability, the data may still be represented in RFC 3597 form where appropriate. Refusing the friendly syntax is not the same as losing the record.

Parsing is an execution boundary

The draft itself warns that accidentally or deliberately invalid field definitions could trigger unusual bugs in server or provisioning software that fails to check syntax before use. It also notes that a language capable of representing arbitrary records can undermine restrictions in a provisioning system.

Those warnings point beyond grammar. A parser consumes counts, lengths, encodings, names, qualifiers and potentially large user inputs. A form generator turns descriptive data into an authorization surface. A database adapter maps a shared stanza into a product-specific schema that the draft deliberately does not define. A zone loader may accept the text while a signer, dynamic-update path or AXFR exporter handles it differently.

The practical response is not a universal central policy. It is a staged execution path tied to the implementation that bears the risk. Parse in an isolated process with explicit resource limits. Exercise accepted and rejected vectors. Convert master text to wire bytes and back. Load a canary zone that cannot affect public answers. Query the authoritative server, capture the returned RDATA and compare it with the expected bytes. Test export, reload and rollback. Only then should the same definition become eligible for a production scope.

A schema that passes on one implementation has not passed on another. Even the same product may have different parsers across versions, packaging options or storage back ends. The receipt must name the binary and the adapter, not just the RRTYPE.

A twelve-part receipt for one definition

The smallest credible activation record links publication to observed behavior:

Receipt element Evidence to retain Claim it cannot make alone
Draft state Revision, date, Datatracker status Standards-track adoption
Discovery Directory answer and lookup names Definition consistency
Reconciliation Hashes of numeric, symbolic and language variants Parser compatibility
Authentication DNSSEC state, trust policy and chain result Semantic correctness
Freshness Authoritative source, TTL, cache age, stale indicator Fleet convergence
Override Local-file path, hash and precedence Central equivalence
Capability Server, parser and field-vocabulary versions Successful conversion
Special processing Named module for every X requirement Correct configuration
Conformance Positive, negative and resource-limit vectors Serving outcome
Conversion Master-to-wire and wire-to-text bytes Authoritative load
Canary Isolated load and query readback Production activation
Activation Scope, operator decision, health result and rollback Business outcome elsewhere

The table is an editorial operating model, not language from the draft. Its purpose is to prevent one valid artifact from borrowing the authority of the next. A DNSSEC result should not stand in for a parser test. A parser test should not stand in for a loaded zone. A loaded zone should not stand in for a returned answer. A returned answer should not authorize fleet-wide activation.

The same separation makes faults repairable. A mismatch between the two published names belongs to reconciliation. An unknown field token belongs to capability admission. A failed round trip belongs to conversion. A valid canary followed by a failed public reload belongs to deployment. When all failures are called “RRTYPE support”, rollback becomes guesswork.

Central publication can stay thin

The attractive part of the proposal is that one portable description can reduce duplicated software work. That benefit survives without making the publication point an execution authority. The common layer needs a stable grammar, unambiguous name and number binding, field semantics, language behavior, registry process and testable interoperability invariants. Product-specific storage, rollout timing, resource limits and special processing can remain local.

This is the narrow coordination line in Heng Lu's minimum-initial-specification doctrine. Centralize what must be common for exchange. Leave later decisions close to the operator until interoperability requires otherwise. Adoption is meaningful when running systems can prove the result, not when a registry has made refusal socially awkward.

The architecture also protects experimentation. An implementer can use a local stanza to prototype support. A provisioning vendor can generate a form before every authoritative product ships a friendly parser. An operator can continue to use RFC 3597 generic notation. Those paths can coexist if their outputs are observable and their claims remain bounded.

What must not coexist invisibly are different schema generations presented as one state. The receipt is less about bureaucracy than about naming the active bytes. Without that identity, a remote update can alter parser behavior across a fleet at cache-dependent times, and an incident team may be unable to reconstruct which definition each server executed.