要約

  • 小さいSvcPriorityは、利用資格を満たしたレコードの中でのみ優先を表す。形式不良、自己矛盾、未知の必須キーがあれば先に除外されるため、見かけ上の第一候補が候補集合に入らないことがある。
  • AliasModeはサービス発見を委任してもoriginを変えない。ServiceModeは接続先とパラメーターを束ねるが、アドレスhintやDNS上のALPNは入力にすぎず、A/AAAA、元のサービス名に対するTLS検証、実際のALPN、アプリ応答が別々の証拠になる。

一番札なのに入口で落ちる

あるoriginが二つのHTTPS ServiceModeレコードを公開したとする。優先度1は新しいedgeを指し、実験的キーをmandatoryに指定する。優先度2は既存edgeで、古いクライアントも全パラメーターを理解できる。運用画面は優先度1を「選択された接続先」と表示した。

しかし、そのクライアントにとって第一レコードは利用不能である。RFC 9460では未知の必須キーを持つServiceModeレコードを無視する。そこで優先度2を評価し、接続に成功してよい。順位が逆転したのではない。順位付けより前に資格判定が行われたのである。

これは特定のブラウザーやCDNに関する事件ではない。DNS所有者は接続案を提示できるが、全クライアントに理解力を与え、ポートを開通させ、サーバーに宣言通りのプロトコルを選ばせ、証明書に元のサービスを認証させることはできない。

AliasModeとServiceModeの権限

RFC 9460はSVCBをRR type 64、HTTPSをtype 65として定義する。レコードはSvcPriority、TargetName、任意のSvcParamsから成り、優先度0がAliasMode、非0がServiceModeである。

AliasModeは特定サービスの発見先を別名へ委任する。特にCNAMEを置けないzone apexで意味がある。ただし影響はそのSVCB互換RR種別に限定され、同じ名前の他のRRを変更しない。AliasMode内のパラメーターも無視される。無限委任を避けるため、クライアントとresolverはalias chain長を制限しなければならない。

委任してもoriginは変わらない。HTTPSクライアントはproviderのTargetNameへ到達しても、元のサービス名をSNIに入れ、その名前で証明書を検証し、HTTPのHostまたは:authorityも維持する。譲ったのは発見経路であって、読者が頼るサービス本人性ではない。

ServiceModeはTargetName、port、ALPN、アドレスhint、拡張キーを一つの候補計画に束ねる。複数CDNが異なる能力を持つ場合、各providerの接続先とパラメーターを混ぜずに済む。それでもレコードは、対応クライアントが試す案であり、稼働や配備一致の証明ではない。

選ぶ前に捨てる

wire形式が壊れたRRはRRset全体を無効にし、非SVCB接続へ戻すことがある。認識済みパラメーターが矛盾するレコードも拒否される。未知の通常キーは無視できるが、未知の必須キーはレコードを非互換にする。

生き残ったレコードだけが優先順位に入る。小さい数字を先に試し、同順位は均等にrandom shuffleする。SRVのweightとは違う。従って順位1は「互換なら先に使う」であり、「無条件に従う」ではない。

mandatoryはサーバーへの命令でも、クライアントの自動更新でもない。「このキーを無視すると当該レコードは正しく機能しない」と宣言する仕組みである。列挙キーは同じレコードに実在し、mandatory自身を含めてはならない。HTTPSではportとno-default-alpnが存在時に自動必須になる。誤ったportや既定protocolの復活は、単なる性能差ではなく別の通信になるからだ。

DNSのALPNと握手のALPN

alpnは候補接続先が提供すると述べるprotocol suiteである。HTTP/3なら初回からQUICを準備できる。しかしDNS値は握手結果ではない。TLSのALPNは依然としてclientとserverの間で決まり、edgeの世代遅れ、UDP遮断、設定反映差によって結果は変わる。

証拠にはDNSで受けたALPN集合と、握手で選ばれた値の双方が必要である。portも同様で、DNSが指定してもclient policyやfirewallは拒否できる。公開は意図を示し、socket結果は一つの地点での実行を示す。

hintを権威に昇格させない

ipv4hintとipv6hintは待ち時間を減らすための暫定アドレスで、TargetNameのA/AAAAの代替ではない。A/AAAAが利用可能ならhintを無視し、利用できないときも問い合わせを続け、将来の接続では得られたアドレスを優先する。

先にhintへ接続し、後で正式回答へ切り替えることは許される。だから監査では、接続先IPだけでなく、その出所を保存する必要がある。hint、Answer、Additional、cache、proxy解決のどれか、TTLとnetworkは何か。これを失えば、古いDNS、意図したrace、provider分裂、改ざんを区別できない。

迂回しても元の名前を認証する

RFC 9460はSVCB/HTTPSが信頼できないDNS経路を通ることを想定する。DNSSECはRRsetの由来と完全性を強めるが任意であり、接続先の稼働や本人性まで証明しない。

代替endpointは元のserviceに対する権限をTLSで示す。providerのTargetNameだけに有効な証明書では足りない。DNSSECが成功しても、元の名前に対するcertificate validationが失敗すれば、その接続計画は完成しない。

DNSは発見、TLS identityは本人確認、ALPNはこの接続のprotocol合意、HTTPはorigin要求と応答を担当する。一つの緑色表示で全段階を代表させてはならない。

fallbackは採用政策である

HTTPはSVCB以前から存在するため、通常のclientはSVCBがなくても接続できる。これは段階導入を可能にする一方、downgrade境界になる。認証されたSVCB問い合わせがDNSSECエラー、SERVFAIL、保護transport失敗、timeoutで終わった場合、保護パラメーターを捨ててA/AAAAだけで進むべきではない。無認証DNSの通常失敗はlocal policyで扱える。

multi-CDNではCNAME、HTTPS、A/AAAAが別々の時点で異なるprovider世代を観測し得る。選択したTargetNameのアドレスを改めて取得しなければ、別providerの値を結合してしまう。Running-Code Primacyが求めるのは宣言の崇拝ではなく、相互運用する実装で確認できる最小の共通規則である。

出典