HTTPSレコードとSVCBレコードの完全解説｜ALPN・ECH・HTTP/3のDNS設定

HTTPSレコード DNS — なぜ今必要なのか

WebサイトへHTTPS接続するとき、ブラウザは従来次の順序で情報を集めていた。

1. DNS — example.com の A/AAAA レコードでIPアドレスを取得
2. TCP — 443番ポートへ接続
3. TLS — ClientHelloでSNI（Server Name Indication）を平文で送信
4. ALPN — TLS握手中に h2 / http/1.1 等をネゴシエーション
5. HTTP — レスポンスヘッダーの Alt-Svc: h3=":443" でHTTP/3を後から学習

このフローには2つの非効率がある。

• ALPN情報が遅い — HTTP/3（QUIC/UDP）を使えるかは、TLS完了後のAlt-Svcか、2回目以降の接続まで分からないことがあった
• SNIが平文 — ClientHello内のSNIは暗号化されず、中間者に「どのホストへ接続しているか」が見える

SVCB/HTTPSレコード（RFC 9460, 2018年草案から2023年標準化）は、DNS応答の段階でサービスパラメータを渡す仕組みだ。検索キーワード「HTTPS レコード DNS」「SVCB レコード 設定」で調べるエンジニアが増えている背景は、Chrome・Firefox・Cloudflareが2023〜2024年に本格対応したためだ。

従来のDNSとHTTPSレコードの位置づけ

[従来]
  ブラウザ → DNS(A/AAAA) → IP取得 → TCP:443 → TLS+ALPN → HTTP → Alt-Svcでh3学習

[HTTPSレコードあり]
  ブラウザ → DNS(A/AAAA + HTTPS) → IP + {ALPN:h3,h2, port:443, ech:...}
         → 初回からUDP:443(QUIC)を試行可能 / ECHでSNI秘匿

A/AAAA/CNAMEはどこ（IP/別名）へ行くか。HTTPS/SVCBはどう接続するかを担う。両方必要なのが通常だ。

SVCBレコードとHTTPSレコード — 用語整理

IETFでは SVCB（Service Binding, TYPE 64） が一般形、HTTPS（TYPE 65） がその特殊化として定義されている。

項目	SVCB (TYPE 64)	HTTPS (TYPE 65)
用途	任意サービス（別ホストへの委譲含む）	HTTPSサービスに特化
ターゲット	別FQDN（例: pool.example.net）可	通常 .（自身）または同一名前
Cloudflare UI	「HTTPS」タイプとして管理	同左
dig指定	TYPE64 または SVCB	TYPE65 または HTTPS

エイリアスモード vs サービスモード

SVCB/HTTPSレコードには2つのモードがある。

エイリアスモード（AliasMode）

• TargetName が .（ルート）またはレコード名と同じ
• 「この名前のHTTPSパラメータは次のSVCBチェーンを参照せよ」という間接参照
• 実務ではCloudflareが自動生成するレコードの多くがこれ

サービスモード（ServiceMode）

• TargetName が別のFQDN（例: edge.example.com）
• ポート・ALPN・IPヒント（ipv4hint/ipv6hint）を直接記述
• CDNへの委譲やマルチCDN構成で使う

Wire formatの例（概念）:

example.com.  300  IN  HTTPS  1 . alpn="h3,h2" port=443 ech="..." ipv4hint=...

• Priority — 数値が小さいほど優先（複数レコード時）
• TargetName — . ならエイリアスモード
• SvcParams — キー=値のパラメータ列

主要なSvcParam — 実務で触るもの

HTTPS/SVCBレコードの本体は SvcParams（サービスパラメータ）の集合だ。

キー	意味	実務での例
alpn	サポートするALPNプロトコルID	h3, h2, http/1.1
port	接続先ポート	443（省略時は443）
ech	ECH設定（ECHConfigList）	Base64エンコードされた公開鍵
ipv4hint	IPv4アドレスヒント	104.21.0.1（Aレコードと一致推奨）
ipv6hint	IPv6アドレスヒント	2606:4700::
mandatory	必須パラメータの列挙	互換性制御用
no-default-alpn	デフォルトALPNを使わない	特殊構成

ALPN — Application-Layer Protocol Negotiation

ALPNはTLS 1.2/1.3の拡張で、握手時にアプリケーション層プロトコルを選ぶ。HTTPSレコードの alpn="h3,h2" は「このホストはQUIC(h3)とHTTP/2(h2)をサポートする」という事前宣言だ。

ALPN IDの対応:

ALPN ID	プロトコル
h3	HTTP/3 over QUIC
h2	HTTP/2 over TLS
http/1.1	HTTP/1.1

ブラウザはHTTPSレコードのALPNリストを読み、h3が含まれていれば初回からUDP 443へのQUIC接続を試行できる。HTTP/2とHTTP/3の違いで説明した「Alt-Svcで2回目以降にh3を学習する」パターンより1 RTT早い可能性がある。

ECH — Encrypted Client Hello

ECH（Encrypted Client Hello） はTLS 1.3 ClientHello内のSNI等を暗号化する拡張（旧称 ESNI/ECH）。中間者に「ユーザーがどのホストを見ているか」を見せない。

仕組みの概要:

1. DNS HTTPSレコードの ech パラメータに公開鍵（ECHConfigList）が載る
2. クライアントはClientHelloを2層構造にする
   • Outer ClientHello — カバードメイン（例: cloudflare-ech.com）へ向けた形式
   • Inner ClientHello — 実際のSNI（example.com）を暗号化
3. サーバー（またはCDNエッジ）が復号し、正しい証明書で応答

ECHが無効な従来のTLS:

ClientHello {
  SNI: example.com          ← 平文で見える
  ALPN: h2, http/1.1
}

ECH有効時:

ClientHello (outer) {
  SNI: cloudflare-ech.com   ← カバードメイン
  encrypted_inner: { SNI: example.com, ALPN: h3,h2 }  ← 暗号化
}

Cloudflareは2023年以降、無料プランでもECHを段階的に有効化している。HTTPSレコードの ech= パラメータはダッシュボード操作と連動し、手動でBase64を編集する必要は通常ない。

CNAMEとの違い — 混同しやすいポイント

「CNAMEの代わりにHTTPSレコード？」という質問はよくあるが、役割が異なる。

CNAMEの制約との関係

DNSの鉄則: CNAMEが存在する名前には、他のレコード（A, MX, TXT等）を置けない（RFC 1034）。HTTPSレコードも例外ではない。

典型的な構成:

# ✅ 正しい — apexはA/AAAA + HTTPS
example.com.     A      104.21.0.1
example.com.     AAAA   2606:4700:...
example.com.     HTTPS  1 . alpn="h3,h2" port=443 ech="..."

# ✅ 正しい — サブドメインをCNAME + 別名のHTTPS
www.example.com. CNAME  example.com.
example.com.     HTTPS  1 . alpn="h3,h2" ...

# ❌ 不可 — 同一名前にCNAMEとHTTPS
www.example.com. CNAME  cdn.provider.net.
www.example.com. HTTPS  1 . alpn="h3" ...

サブドメインを外部CDNのCNAMEに向ける場合、HTTPSパラメータはCDN側のドメインまたは委譲先のSVCBサービスモードで表現する。CloudflareプロキシONなら、Cloudflareが example.com 名前でHTTPSレコードを管理するのが簡単だ。

ANAME/ALIAS/CNAME flattening

apex（example.com）にCNAMEを置けない問題は、CloudflareのCNAME Flattening（ANAME相当）で「Aレコードとして返す」方式で回避している。HTTPSレコードはこの仕組みと独立して追加される。

Alt-Svcヘッダーとの関係 — HTTP/3最適化の二段構え

HTTP/2とHTTP/3の違いでは、HTTP/3の学習経路として Alt-Svc ヘッダーを説明した。

alt-svc: h3=":443"; ma=86400

手段	いつ有効か	持続期間	設定場所
Alt-Svc	1回目のHTTPレスポンス以降	ma= 秒（典型86400）	サーバー/CDNレスポンスヘッダー
HTTPSレコード	DNS解決直後	DNS TTL（典型300〜3600）	権威DNS

初回訪問者への効果

Alt-Svcのみの場合:

訪問1: DNS → TCP/TLS(h2) → HTTP → Alt-Svc学習
訪問2: DNS → UDP/TLS(h3)  ← ここで初めてHTTP/3

HTTPSレコード + Alt-Svcの場合:

訪問1: DNS(HTTPS RR) → UDP/TLS(h3) を即試行 → 失敗時h2フォールバック

初回TTFBの改善が期待できるのは、HTTPSレコード経由でh3を試行できる点だ。ただしUDP 443がブロックされている環境では、結局h2に落ちる（HTTP/3記事のフォールバック節参照）。

Cloudflareの実際の挙動

Cloudflare有効サイトでは通常:

1. DNS HTTPSレコードに alpn="h3,h2" と ech が載る
2. HTTPレスポンスにも alt-svc: h3=":443"; ma=86400 が付く
3. ブラウザは両方を参照し、HTTP/3を優先試行

検証コマンド:

# Alt-Svcヘッダー確認
curl -sI --http2 https://example.com/ | grep -i alt-svc

# HTTP/3直結
curl --http3-only -sI https://example.com/ | head -5

# DNS HTTPSレコード
dig @1.1.1.1 example.com HTTPS +short

期待される出力例:

alt-svc: h3=":443"; ma=86400
HTTP/3 200
1 . alpn="h3,h2" ipv4hint=104.21.0.1 ech=ABC123...

CloudflareでのHTTPSレコード設定

Cloudflare利用が「SVCB レコード 設定」の最短ルートだ。ダッシュボード操作でHTTPSレコードが自動管理される。

手順1 — HTTP/3（QUIC）を有効化

1. Cloudflareダッシュボード → 対象ゾーン
2. Network → HTTP/3 (with QUIC) を ON
3. SSL/TLS → Full (strict) を推奨（オリジン証明書が有効な場合）

これだけで、権威DNSとしてCloudflareが example.com 向けHTTPSレコードを配信する。手動追加は通常不要。

手順2 — DNSレコードの基本構成

Type    Name    Content              Proxy
A       @       192.0.2.1            Proxied（オレンジ雲）
AAAA    @       2001:db8::1          Proxied
CNAME   www     example.com          Proxied

プロキシON（オレンジ雲）のとき、CloudflareエッジIPが返り、HTTPSレコードの ipv4hint もエッジに整合する。

手順3 — HTTPSレコードの手動追加（上級）

自動生成を確認した上で、カスタムパラメータが必要な場合のみ。

フィールド	値の例	説明
Type	HTTPS	TYPE 65
Name	@ または www	対象ホスト
Priority	1	複数エントリ時の優先度
Target	.	エイリアスモード
SvcParam: alpn	h3,h2	カンマ区切り、引用符で囲む
SvcParam: port	443	省略可
SvcParam: ech	（自動）	Cloudflareが生成。手編集非推奨

Terraform例（cloudflare provider 4.x）:

resource "cloudflare_record" "https_apex" {
  zone_id = var.zone_id
  name    = "@"
  type    = "HTTPS"
  data {
    priority = 1
    target   = "."
    params {
      alpn   = "h3,h2"
      port   = 443
      # ech は Cloudflare API が自動付与
    }
  }
}

手順4 — 設定後の検証

digコマンド完全ガイド — HTTPSレコードの確認

DNS反映確認で触れた dig を、HTTPS/SVCB向けに拡張する。

基本クエリ

# HTTPSレコード（TYPE 65）を取得
dig example.com HTTPS

# 短い形式
dig example.com HTTPS +short

# 権威をバイパスしてCloudflareリゾルバ直接
dig @1.1.1.1 example.com HTTPS +short

# Google Public DNS
dig @8.8.8.8 example.com HTTPS +short

SVCB（TYPE 64）の確認

dig example.com SVCB +short
dig example.com TYPE64 +short

HTTPS専用ドメインならTYPE65だけで足りる。マルチCDN構成ではTYPE64のサービスモードが出ることもある。

詳細フラグ

# DNSSEC検証付き
dig example.com HTTPS +dnssec +multi

# 特定レコードタイプを明示（古いdig向け）
dig example.com TYPE65

# トレースで権威まで辿る
dig example.com HTTPS +trace

# JSON出力（jq連携）
dig example.com HTTPS +json | jq '.ANSWER_SECTION'

出力の読み方

;; ANSWER SECTION:
example.com.    300    IN    HTTPS    1 . alpn="h3,h2" ipv4hint=104.21.0.1 ech="ABC..."

フィールド	意味
300	TTL（秒）
1	Priority
.	TargetName（エイリアスモード）
alpn="h3,h2"	HTTP/3とHTTP/2をサポート
ipv4hint=	接続先IPのヒント（Aレコードと一致することが多い）
ech=	ECH設定（Base64）

Windows / PowerShell

# PowerShell 7+（Windows）
Resolve-DnsName -Name example.com -Type HTTPS

# WSL / Git Bash
dig @1.1.1.1 example.com HTTPS +short

nslookup はHTTPSタイプ非対応のため、上記を使う。

トラブルシュート — digで空になる場合

症状	原因	対処
ANSWER: 0	権威がHTTPS RR未設定	Cloudflare Network設定、DNSレコード確認
古いALPNのみ	TTLキャッシュ	dig @1.1.1.1 で権威直叩き
echなし	ECH未有効化	Cloudflare SSL/TLS → ECH設定
ipv4hint不一致	手動編集ミス	Aレコードと整合させる

自前DNS（BIND）でのSVCB/HTTPSレコード例

Cloudflare以外で権威DNSを運用する場合のBIND 9.18+設定例。

; HTTPS レコード（エイリアスモード）
example.com.  300  IN  HTTPS  1 . (
    alpn="h3,h2"
    port=443
    ipv4hint=192.0.2.1
    ipv6hint=2001:db8::1
)

; SVCB サービスモード — CDNへ委譲
api.example.com.  300  IN  SVCB  1 cdn.provider.net. (
    alpn="h2"
    port=443
)

named.conf で HTTPS/SVCB タイプが拒否されないか確認:

named-checkzone example.com zone.file
rndc reload
dig @ns1.example.com example.com HTTPS

自前nginxでHTTP/3を終端する場合は、HTTP/3記事のnginx設定とセットで、Alt-SvcとHTTPSレコードのALPNを一致させる。

ブラウザ・クライアントの対応状況

クライアント	HTTPS RR	ECH	備考
Chrome 120+	✅	✅（117+）	Secure DNS設定でDoH経由
Firefox 114+	✅	✅	DNS over HTTPS推奨
Safari 17+	✅	部分	OSレベル依存
curl 8.x	✅（—doh-url）	—	--http3-only と併用
古いAndroid WebView	❌	❌	Alt-Svcのみ

DoH/DoT（DNS over HTTPS/TLS）経路でHTTPSレコードが返るリゾルバを使う必要がある。ISPデフォルトDNSがTYPE65を握りつぶすケースは2025年時点で減っているが、企業DNSでは未対応もある。

セキュリティとプライバシー — HTTPSレコードの副作用

メリット

• SNI秘匿（ECH） — アクセス先ホスト名の漏洩を抑止
• ダウングレード攻撃の緩和 — mandatory パラメータで必須機能を宣言
• フィルタリング回避ではない — 正規のプライバシー強化。ポリシー違反用途は対象外

注意点

• DNS応答の改ざん — HTTPS RRもDNSSECで保護すべき。CloudflareはDNSSECワンクリック有効化可
• ech鍵のローテーション — 鍵更新時はDNS TTL内に新旧両方を配る設計（Cloudflare自動）
• 監視・ログ — 従来SNIベースのログがECHで使えなくなる。サーバー側は復号後のInner SNIで記録

セキュリティヘッダー一覧の Strict-Transport-Security と組み合わせ、HTTPS接続全体の強度を揃える。

実務シナリオ別 — 設計パターン

パターンA — Cloudflareプロキシ + HTTP/3

最も一般的。設定はダッシュボードのみ。

A/AAAA（プロキシ） + HTTPS（自動） + Alt-Svc（自動）
→ dig で h3 確認、curl --http3-only で検証

パターンB — 自前オリジン + Cloudflare CDN

オリジンはHTTP/2、エッジでHTTP/3終端。

オリジン: nginx HTTP/2
Cloudflare: HTTP/3 ON → HTTPS RR + Alt-Svc
→ クライアントはエッジとh3、エッジとオリジンはh2

パターンC — マルチCDN（上級）

SVCBサービスモードでトラフィック分割。

example.com. HTTPS 1 . alpn="h3,h2"           ; プライマリ
example.com. HTTPS 2 backup.cdn.net. alpn="h2" ; セカンダリ

Priority値でフェイルオーバー順序を制御。実装・テストコストが高い。

パターンD — API専用サブドメイン

api.example.com はHTTP/2のみに限定（h3不要）。

api.example.com. HTTPS 1 . alpn="h2" port=443

QUIC対応ライブラリが未整備のクライアント向けAPIで、h3試行を避けたい場合に有効。

HTTP/3接続の端到端検証手順

HTTP/2とHTTP/3の違いの検証節を、DNS視点で補完する。

1. DNS層

dig @1.1.1.1 example.com HTTPS +short | grep -o 'alpn="[^"]*"'
# 期待: alpn="h3,h2"

2. TLS/QUIC層

curl --http3-only -w 'version=%{http_version} time=%{time_connect}s\n' \
  -sI -o /dev/null https://example.com/
# 期待: version=3

3. HTTP層（Alt-Svc）

curl -sI --http2 https://example.com/ | grep -i alt-svc
# 期待: alt-svc: h3=":443"; ma=86400

4. ブラウザ層

Chrome DevTools → Network → 右クリックヘッダー → Protocol 列を表示 → h3 を確認。

5. フォールバック層

# UDP 443 を意図的にブロックした環境、または --http2 強制
curl --http2 -sI https://example.com/ | head -1
# 期待: HTTP/2 200（サイトは落ちない）

RFCと標準化の経緯

HTTPS/SVCBレコードを深く理解するには、関連RFCの関係を押さえておくとよい。

RFC	タイトル	内容
RFC 9460	Service Binding and Parameter Specification via DNS SVCB	SVCB/HTTPS RRの一般仕様
RFC 9461	SVCB HTTPS RR for DNS	HTTPS専用プロファイル
RFC 9114	HTTP/3	h3プロトコル本体
RFC 9000	QUIC	トランスポート
draft-ietf-tls-esni	ECH	TLS ClientHello暗号化

2018年頃から「DNSでALPNを渡す」議論が始まり、2020年にChromeが _dns.resolver.arpa 向け実験を実施。2023年にRFC 9460/9461が標準化され、Cloudflare・Google Public DNSがTYPE65を本番配信した。2024〜2025年はECHの一般化フェーズで、Chrome Stableでデフォルト有効化が進んでいる。

SVCBパラメータキーの番号

Wire formatではSvcParamキーが整数IDで表現される。デバッグ時にパケットキャプチャで見かけることがある。

キーID	名前	用途
0	mandatory	必須パラメータ列
1	alpn	ALPNプロトコルリスト
2	no-default-alpn	デフォルトALPN無効化
3	port	ポート番号
4	ipv4hint	IPv4ヒント
5	ech	ECHConfigList
6	ipv6hint	IPv6ヒント

dig +short の出力は人間可読形式にデコードされるため、通常はIDを意識する必要はない。

Chrome / Firefox の内部動作 — 開発者向け

ブラウザがHTTPSレコードをどう消費するかを知ると、挙動の不可解な症状を切り分けやすい。

Chrome

1. DNS解決時にA/AAAA/HTTPSを取得（Secure DNS有効時はDoH）
2. HTTPS RRの alpn に h3 があれば、QUIC接続を並列または優先試行
3. 失敗時は alpn の次候補（h2）へTCP接続
4. HTTPレスポンスのAlt-Svcでキャッシュ更新

デバッグフラグ（開発時のみ）:

chrome://flags/#enable-quic
chrome://net-internals/#dns
chrome://net-internals/#alt-svc

net-internals/#dns では example.com のHTTPSレコードキャッシュを確認できる。Alt-Svcタブでは h3 エントリの expires を見る。

Firefox

about:networking#dns でDNSキャッシュ、about:config の network.trr.mode でDoH設定を確認。Firefox 114以降はHTTPS RRをTRR（Trusted Recursive Resolver）経由で取得する。

よくある誤解

誤解	実際
HTTPSレコード = SSL証明書	証明書ではない。接続パラメータのDNS表現
CNAMEをHTTPSに置き換えられる	不可。名前解決と接続ヒントは別レイヤ
HTTPSレコードがあれば必ずh3	UDPブロック・クライアント非対応ならh2
Alt-Svcは不要になる	併用推奨。キャッシュ・互換性のため残す
ech= を手書きすればECH有効	サーバー側鍵と一致しないと握手失敗
DNS only Cloudflareでもh3	プロキシOFFではエッジ終端なし
TYPE65はTXTの一種	独立したRRタイプ。TXTとは無関係

チェックリスト — 本番投入前

関連技術との関係図

                    ┌─────────────────┐
                    │   DNS 解決      │
                    │ A/AAAA/CNAME    │
                    │ HTTPS/SVCB ←── ALPN, ECH, port
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
         UDP:443 QUIC    TCP:443 TLS    （MX等は別）
         HTTP/3 (h3)     HTTP/2 (h2)
              │              │
              └──────┬───────┘
                     ▼
              HTTPレスポンス
              Alt-Svc: h3=":443"  ← 2nd source of h3 hint
                     │
                     ▼
              以降の接続最適化

• DNS HTTPS RR — 接続前のヒント（ALPN, ECH, IP hint）
• TLS ALPN — 実際のプロトコル選択（握手）
• Alt-Svc — HTTP層での代替サービス宣言
• 詳細なプロトコル差分は HTTP/2とHTTP/3の違い を参照

トラブルシューティング — 症状別早見表

症状	確認コマンド	想定原因	対処
dig HTTPS が空	dig @1.1.1.1 example.com HTTPS	レコード未設定	Cloudflare HTTP/3 ON、DNS確認
alpnにh3がない	dig ... HTTPS +short	HTTP/3無効	Network設定、nginx http3 on
curl —http3-only 失敗	curl -v --http3-only ...	UDP 443ブロック	FW確認、h2フォールバックは正常
echパラメータなし	dig ... HTTPS +short	ECH未有効	Cloudflare SSL/TLS設定
ブラウザだけh2	DevTools Protocol列	DoH未設定でRR未到達	Secure DNS有効化
ipv4hintとA不一致	dig A と比較	手動編集ミス	レコード整合性修正
Alt-SvcはあるがRRなし	両方dig/curl	権威DNSがRR非対応	権威をCloudflare等へ移行

ログ取得例（nginx + HTTP/3）

# HTTPS RR経由でh3接続したかをaccess_logで確認
log_format h3log '$remote_addr "$request" proto=$protocol alpn=$ssl_alpn';
access_log /var/log/nginx/h3.access.log h3log;

$protocol が HTTP/3.0 ならQUIC接続成功。DNS HTTPSレコードの効果測定は、RR導入前後でh3接続比率を比較するのが定石だ。

関連記事

この記事は インフラ・DNS テーマの一環です。あわせて読むと理解が深まる関連記事をまとめました。

トピック	記事
CNAME lookup・DNS check の確認手順とよくある失敗	CNAME lookup・DNS check の確認手順とよくある失敗
SSL証明書の有効期限を確認する方法	SSL証明書の有効期限を確認する方法｜opensslコマンドと注意点
.htaccessでリダイレクトをかける方法	.htaccessでリダイレクトをかける方法｜301と302の使い分け
robots.txtの書き方と役割	robots.txtの書き方と役割｜クローラーを正しく制御する方法
AIクローラー対応 robots.txt・llms.txt 設定ガイド 2026	AIクローラー対応 robots.txt・llms.txt 設定ガイド 2026｜GPTBot・ClaudeBot・Google-Extended・GEO戦略
ブログの SEO と JSON-LD 構造化データ入門	ブログの SEO と JSON-LD 構造化データ入門
Monorepo Turborepo Remote Cache 設計完全ガイド	Monorepo Turborepo Remote Cache 設計完全ガイド｜CI パイプライン・GitHub Actions・2026 実践
SSL Check	SSL Check｜証明書期限とチェーン確認
DNSリバインディング攻撃の防御	DNSリバインディング攻撃の防御｜Host検証・SameSite・Private Network Access・localhostバインド
HTTPステータスコード一覧	HTTPステータスコード一覧｜200・404・500の意味と対処法
APIキャッシュ設計ガイド	APIキャッシュ設計ガイド｜ETag・Cache-Control・304・CDNキャッシュキーの実務
色のコントラストチェック	色のコントラストチェック｜color contrastの使い方と注意点

まとめ

HTTPSレコード（SVCB）は、DNSが「IPアドレスだけでなく、どのプロトコルで・どのポートに・ECH鍵付きで」接続すべきかを伝える進化形だ。

実務の要点:

1. CNAME/A/AAAAと役割が違う — 置き換えではなく併用
2. ALPN=h3,h2 — 初回からHTTP/3試行を可能にし、Alt-Svcより早いヒントになる
3. Cloudflare — HTTP/3をONにすればHTTPSレコードは多く自動。dig @1.1.1.1 example.com HTTPS +short で確認
4. ECH — プライバシー強化。CDN任せが現実的
5. 検証 — dig + curl --http3-only + DevTools Protocol列の3点セット

次のアクション: 本番ドメインで dig @1.1.1.1 your-domain.com HTTPS +short を実行し、alpn="h3 が含まれるか確認する。含まれなければCloudflareのHTTP/3設定を、含まれるのにh3にならなければUDP 443疎通を、HTTP/3記事の切り分け表に沿って調べてほしい。