Inputs
Example
example.com HTTPS 1 . alpn=h3,h2 ipv4hint=192.0.2.1 -> ServiceMode, ALPN set, hints versus A records, published-record findings.
llms.txt Validator
Check and generate HTTPS and SVCB service binding records with RFC 9460 validation, ECH decoding and a clear line between published records and connectivity.
Use it before publishing or debugging HTTPS and SVCB records, ECH configurations and HTTP/3 advertisements.
What an HTTPS record tells a client before it connects
HTTPS and SVCB records (RFC 9460) let a client learn from DNS alone where and how to connect: an alias for a zone apex, alternative endpoints with priorities, supported ALPN protocols such as h3, a non-default port, address hints and an Encrypted ClientHello configuration. Browsers use them to go straight to HTTP/3, to upgrade http:// links like an HSTS redirect, and to protect the server name with ECH.
The format is compact and unforgiving: keys must be unique and strictly ordered on the wire, some keys require others, and a single malformed record makes clients discard the whole set. This checker parses records from DNS or from your zone file, validates them against RFC 9460 and the companion specifications for ECH, DNS-over-HTTPS paths and Oblivious HTTP, and generates records together with their wire and generic forms.
Checking a published service binding
For a live check, enter the origin host — a URL works too, and a port other than 443 selects the _port._https name automatically. The tool follows CNAMEs and AliasMode records with the same record type, lists every ServiceMode record with its effective target, ALPN set, port, hints and ECH configuration, and resolves the A and AAAA records of each target so you can compare them with the hints.
Before publishing, paste the planned records or build one with the generator, then fix every error: duplicate or unknown keys, no-default-alpn without alpn, mandatory keys that are missing, empty hint lists or an invalid port. Warnings point to choices that work but can surprise, such as ports browsers refuse or hints that disagree with the A records.
Published in DNS is not the same as reachable
This tool reads DNS; it does not open a single connection to the endpoints it finds. A valid record proves that the binding is published as written, not that the server speaks h3 on that port, holds the ECH key, or answers at the hinted addresses — check the live service separately, for example with the TLS Configuration Checker. Answers come from a recursive resolver, and AD reflects only that resolver's DNSSEC validation.
Frequently asked questions
What is the difference between AliasMode and ServiceMode?
Priority 0 is AliasMode: it points the whole service at another name, which is how a zone apex can alias without a CNAME. Priority 1 or higher is ServiceMode: each record describes one endpoint with its parameters, and lower numbers are preferred.
Why does a record with TargetName "." still work?
In ServiceMode, "." means the owner name itself is the endpoint. In AliasMode, "." says the service is not available.
Do I still need A and AAAA records?
Yes. Clients that do not support HTTPS records ignore them, and supporting clients resolve the target's A and AAAA records anyway; hints are only a shortcut and are ignored once real addresses are known.
What happens if one record is malformed?
Clients must discard the entire RRset and connect as if no HTTPS record existed, which also silently disables ECH. That is why the checker treats wire-format errors as blocking.
Why does the tool warn about some ports?
Browsers apply the Fetch bad-port list to the port parameter and will not connect to ports such as 25 or 6667, even if the record is otherwise valid.
Does an HTTPS record replace HSTS?
For clients that query it, it acts like an HSTS-style upgrade: http:// requests are upgraded to https://, and certificate errors may no longer be bypassable. It is not preloaded and depends on DNS, so keep HSTS where you rely on it.