Summary

  • ARIN’s public Delegation Key payload guide labels digest type 3 as MD5 and gives its “Digest Length” as 32. IANA assigns DS digest type 3 to GOST R34.11-94, now deprecated. These are different meanings for the same field value.
  • The guide leaves the length unit unstated. GOST’s 256-bit digest occupies 32 octets or 64 hexadecimal characters; that distinction does not establish what ARIN’s live API accepts or rejects.
  • Current IANA recommendations and RFC 9906 say MUST NOT in all four use and implementation columns for type 3. Correcting its name is not permission to deploy it. No API, zone or resolver was tested for this article.

The number is not a nickname

In ARIN’s public payload reference, the third digest type is remarkably concise: “MD5”, followed by a digest length of 32. In IANA’s registry, the same DS digest type number identifies GOST R34.11-94. One can reconcile differing punctuation or translated descriptions. One cannot reconcile two different cryptographic functions by treating their common number as a matter of presentation.

The mismatch is in the Delegation Key section of the Reg-RWS payload documentation, captured on 14 September 2026. That section describes fields inside a Delegation Payload. Its table lists SHA1 for type 1, SHA256 for type 2, MD5 for type 3 and SHA384 for type 4. The corresponding lengths are 40, 64, 32 and 96. This is a finding about a publicly accessible reference, not a report that ARIN generated or published an MD5-derived DS record.

The authoritative comparison is unusually direct. IANA’s DS digest registry assigns type 3 to GOST, marks it deprecated and refers to RFC 5933 and RFC 9906. The original assignment in RFC 5933 also identifies digest type 3 as GOST R34.11-94. Deprecation changes the recommendations for using a registered identifier; it does not quietly reassign the identifier to MD5.

Why does this small row matter? A DS record carries a numeric digest type together with digest data. The number tells a reader which function the data represents. A friendly label may help a person choose or inspect a value, but the label does not define a private version of the protocol. If a developer followed the MD5 label when constructing data for type 3, the resulting pairing could be incompatible with the registered meaning. That is a conditional consequence, not an observed event in an ARIN-managed delegation.

Two algorithm fields, two namespaces

The reference contains a second opportunity for confusion. Its Delegation Key has both an algorithm and a digestType. The algorithm catalogue lists values including 5, 7, 8, 10, 13, 14, 15 and 16, with familiar RSA, ECDSA and EdDSA names. That catalogue concerns the DNSKEY algorithm. The digest table concerns the function used for the DS digest. Neither list supplies the meaning of a number in the other.

RFC 4034 describes the distinction at the wire level. The DS digest type identifies the algorithm used to construct the digest. The digest calculation includes the canonical DNSKEY owner name followed by the DNSKEY record data: flags, protocol, algorithm and public key. It is therefore not simply a hash of whatever public-key string happens to be displayed on a screen. A reference that mixes fields or inputs can mislead without changing the protocol itself.

The original GOST specifications make the separate numbering especially plain. RFC 5933 assigns 12 to the ECC-GOST DNSKEY signature algorithm and 3 to the GOST DS digest. A type-3 DS digest is not a DNSKEY algorithm numbered 3. Nor is it DNSKEY’s protocol field containing 3, or a key tag containing that number. The repeated integer is incidental; the field’s namespace gives it meaning.

ARIN’s documentation says the names for its algorithm and digest type are determined from entered numeric values, and that supplied names are discarded. Taken as a description of the intended interface, this makes the field map particularly important: changing an entered descriptive name would not override the number. It does not, by itself, demonstrate the name returned by the deployed service, the validator’s checks or any stored delegation. Those questions require different evidence.

Thirty-two what?

The adjacent length entry deserves a separate finding, not an exaggerated extension of the first. ARIN calls the column “Digest Length” without stating its unit. Its other entries—40 for SHA1, 64 for SHA256 and 96 for SHA384—are consistent with hexadecimal-character counts. That pattern supplies a plausible reading of 32; it is not an explicit declaration that the service enforces a 32-character limit.

RFC 5933 specifies a 256-bit GOST digest. There are eight bits in an octet and two hexadecimal characters per octet. The same value therefore occupies 32 octets and, in hexadecimal presentation, 64 characters. RFC 4034’s DS presentation format expresses the digest as case-insensitive hexadecimal; it also allows whitespace. Counting a formatted text string and counting its underlying octets are not interchangeable operations.

If ARIN’s column is intended to count hexadecimal characters, 32 would not describe the GOST digest registered under type 3. If it is intended to count octets, 32 would describe GOST’s size, but the neighbouring entries would need a different explanation. The public table does not resolve that question. A responsible correction would specify the unit and the treatment of formatting rather than leave readers to infer an undocumented acceptance rule.

This distinction also prevents a tempting but unsupported headline. The documented length does not prove that an upload of a 64-character GOST digest fails. It does not prove that a 32-character string succeeds. It says nothing sufficient about decoding, validation order, error reporting or storage. A documentation discrepancy can justify asking for those answers without pretending that they have already been obtained.

A correct historical name is not a current recommendation

There is another limit on the proposed correction. Replacing MD5 with GOST would repair the identifier’s description, but it would not make digest type 3 a recommended choice for a new delegation. RFC 9906, published in November 2025, retires ECC-GOST and GOST R34.11-94 from DNSSEC use. The current IANA row says MUST NOT for use in delegation, use in validation, implementation for delegation and implementation for validation.

Older material is easy to misread here. RFC 5933 originally described optional implementation. That historical text explains the assignment; it does not supersede the later retirement. A maintenance note should preserve the number’s historical meaning and attach its current status. It should not convert a reference-table repair into instructions to generate or validate new GOST material.

The distinction is practical. A catalogue can describe identifiers that an operator encounters while inspecting, editing or removing old configuration. That descriptive role need not endorse their creation. This article has not tested whether ARIN supplies any such compatibility or removal path. It argues for keeping identification, current recommendation and observed service behaviour in separate columns of the operator’s understanding, whether or not a particular interface displays literal columns.

RFC 9906 also distinguishes a retired-only validation path from a demonstrated bad signature. Where no other acceptable authentication path exists, its prescribed treatment is insecure, rather than using the retired algorithms to classify the chain as bogus. Neither term is a synonym for an unreachable domain. There is no basis here for describing an ARIN reverse zone, a particular customer or a deployed resolver as having any of those conditions.

A parent-side field, not the whole DNS service

ARIN’s reverse-DNS guidance supplies the operational setting. After securing a reverse zone, an operator can signal the parent with DS data and manage it per delegation through ARIN Online or the RESTful provisioning service. The documented payload therefore sits at a real boundary between a child zone’s key material and the parent’s description of that material.

That boundary is important precisely because it is limited. Managing parent DS data is not the same activity as signing the child zone, publishing its DNSKEY records or operating every resolver that may validate it. The public guide cannot establish the state of all those systems. A wrong field label may travel into a client’s understanding; it does not establish that the mistake travelled through every operational boundary into a public DNS answer.

The evidence supports a narrow request: reconcile the public digest-type map with its registered meaning, state the length unit and describe current treatment of retired identifiers. It supports a separate request for dated, reproducible acceptance and error evidence if runtime behaviour is disputed. It does not support deleting existing DS material as a precaution, attempting an untested rollover or changing ARIN’s address-allocation powers.

Sources

  • ARIN’s Reg-RWS payload reference: the Delegation Key fields, name-handling description and digest-name/length table.
  • IANA’s DS digest-type registry: the registered meaning of type 3 and its current recommendation columns.
  • RFC 5933: the original distinct GOST assignments and 256-bit digest specification; historical use recommendations are superseded.
  • RFC 9906: the November 2025 retirement and prescribed validation treatment.
  • ARIN’s reverse-DNS guidance: the parent-DS provisioning context, not evidence of any particular zone’s state.
  • RFC 4034: DS field semantics, digest inputs and hexadecimal presentation, not current algorithm-selection advice.