SVCB & HTTPS
Record Lookup.

What these records are for

Before a browser can fetch a page it has to make several guesses: which IP address to try, whether the server speaks HTTP/3 or only HTTP/2, and which port. Traditionally it discovers those by trying, failing, and retrying — an A lookup, then a connection, then an upgrade negotiated inside the connection.

SVCB and HTTPS records, standardised in RFC 9460, move that information into DNS so the client knows it up front. The HTTPS record is the web-specific form, and modern browsers query it automatically alongside the A and AAAA lookups. The SVCB record is the generic form for other protocols.

The practical effect is a faster first connection and, when ech is present, a private one.

Reading a record

The format is compact and reads like this:

1 . alpn=h3,h2 ipv4hint=104.16.132.229 ipv6hint=2606:4700::6810:84e5

The first number is the priority. Zero has a special meaning — it makes the record an alias, pointing at another name much as a CNAME would, and it must not carry parameters. Any other number means the record describes a usable endpoint, and lower numbers are preferred.

The second field is the target. A lone dot is not an empty value or a mistake: it means "this same name", which is the common case. Anything else is a different hostname to connect to.

Everything after that is key/value parameters. This tool names each one in plain language rather than leaving you to look them up.

The three findings that actually change behaviour

alpn containing h3. The endpoint advertises HTTP/3. Without a record saying so, a browser generally reaches HTTP/3 only after connecting over HTTP/2 and being told to upgrade — so publishing it removes a round trip from the very first visit.

ech. An Encrypted Client Hello configuration. Ordinarily the hostname you are asking for travels in the clear during the TLS handshake, visible to anyone on the path even though everything after it is encrypted. ECH closes that gap, and the key to do it is published here.

ipv4hint and ipv6hint. Addresses to try immediately, saving a separate lookup. These are hints, not authority — a client is free to do the A/AAAA lookup anyway, and should if the hints fail.

What "no records" means

Most domains still publish nothing here, and that is unremarkable rather than a fault. These records are opt-in, relatively new, and largely deployed by CDNs and large operators so far. A site without them works exactly as it always did.

This tool distinguishes two different empty answers, because they mean different things when you are debugging a zone. No records means the name resolves but publishes nothing of this type. NXDOMAIN means the name does not exist at all — which, if you did not expect it, is the more interesting result.

The apex problem these records quietly solve

There is a long-standing awkwardness in DNS: you cannot put a CNAME at the apex of a zone. www.example.com can be a CNAME pointing at a CDN, but example.com itself cannot, because the apex must carry SOA and NS records and a CNAME is not allowed to coexist with anything else at the same name.

Providers have worked around this for years with proprietary inventions — ALIAS records, ANAME records, flattened CNAMEs — all of which mean the DNS provider quietly resolves the target for you and answers with an address. It works, but it is provider-specific, it hides where the answer actually came from, and it re-resolves on the provider's schedule rather than the client's.

An SVCB record in AliasMode — priority zero, pointing at another name — is the standardised answer to the same problem. It is allowed at the apex, it means what it says, and every client that understands it follows the same rules. If you see a priority-0 record on a bare domain, that is very likely what it is doing.

Publishing one

In a conventional zone file an HTTPS record looks much like any other, with the type name followed by the presentation format this tool displays:

example.com. 300 IN HTTPS 1 . alpn="h3,h2"

That single line tells a browser it can go straight to HTTP/3. Most managed DNS providers now expose the type in their UI, though some still require the numeric form (TYPE65) with the value supplied as raw bytes — if your provider only offers that, it is worth checking whether they have added native support before hand-encoding anything.

Start minimal. An alpn parameter alone is useful and hard to get wrong. Address hints are an optimisation you should add only if you are confident they will be kept in step with your A and AAAA records, because a stale hint sends clients to an address you no longer serve — they will recover, but you have made the first connection slower rather than faster, which is the opposite of the point.

What Encrypted Client Hello does and does not hide

ECH is the most interesting thing these records carry, and it is also the most over-claimed, so it is worth being precise.

In an ordinary TLS handshake the client announces which hostname it wants in the clear, before encryption begins, so the server knows which certificate to present. Anyone watching the connection sees that name. ECH encrypts that portion of the handshake using a public key published — here — in DNS.

What it hides is the hostname. What it does not hide is the IP address you connected to, the timing and size of your traffic, or the DNS lookup itself unless that lookup was also encrypted. On a CDN where thousands of sites share an address, hiding the hostname genuinely obscures which site you visited. On a server hosting one site, the address alone still identifies it, and ECH buys you much less.

It also only works if both ends support it. A client that does not understand ECH simply proceeds without it, and nothing breaks — which is the general pattern for everything in these records.

When a client does not understand them

Every parameter here is advisory. A resolver or client that has never heard of SVCB ignores the record and falls back to the ordinary A and AAAA lookups, exactly as it always did. Publishing these records cannot break an older client, which is why adding one is a low-risk change.

The one exception is the mandatory parameter, and it exists precisely to handle this. It lists other parameters a client must understand for the record to be usable; if the client does not recognise one of them, it is required to ignore the whole record rather than act on a partial reading. This tool flags a mandatory list that names a parameter the record does not actually set, because that combination makes the record unusable to a correct client while looking perfectly fine to a human reading it.

Common questions

Do I need these records? Only if you want the benefits above. If your site is behind a CDN, the CDN most likely publishes them for you already — look one up and see. If you run your own origin, adding an HTTPS record is a small win and a prerequisite for ECH.

Why does the tool query two types? A zone can publish SVCB without HTTPS or the other way around. Checking only the web-specific type would report "nothing here" for a zone that publishes the generic one, which would be wrong in a way that is hard to notice.

The record shows a target of just a dot. Is it broken? No — that is the normal, most common form. It means the record describes the same name it is published on.

Can these records be spoofed? In an unsigned zone, yes, like any DNS answer. That is the argument for DNSSEC, and it matters more here than for most record types because these ones steer the connection itself. Our DNSSEC checker tells you whether the zone is signed.

Why is a parameter shown that you do not explain? The parameter registry grows, and this tool shows every key the zone publishes rather than only the ones it recognises. An unrecognised key is displayed verbatim and marked as such — hiding it would misrepresent what is actually in DNS.

If you are auditing a zone more broadly, the DNS record lookup covers the conventional record types and the DNSSEC checker covers whether any of it can be trusted in transit.