DNS records now supports HTTPS and many more DNS records now supports ...

DNS records now supports HTTPS and many more

PRODUCT ANNOUNCEMENT   LAUREN ANDERSON   0 COMMENTS

In our constant efforts to provide the best service, our DNS records system now supports 4 more DNS records: SVCB, HTTPS, OPENPGPKEY and SMIMEA, adding to our existing A, AAAA, CNAME, MX, HINFO, SRV, TXT, SPF, AFSDB, KEY records and web redirect records. If you haven't heard about these records yet, here's a quick explanation:

DNS records

1
SVCB record explained

SVCB (Service Binding) records, standardized in RFC 9460, allow clients to discover how to connect to a network service before a connection is even attempted. Unlike SRV records, SVCB records can carry additional service parameters such as supported application protocols (ALPN), port numbers, and IP address hints — all in a single DNS lookup.

SVCB supports two modes. In AliasMode (priority 0), the record redirects a service name to another domain, similar to CNAME but allowed at the zone apex and scoped to a specific service type. In ServiceMode (priority greater than 0), the record describes a concrete endpoint along with its parameters.

For example, to describe a service reachable at port 8004 supporting the "bar" protocol:

_service._tcp.test.com. SVCB 1 endpoint.test.com. alpn="bar" port="8004"

2
HTTPS record explained

The HTTPS record (DNS RR type 65) is a dedicated variant of SVCB specifically for HTTP and HTTPS origins, also standardized in RFC 9460. It shares the same syntax and modes as SVCB but is queried directly using the origin hostname — no underscore prefix is needed for port 443.

Beyond connection parameters, the mere presence of an HTTPS record signals to clients that the origin supports HTTPS, functioning similarly to HTTP Strict Transport Security (HSTS) but at the DNS level. It also enables apex aliasing to a CDN or hosting provider without relying on CNAME, which is not permitted at the zone apex.

For example, to advertise HTTP/3 (QUIC) support and delegate to a CDN at the apex:

test.com. HTTPS 1 cdn.example.net. alpn="h3,h2"
www.test.com. HTTPS 0 test.com.

3
OPENPGPKEY record explained

OPENPGPKEY records, specified in RFC 7929, allow OpenPGP public keys to be published directly in DNS. This makes it possible for email clients and other applications to automatically retrieve the correct public key for an email address via a DNS query, enabling end-to-end encrypted email without relying on key servers or manual key exchange.

The record is stored under a specially constructed name: the SHA-256 hash of the local part of the email address (truncated to 28 octets), followed by ._openpgpkey. and the domain. The record data contains the raw OpenPGP public key packet.

For example, to publish a key for alice@test.com:

c93f1e400f26708f98cb19d936620da35eec8f72e57f9eec01c18ae4._openpgpkey.test.com. TYPE61 \# [key data]

4
SMIMEA record explained

SMIMEA records, specified in RFC 8162, bind S/MIME certificates to email addresses via DNS. S/MIME is widely used in corporate environments to encrypt and digitally sign email. Publishing the associated certificate in DNS allows recipients to automatically discover and verify the sender's certificate without any out-of-band exchange.

Like OPENPGPKEY, the record name is derived from a SHA-256 hash of the email address's local part (truncated to 28 octets), followed by ._smimecert. and the domain. The record fields specify the certificate usage, selector, matching type, and the certificate data or its hash.

For example, to publish an S/MIME certificate for bob@test.com:

f10e7de079689f55c0cdd6782e4dd1448c84006962a4bd832e8eff73._smimecert.test.com. SMIMEA 3 0 0 [certificate data]

If you have any questions or comments, feel free to contact us or comment!







*
* (Your email address will not be published.)
Loading...