Question 1

What is a DNS HTTPS Record (Type 65 / RFC 9460) and what problems does it solve?

Accepted Answer

The DNS HTTPS record (Resource Record Type 65) is a next-generation standard standardized in RFC 9460 (a specialized form of SVCB for HTTPS):

① Consolidated Protocol Discovery & IP Resolution:
Historically, clients queried A/AAAA records first and negotiated HTTP/2 or HTTP/3 later via Alt-Svc headers. HTTPS records allow clients to retrieve IP addresses, supported application protocols (ALPN), custom ports, and ECH public keys in a single initial DNS lookup.

② Apex Domain Aliasing:
Overcomes the classic RFC 1034 limitation prohibiting CNAME records at the domain root (Zone Apex).

Question 2

What is the difference between Service Mode and Alias Mode in HTTPS records?

Accepted Answer

The behavior is governed by the SvcPriority field:

① Alias Mode (Priority = 0):
When SvcPriority is 0, the record acts as a CNAME-like alias to a TargetName. It safely functions at the domain root (Zone Apex) while directing the client to query HTTPS records at the target.

② Service Mode (Priority ≥ 1):
Lower priority numbers take precedence. In this mode, developers can bind SvcParams (such as `alpn="h2,h3"`, `port=8443`, `ipv4hint`) instructing the client to initiate the optimal connection directly.

Question 3

How does an HTTPS record accelerate HTTP/3 (QUIC) and eliminate 0-RTT negotiation delays?

Accepted Answer

Speed gains stem from upfront protocol knowledge during DNS resolution:

① Eliminating Alt-Svc Round Trips:
Previously, first-time visitors connected over TCP/TLS first and only discovered HTTP/3 after receiving an `Alt-Svc: h3=":443"` header from the origin server.

② Direct UDP QUIC Handshake:
With `alpn="h3,h2"` declared in the DNS HTTPS record, modern browsers (Chrome, Safari, Firefox) immediately initiate UDP QUIC on the very first packet, saving a full round-trip delay.

Question 4

What are `ipv4hint` and `ipv6hint`, and how do they improve latency?

Accepted Answer

IP Hint parameters provide cached IP hints inside the HTTPS record payload:

① Reducing Extra DNS Round-Trips:
When the TargetName points to an external CDN hostname, clients typically require secondary A/AAAA lookups. `ipv4hint` and `ipv6hint` supply fallback IP addresses for immediate concurrent connection attempts.

② Strict Security Compliance:
RFC 9460 mandates that clients still asynchronously validate authoritative A/AAAA records, preserving both low latency and DNS integrity.

Question 5

How does the HTTPS record enable Encrypted Client Hello (ECH) privacy protection?

Accepted Answer

ECH represents a major TLS 1.3 privacy enhancement:

① Masking the Server Name Indication (SNI):
Traditional TLS handshakes expose the requested domain name in plaintext Client Hello packets, enabling eavesdroppers and transit ISPs to inspect browsing habits.

② Distributing ECH Keys via DNS:
Origin servers publish their cryptographic public keys via the `ech="Base64..."` SvcParam. The browser encrypts the entire inner Client Hello before transmission, completely sealing SNI leaks.

Question 6

Why can HTTPS records be configured at the Root Domain (Zone Apex) where CNAME fails?

Accepted Answer

It resolves a fundamental DNS specification conflict:

① CNAME Exclusivity Rule:
DNS standards require SOA and NS records at the root domain (`example.com`), and CNAME records cannot coexist with any other record type.

② Alias Mode Compatibility:
As an independent record type, Priority 0 HTTPS Alias records comfortably coexist with SOA, NS, and MX records, offering standard cross-provider root aliasing.

Question 7

How do Cloudflare, AWS Route 53, and BIND 9 differ when creating HTTPS records?

Accepted Answer

DNS providers accommodate HTTPS records across varying interface designs:

① Cloudflare DNS:
Provides a dedicated 4-field modal (Name, Priority, Target, Value/SvcParams) for structured entry.

② AWS Route 53:
Allows pasting the full RFC 9460 presentation parameter string directly into the single value field (e.g. `1 . alpn="h2,h3"`).

③ BIND 9 / NSD Zone Files:
Standard single-line record format: `@ IN HTTPS 1 . alpn="h2,h3" ipv4hint=203.0.113.1`. This generator provides copy-ready syntax for all target environments.

Question 8

Why do some raw DNS responses look like hex or gibberish, while this tool displays them normally?

Accepted Answer

Difference between wire format encoding and RFC 9460 presentation parsing:

① Wire Format vs Unknown RR Types:
Under RFC 9460, HTTPS records (Type 65) transmit binary Key-Value pairs. Older DNS resolvers or legacy command-line tools (such as un-updated `dig TYPE65`) lack native Type 65 parsers, falling back to RFC 3597 unknown record output (e.g. `\# 22 00010000010005026832...`) which looks like garbled hexadecimal data.

② Native RFC 9460 Presentation Decoder:
This tool features a built-in RFC 9460 parsing engine that decodes raw binary attributes into human-readable parameters (ALPNs, IP Hints, ECH keys) and formats them for major cloud providers.

DNS HTTPS Record (Type 65) Generator

DNS Admin Panel [4 Core Fields] Breakdown

DNS Provider Tutorials & Guides

Frequently Asked Questions (FAQ)8 Q&As