Shared wire-format representation for the SVCB service binding record (RFC 9460 section 2) and its HTTPS-specific variant (RFC 9460 section 9). The type parameter n (either N_svcb or N_https) determines the RR type. Each has its own type synonym (T_svcb, T_https) and matching record pattern synonym (T_SVCB, T_HTTPS) with the corresponding field-name prefix (svc, https). The wire format is shared, but the type role of n is nominal: a T_svcb value cannot be used where a T_https is expected. This is deliberate — the two RR types serve different transports, and future SvcParamKeys may apply to only one of them.

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                  SvcPriority                  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                  TargetName                   /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                   SvcParams                   /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The target field is not subject to wire-form name compression (RFC 3597 section 4) and is not in the RFC 4034 section 6.2 list of types that lower-case their RDATA names — it is compared case-sensitively in canonical form. The Ord instance compares structurally on the parsed fields rather than on the wire form, so it is not canonical: callers that need RFC 4034 canonical ordering must serialise to wire form first.

The SvcParams field is a list of (key, length, value) triples — possibly empty — making up the rest of the RData:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                  SvcParamKey                  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                  SvcParamLen                  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                  SvcParamValue                /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

On the wire the list must be in strictly ascending key order; the presentation form may list keys in any order. Each value has the type associated with its key in the decoder state configured for the RR type — keys absent from the state decode as OpaqueSPV, preserving the raw bytes.

The record pattern synonyms T_SVCB and T_HTTPS build the corresponding T_svcb or T_https value directly, with their own field-name prefixes (svc and https):

let s = T_SVCB  { svcPriority      = 0
                , svcTarget        = RootDomain
                , svcParamValues   = [] }
    h = T_HTTPS { httpsPriority    = 0
                , httpsTarget      = RootDomain
                , httpsParamValues = [] }
 in RData s : RData h : []

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

aliasDomain :: forall n. X_svcb n -> Maybe Domain
aliasDomain r | _svcPriority r == 0 = Just $ _svcTarget r
              | otherwise           = Nothing

X_svcb specialised to SVCB records.

X_svcb specialised to HTTPS records.

The class of types representing the value side of a service parameter inside an SVCB or HTTPS record. Each instance corresponds to a specific SVCParamKey; the encodeSPV and decodeSPV methods handle only the value bytes. The surrounding (key, length) frame is owned by the SVCB-record encoder: encodeSPV writes just the payload, and the framework wraps the result in the 2-byte length prefix. For value-less parameters this means encodeSPV is just pure ().

The Presentable instance builds the RFC 9460 zone-file presentation form: the key name followed (where the value is non-empty) by = and the value. The Show instance is typically derived and aims to produce syntactically valid Haskell.

The set of service parameters in an SVCB or HTTPS record, with at most one value per SVCParamKey. The Monoid instance provides the empty set; the Semigroup instance is left-biased on key collisions.

Look up the parameter at the key associated with type a, returning a Just only when the stored value really is of type a. A value of the same key code but held as OpaqueSPV (because the typed instance was not registered when the record was decoded) does not match — opaque values must be retrieved through SPVMap.

The alpn service parameter (RFC 9460 section 7.1) — the set of Application-Layer Protocol Negotiation (RFC 7301) protocol identifiers this service endpoint supports. Together with SPV_ndalpn it defines the SVCB ALPN set: by default the scheme's protocol is implicitly included, and SPV_ndalpn suppresses that default.

The docpath service parameter (RFC 9953 section 8.2) — the absolute path to the DNS-over-CoAP (DoC) resource at this service endpoint, represented as a list of path segments. An empty list denotes the root path "/" (on the wire: a zero-length SvcParamValue).

Each segment is 1..255 octets per the RFC ABNF; the wire-form decoder rejects zero-length segments. Presentation form is a comma-separated list of segments using the standard RFC 9460 Appendix A.1 quoting and escaping rules, identical to those of SPV_alpn.

The dohpath service parameter (RFC 9461) — a URI template (UTF-8) advertising the DNS-over-HTTPS endpoint at this service. Typically seen on resolver-discovery answers to queries for _dns.resolver.arpa or on explicit queries to a specific operator's resolver.

The ech service parameter (RFC9848, Section 3) — an Encrypted Client Hello (ECH) configuration list. Presented as a base64-encoded value.

The ipv4hint service parameter (RFC 9460 section 7.3) — a non-empty list of IPv4 addresses for this service endpoint that a client may use to start a connection in parallel with an authoritative A lookup. Hints are advisory; clients should still validate them against authoritative address records when they arrive.

The ipv6hint service parameter (RFC 9460 section 7.3) — the IPv6 counterpart of SPV_ipv4hint: a non-empty list of IPv6 addresses to try in parallel with the authoritative AAAA lookup.

The mandatory service parameter (RFC 9460 section 8) — the set of additional SVCParamKey codes a client must recognise to make sense of this RR, on top of any keys that are automatically mandatory for the application protocol. A client that does not understand all the listed keys must ignore the RR.

The set may not be empty on the wire (an empty list is encoded as the parameter being absent) and may hold at most 32767 keys. The constructor is not exported; build instances via fromNonEmptyList or by combining values with their Semigroup instance.

The no-default-alpn service parameter (RFC 9460 section 7.1) — a value-less flag that suppresses the scheme's default ALPN from the SVCB ALPN set. Meaningful only alongside an explicit SPV_alpn that supplies a replacement protocol list.

The port service parameter (RFC 9460 section 7.2) — overrides the scheme's default TCP or UDP port for reaching this service endpoint.

The pvd service parameter (draft-ietf-intarea-proxy-config-14 section 7.5) — a value-less flag that announces the host supports Provisioning Domain discovery via the well-known PvD URI. Its presence in an SVCB or HTTPS RR signals that a client MAY fetch PvD Additional Information from https://host/.well-known/pvd. Per the draft, the wire value MUST be empty; the presentation form is just the bare key name with no '='.

The tls-supported-groups service parameter (draft-ietf-tls-key-share-prediction-04 section 5) — a non-empty list of TLS Named Group codepoints (the IANA TLS Supported Groups registry) that the service supports. Clients can use this hint to predict an acceptable key share, reducing the chance of a HelloRetryRequest round-trip.

The wire form is a non-empty sequence of 16-bit codepoints in network byte order; the decoder rejects an empty value. The presentation form is a comma-separated list of decimal integers and forbids zone-file escape sequences (per the draft). Duplicates are flagged as a syntax error by the specification but are not currently rejected by either the encoder or the decoder — callers are expected to feed in a duplicate-free list, in their preferred order (the spec does not impose canonical ordering on the wire).

Extract specific known SVCParamValue from existential wrapping

Build an SVCParamValue from a raw numeric key and a raw byte payload. Useful when a caller has a wire encoding for a key that has no registered KnownSVCParamValue instance, or when round-tripping bytes for keys that should remain uninterpreted.

Key associated with a generic SvcParamValue

Encode an SVCParamValue to its OpaqueSPV equivalent under the same key code. Values that are already opaque are returned unchanged. For typed values this re-encodes the payload to wire form; encoding can fail (for example if the result would be too long to fit a 16-bit length field), in which case the EncodeErr is returned.

The class of types representing the value side of a service parameter inside an SVCB or HTTPS record. Each instance corresponds to a specific SVCParamKey; the encodeSPV and decodeSPV methods handle only the value bytes. The surrounding (key, length) frame is owned by the SVCB-record encoder: encodeSPV writes just the payload, and the framework wraps the result in the 2-byte length prefix. For value-less parameters this means encodeSPV is just pure ().

The Presentable instance builds the RFC 9460 zone-file presentation form: the key name followed (where the value is non-empty) by = and the value. The Show instance is typically derived and aims to produce syntactically valid Haskell.

Fallback carrier for service-parameter values whose key code has no KnownSVCParamValue instance registered. The key code is encoded as a type-level natural so OpaqueSPV values with different codes have distinct types. The wire payload is kept as raw bytes and round-trips losslessly; the presentation form is keyN=... with the value as a DnsText character-string.

Existential wrapper around any KnownSVCParamValue, so a single list can hold a mix of typed service parameters. The present method delegates to the underlying instance, which emits both the key name and the value.

Application-Layer Protocol Negotiation identifiers RFC9460, Section 14.3.2

DNS over CoAP path RFC9953, Section 3

URI template for DNS-over-HTTPS resolver discovery RFC9461, Section 4

Encrypted Client Hello configuration RFC9848, IANA Considerations

Speculative IPv4 address hints RFC9460, Section 14.3.2

Speculative IPv6 address hints RFC9460, Section 14.3.2

Keys the client must understand to use this RR RFC9460, Section 14.3.2

Suppress the default ALPN for this scheme RFC9460, Section 14.3.2

Oblivious HTTP support indicator RFC9540, Section 4

Alternative TCP/UDP port RFC9460, Section 14.3.2

Provisioning Domain RFC-ietf-intarea-proxy-config-14, Section 7.5

TLS supported groups draft-ietf-tls-key-share-prediction-04, section 5

A service-parameter key code (RFC 9460 section 2.1). The pattern synonyms below name the keys that have standardised value formats; an unrecognised code keeps its numeric form and presents as keyN.