Shared wire-format representation for DNSSEC delegation-signer records: the parent-side DS record (RFC 4034 section 5.1) and the child-side CDS announcement (RFC 7344 section 3.1). The type parameter n (either N_ds or N_cds) determines the RR type. Each has its own type synonym (T_ds, T_cds) and matching record pattern synonym (T_DS, T_CDS) with the corresponding field-name prefix (ds, cds). The wire format is identical and the type role of n is phantom, so T_ds and T_cds are mutually coercible — useful for promoting a child-side CDS announcement into a parent-side DS without rebuilding the value.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Key Tag             |  Algorithm    |  Digest Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                            Digest                             /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

No embedded domain field, so derived Ord agrees with the canonical wire-form octet ordering (RFC 4034 section 6.2).

The record pattern synonyms T_DS and T_CDS build the corresponding T_ds or T_cds value directly, with their own field-name prefixes (ds and cds):

:set -XOverloadedStrings
let ds  = T_DS  { dsKtag  = 12345
                , dsKalg  = 13
                , dsHalg  = 2
                , dsHval  = coerce @Bytes16 "0001...1e1f" }
    cds = T_CDS { cdsKtag = 12345
                , cdsKalg = 13
                , cdsHalg = 2
                , cdsHval = coerce @Bytes16 "0001...1e1f" }
 in RData ds : RData cds : []

Functions that work on either RR type can use the underscore-prefixed selectors on the shared X_ds record:

hashTypeVal :: forall n. X_ds n -> (Word8, ShortByteString)
hashTypeVal = (,) <$> _dsHalg <*> _dsHval

X_ds specialised to DS records.

X_ds specialised to CDS records.

Shared wire-format representation for DNSSEC signing-key records: the DNSKEY record (RFC 4034 section 2) published at the child zone apex, the CDNSKEY child-side announcement (RFC 7344 section 3.2) of which KSKs the parent should reference, and the legacy KEY record (RFC 2535 section 3.1) still used by SIG(0) transaction authentication and otherwise effectively unused in modern deployments. The type parameter n (one of N_key, N_dnskey, N_cdnskey) determines the RR type. Each has its own type synonym (T_key, T_dnskey, T_cdnskey) and matching record pattern synonym (T_KEY, T_DNSKEY, T_CDNSKEY) with the corresponding field-name prefix (key, dnskey, cdnskey). The wire format is identical across all three and the type role of n is phantom, so the types are mutually coercible; the practical pairing is DNSKEY <-> CDNSKEY (mirroring DS <-> CDS).

                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              Flags            |    Protocol   |   Algorithm   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 /                                                               /
 /                            Public Key                         /
 /                                                               /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

No embedded domain field, so derived Ord agrees with the canonical wire-form octet ordering (RFC 4034 section 6.2).

The record pattern synonyms build the corresponding type directly, with their own field-name prefixes:

:set -XOverloadedStrings
let dk  = T_DNSKEY  { dnskeyFlags  = 257
                    , dnskeyProto  = 3
                    , dnskeyAlgor  = 13
                    , dnskeyValue  = coerce @Bytes64 "3FOs...Kw==" }
    cdk = T_CDNSKEY { cdnskeyFlags = 257
                    , cdnskeyProto = 3
                    , cdnskeyAlgor = 13
                    , cdnskeyValue = coerce @Bytes64 "3FOs...Kw==" }
 in RData dk : RData cdk : []

Functions that work on any of the three RR types can use the underscore-prefixed selectors on the shared X_key record:

keyAlgVal :: forall n. X_key n -> (DNSKEYAlg, ShortByteString)
keyAlgVal = (,) <$> _keyAlgor <*> _keyValue

X_key specialised to KEY records.

X_key specialised to DNSKEY records.

X_key specialised to CDNSKEY records.

Compute RFC 4034, Appendix B key tag over the DNSKEY RData: 16 bit flags, 8 bit proto, 8 bit alg and key octets.

With the obsolete algorithm 1 we assign key tag 0 to truncated keys, but RSAMD5 keys are no longer seen in the wild. We check that the modulus actually has at least 3 octets.

Shared wire-format representation for DNSSEC signature records: the RRSIG record (RFC 4034 section 3) that signs an RRSet, and the legacy SIG record (RFC 2535 section 4.1) and its SIG(0) transaction-authentication use (RFC 2931 section 3). The type parameter n (either N_sig or N_rrsig) determines the RR type. Each has its own type synonym (T_sig, T_rrsig) and matching record pattern synonym (T_SIG, T_RRSIG) with the corresponding field-name prefix (sig, rrsig). The wire format is shared, but the type role of n is nominal: a T_sig value cannot be used where a T_rrsig is expected. This is deliberate — SIG(0) signs a single transaction while RRSIG signs an RRSet, and conflating them at the type level would be unsafe.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type Covered           |  Algorithm    |     Labels    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Original TTL                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Signature Expiration                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Signature Inception                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Key Tag            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         +
|                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/                                                               /
/                            Signature                          /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As noted in Section 3.1.5 of RFC 4034 the RRsig inception and expiration times use serial number arithmetic. As a result these timestamps are not pure values, their meaning is time-dependent! They depend on the present time and are both at most approximately +/-68 years from the present. This ambiguity is not a problem because cached RRSIG records should only persist a few days, signature lifetimes should be *much* shorter than 68 years, and key rotation should cause any misconstrued 136-year-old signatures to fail to validate. This also means that the interpretation of a time that is exactly half-way around the clock at now +/-0x80000000 is not important, the signature should never be valid.

To avoid ambiguity, these *impure* relative values are converted to pure absolute times as they are received from from the network, and converted back to 32-bit values when encoding. Therefore, the constructor takes absolute 64-bit representations of the inception and expiration times.

The signer zone name is not subject to wire-form name compression (RFC 3597 section 4) and canonicalises to lower case (RFC 4034 section 6.2, confirmed by RFC 6840 section 5.1). The Eq and Ord instances compare the signer name in canonical wire form (via equalWireHost / compareWireHost), giving stable comparison semantics for general use in ordered collections. Canonical RR ordering is not a meaningful concept for RRSIG records — they are never themselves signed — so the canonical-ordering machinery from RFC 4034 §6.2 does not apply to them in practice.

X_sig specialised to RRSIG records.

X_sig specialised to SIG / SIG(0) records.

The IPSECKEY resource record (RFC 4025 section 2.1) — IPsec keying material for a host or subnet.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  precedence   | gateway type  |  algorithm    |   gateway     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+               +
 ~                            gateway                            ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               /
 /                          public key                           /
 /                                                               /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

The gateway type byte selects one of four defined gateway shapes (none, IPv4, IPv6, or FQDN); the gateway field carries the corresponding value, and the trailing public key holds the key bytes.

For future or otherwise unrecognised gateway types (any value outside 0..3) the wire-form boundary between the gateway and the public key is unknown to the parser, so both are kept together as a single opaque blob inside IPSecKeyGWG, and the key component below is then empty.

The constructors are not exported; the only public view is the IPSecKey bidirectional pattern synonym, which exposes a uniform five-argument tuple (precedence, gateway type, algorithm, gateway, public key) regardless of the gateway shape.

Shape of an IPSECKEY record's gateway field. Four cases match the four gateway types defined by RFC 4025; the catchall IPSecKeyGWG covers any future or otherwise unrecognised gateway type byte and holds the gateway and public-key bytes together as a single opaque blob (the parser has no way to find the boundary between them when the shape is unknown).

The ZONEMD resource record (RFC 8976 section 2.2) — a digest of the zone contents, used by recipients of zone transfers to verify zone integrity end-to-end. Four fields: a 32-bit serial number matching the SOA, an 8-bit scheme selector, an 8-bit hash-algorithm selector, and the digest bytes.

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Serial                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Scheme     |Hash Algorithm |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                             Digest                            |
/                                                               /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

No embedded domain field, so derived Ord agrees with the canonical wire-form octet ordering.