SVCB / HTTPS Record Builder & Decoder

SVCB (type 64) and its web-specific twin HTTPS (type 65) are the DNS records that carry what used to need a CNAME plus out-of-band knowledge: which ALPN protocols a service speaks, which port, which address hints, and the encrypted client hello configuration that makes ECH work. They share one wire format, and almost everything that goes wrong with them is a format detail that looks fine until something else parses it. This page normalises a record, encodes it, breaks the bytes down, and names each rule it breaks with the section that says so.

The first thing to get right is the mode. Priority 0 is AliasMode: the target is an alias and not one SvcParam is permitted. Priority 1 or higher is ServiceMode, where lower numbers are tried first and equal numbers may be load-balanced. A record with priority 0 and an alpn on it is not a record with an extra field, it is invalid, and this page says so rather than quietly encoding it.

The second is ordering. On the wire, SvcParamKeys must appear in ascending numeric order and none may repeat; in presentation format the order is free. So 1 . port=443 alpn="h2" and 1 . mandatory=port,alpn alpn="h2" port=443 both encode to bytes with key 0 first, then 1, then 3 — and the normalised text this page prints comes back sorted. If a zone file and a dig answer disagree about the order, neither is wrong.

The third is escaping, and it catches nearly everyone, because comma-separated values pass through two layers. The presentation value is first unescaped as an RFC 1035 character string, where a backslash escapes the next character and a three-digit \DDD is one byte; then the result is split on commas, where a backslash escapes a comma. So alpn="h2\,h3" is two protocols — the first layer eats the backslash, the second sees a plain separator — while alpn="h2\\,h3" is the single protocol named h2,h3. There is no \xNN escape either: alpn="h2\x2ch3" is one protocol called h2x2ch3.

Smaller edges the page handles rather than hides. The target name is never DNS-compressed inside SVCB rdata, so it always appears in full. An unknown key may be written bare or with an empty value, and key65535 and key65535="" are the same four bytes. mandatory must not list itself, must not name a key that is absent, and comes back sorted. no-default-alpn without an alpn is invalid. And an IPv6 hint only prints with a dotted tail when the address really has an embedded IPv4 one — a zero run of exactly six groups, or five followed by ffff — which is why ::0.0.0.1 comes back as ::1 while ::192.0.2.1 keeps its dots.

What the page cannot tell you is whether the record works. Address hints are hints: RFC 9460 keeps A and AAAA records necessary, and a resolver is free to ignore the hint entirely. An ech value is checked as base64 and nothing more — whether the key inside it matches the server is a TLS question, not a DNS one. And a syntactically perfect HTTPS record still does nothing if the name it sits on is not the one clients look up.