要点

  • IETF Datatracker は、2026 年 8 月 5 日時点で Ray Bellis に関連する RFC を十件表示していた。その中には 2026 年 7 月公開の RFC 10029 も含まれ、同じ確認時点では active Internet-Draft は表示されていなかった。この一覧は公開文書と著者活動の索引であり、単独発明や普遍的な導入を示すものではない。 [1]
  • Bellis が著者として記録された 2010 年の RFC 5966 は、2016 年に五名の著者による RFC 7766 によって obsoleted、つまり置き換えられた。RFC 7766 は、完全な汎用 DNS 実装に TCP 対応を求め、TCP を UDP 失敗後だけの非常手段ではなく通常選択できるトランスポートとして扱った。 [3] [4]
  • RFC 7828 と RFC 8490 は、持続的な DNS 接続に伴う状態を、より明示的に扱うための仕様である。アイドル時間、セッション確立、失敗、タイムアウト、終了、再試行遅延などを表現できるようにするが、各ネットワークの容量や制限値を代わりに決めるものではない。 [5] [6]
  • RFC 8906 は、応答しないこと自体を運用上の問題として扱った。クライアントから見ると、パケット損失、フィルタリング、未対応機能、レート制限、実装不具合が同じ沈黙に見えることがある。通常条件では、沈黙ではなくプロトコル上の応答を返すほうが原因を切り分けやすい。 [7]
  • RFC 9619 は通常の DNS 問い合わせでは一つの主要な質問を扱うという実際的な前提を整理し、RFC 10029 はその枠組みを保ったまま、EDNS オプションで追加のレコードタイプを要求する方法を定義した。RFC 10029 は 2026 年 7 月の Proposed Standard であり、すでに広く普及した機能として書いてはならない。 [8] [9]

小さな名前解決は、多数の独立した責任を通過する

DNS は Domain Name System の略で、人が読める名前と、アプリケーションが使う接続情報を結びつける仕組みである。たとえばブラウザは、IPv4 アドレスを得るために A レコードを尋ねることがある。IPv6 アドレスなら AAAA レコードである。最近の接続では、HTTPS レコードや、署名済み応答を検証するための情報が関わることもある。

ただし、利用者の端末が最初から目的の権威サーバに直接聞くとは限らない。端末上のスタブリゾルバは、オペレーティングシステムやネットワーク設定が指定する再帰リゾルバに問い合わせる。再帰リゾルバは、ルートから上位ドメイン、さらに委任されたゾーンへとたどり、目的のゾーンについて正式なデータを公開する権威サーバに到達する。ここでいう「権威」は、そのゾーンの DNS データについて責任を持つという意味であり、インターネット全体を統治するという意味ではない。

途中にはキャッシュがある。キャッシュは、まだ有効な答えを保存し、同じ問い合わせを繰り返さずに済ませる。家庭用ゲートウェイや企業ネットワークには DNS プロキシがあり、クライアントが近くの装置に聞いているように見えても、実際には別のリゾルバへ転送していることがある。ファイアウォール、NAT、ロードバランサ、anycast の経路選択も、通信の見え方を変える。

この分散は DNS の弱点だけではない。世界中のネットワークが別々の運用者によって動かされているからこそ、単一の組織がすべてを止める構造を避けられる。しかし、分散がうまく働くには、各参加者が相手に理解できる情報を返す必要がある。名前が存在しないなら、そのことを示す応答が要る。要求された操作が実装されていないなら、実装されていないという応答が要る。応答が大きすぎて現在の経路に収まらないなら、切り詰められたことを示す必要がある。

沈黙は、それらの区別を消してしまう。リゾルバは待つべきか、同じ要求をもう一度送るべきか、別のサーバに聞くべきか、EDNS のような拡張を外すべきか、UDP から TCP に切り替えるべきかを決めなければならない。どの判断にも時間がかかる。最終的にページが開いたとしても、途中で何が壊れていたのかは記録に残らないかもしれない。

Bellis の名前が現れる DNS 関連 RFC は、この境界に何度も戻ってくる。文書は、世界中の DNS 運用を一か所に集めようとしていない。むしろ、独立した実装と運用者が互いに「何を理解したか」「何を完了したか」「何を拒否したか」「次に何を試せるか」を伝えられるように、共有の振る舞いを定義している。

この視点は、DNS の委任とレジストリ記録にもつながる。上位ゾーンの NS レコードは、下位ゾーンをどの権威サーバに任せたかを示す帳簿のような役割を持つ。帳簿は正確でなければならないが、帳簿そのものが通信を処理するわけではない。実際の連続性は、委任されたサーバが応答し、必要なトランスポートを扱い、問題が起きたときに理由を分類できるかにかかっている。

TCP は例外処理から、完全な DNS 能力の一部へ移った

DNS は UDP を使う、と短く説明されることが多い。UDP は接続を作らずに小さな問い合わせと応答を交換できるため、名前解決に向いている場面が多い。しかし、その説明だけでは不十分である。大きな応答、DNSSEC による署名情報、IPv6 に伴う応答サイズの変化、プライバシーを意識した接続型 DNS などを考えると、TCP は単なる特殊ケースではなくなる。 [4]

RFC 5966 は 2010 年 8 月に公開され、DNS over TCP の実装要件を扱った。公式記録では R. Bellis が著者として示されている。 [3] ただし、この文書は現在の最終的な説明ではない。2016 年 3 月、John Dickinson、Sara Dickinson、Ray Bellis、Allison Mankin、Duane Wessels の五名による RFC 7766 が公開され、RFC 5966 を置き換えた。 [4]

この置き換えは、標準化の失敗を意味しない。むしろ、公開仕様が運用経験によって更新されることを示している。古い文書は履歴として残るが、実装者は文書の関係を追い、どの仕様が現在の参照点なのかを確認しなければならない。DNS のような基盤では、番号だけを覚えていても十分ではない。

RFC 7766 の重要な点は、完全な汎用 DNS 実装が UDP と TCP の両方を支えるべきだとしたことである。また、TCP を UDP 応答が切り詰められた後だけに使うものとは扱わず、運用上の理由で最初から選べるトランスポートとして位置づけた。適切な TCP 接続がすでに開いている場合には再利用も推奨される。 [4]

非専門家にとっての意味は単純である。小さな UDP 問い合わせには答えるが TCP を扱えない DNS サーバや、ポート 53 の TCP を黙って落とすファイアウォールは、名前そのものが正しくても利用者に長い待ち時間や失敗を見せる可能性がある。利用者は「サイトが開かない」と感じるが、実際には名前、アドレス、権威データは正しく、経路上のトランスポート対応が壊れているだけかもしれない。

RFC は、すべてのサーバが要件を満たしていることを証明するものではない。公開されたテスト対象を与える。運用者は同じ名前とタイプについて UDP と TCP を比較し、接続が成立するか、同じ接続で応答が返るか、大きな応答が処理できるか、失敗時に明確な拒否が返るか、それともタイムアウトまで消えるかを観測できる。

プロキシは、パケットを運びながら意味を変えることがある

DNS プロキシは家庭用ルータや組織内ネットワークでよく使われる。クライアントは近くのアドレスに DNS を聞いているつもりでも、その装置が別のリゾルバに転送している場合がある。単純な A レコード問い合わせだけを試すと、プロキシは正常に見える。しかし、応答が大きい場合、EDNS オプションを含む場合、未知のタイプを尋ねる場合、または TCP を使う場合には、別の問題が表面化する。

RFC 5625 は 2009 年に公開された DNS Proxy Implementation Guidelines であり、公式記録では Bellis が著者として示されている。 [2] この文書は、すべてのプロキシが指針に従っていることを示すものではない。重要なのは、プロキシという中間装置が、もとの要求と届けられた要求の意味を変え得るという点である。

たとえば、プロキシが理解できないフラグや拡張を削除する。大きな応答を扱えず、切り詰めや TCP 再試行を正しく伝えない。未知のタイプに対して本来なら明示的な応答を返すべきところを、何も返さない。そうなると、クライアントは権威サーバが壊れていると誤解するかもしれない。実際には、途中の装置が証拠を消しているだけである。

この問題は DNS に限らず、インターネット基盤全体に共通する。中間装置はそれぞれローカルな理由を持つ。セキュリティ、互換性、性能、古い実装との折り合いで、通過させる内容を調整することがある。しかし、最終的な接続性は、もとの参加者が解釈できる応答を受け取れるかで測られる。設定画面に「DNS proxy enabled」と表示されていても、その経路が EDNS、TCP、応答コード、切り詰め、未知タイプを保つかは別問題である。

運用者のテストは、ドメイン名を一つ変えるだけでは足りない。同じ名前で通常 DNS と EDNS を比べる。既知タイプと未知タイプを比べる。UDP と TCP を比べる。応答サイズを変える。エラーコードが通過するかを見る。目的は、すべての装置に新機能を即座に実装させることではない。未対応という事実と、証拠を消す沈黙とを区別することである。

Bellis について言えることは、ここでも限定される。RFC 5625 は、彼の著者名が記録された公開文書である。メーカー、ネットワーク管理者、サービス運用者がどのように実装し、どのようにテストしたかは、別の証拠がなければ語れない。

接続を開いたままにすることは、容量をめぐる交渉である

TCP を通常の DNS トランスポートとして扱うと、別の運用課題が現れる。サーバは接続状態を持つ。ソケット、メモリ、キュー、処理時間を割り当てる。クライアントは、静かな接続がまだ使えるのか、まもなく閉じられるのかを知りたい。

問い合わせごとに新しい TCP 接続を作れば、遅延と負荷が増える。一方で、すべての接続を長く開いたままにすれば、混雑時にサーバ資源を使い切るかもしれない。一方が固定のアイドル時間を勝手に仮定すると、クライアントには短すぎ、サーバには長すぎることがある。

RFC 7828 は edns-tcp-keepalive EDNS0 option を定義した文書で、Paul Wouters、Joe Abley、Sara Dickinson、Ray Bellis が共著者として記録されている。 [5] このオプションにより、クライアントは接続を維持したいという意図を示し、サーバは TCP セッションに関連するアイドルタイムアウトを返せる。サーバが資源不足などの理由で接続を閉じてほしい場合には、保留中の処理が終わった後に閉じるべきことをゼロ値で示せる。

これは、中央がすべての容量を決める仕組みではない。標準はフィールドと意味を定義する。各サーバは、実際の負荷、利用者数、攻撃リスク、待ち時間目標に合わせて値を決める。クライアントは、その信号を読み、接続を再利用するか、閉じるか、別の方法を試すかを判断する。

RFC 7828 は、anycast に伴う問題も記録している。Anycast は、複数の場所が同じアドレスを広告し、ルーティングが利用者をいずれかの場所へ導く方法である。長い TCP 接続の途中で経路が変わると、同じアドレスに向かっているように見えても、以前と同じサーバに届かないことがある。中間装置が EDNS オプションや特定サイズ以上のメッセージに干渉する可能性もある。 [5]

だからといって、持続接続が無意味になるわけではない。必要なのは観測である。接続再利用率、接続確立時間、アイドル閉鎖の理由、閉鎖時の未処理要求、anycast サイト間の差、fallback の成否を数える。ゼロ値の keepalive は常に障害ではない。意図された容量信号かもしれない。理由のない切断は別のイベントとして扱うべきである。

標準化されたフィールドは、メモリを増やしたりファイアウォールを修理したりしない。しかし、資源判断を相手に見える形にできる。その効果は「TCP なら DNS は必ず信頼できる」という大きすぎる主張ではない。「どの接続をどれだけ保てるかについて、双方が同じ言葉で話せる」という、より実務的な利点である。

状態を持つ DNS には、双方が名づけられる状態が必要だった

keepalive は持続接続の一部を扱う。さらに進むと、DNS 接続の上で、普通の名前問い合わせではないセッション機能をどう管理するかという問題が出る。接続があることと、セッションが成立していることは同じではない。

RFC 8490 は DNS Stateful Operations、略して DSO を定義した。Bellis は六名の著者の一人として記録されている。 [6] DSO は、持続的な DNS セッション上で使う操作コードとメッセージ構造を与え、keepalive、retry delay、暗号化パディングなどの初期操作を扱う。サーバ側からメッセージを送ることも可能にした。

この文書の重要な点は、接続確立と DSO セッション確立を分けたことである。TCP 接続は存在していても、DSO セッションはまだ成立していない場合がある。セッション要求は成功することも、応答コード付きで失敗することも、タイムアウトになることもある。成立後は、双方が DSO メッセージを送れる。どちらかが終了を開始することもあり、サーバは再試行遅延を伝えられる。 [6]

「ソケットが開いている」だけでは運用記録として粗すぎる。セッション交渉中なのか、確立済みなのか、拒否されたのか、時間切れなのか、終了中なのかで、次の判断は変わる。もしすべてを「DNS 接続失敗」とまとめれば、プロトコルが与えた証拠を捨ててしまう。

RFC 8490 は、セッション確立時のタイムアウトや非ゼロ応答コードの扱いも定義している。タイムアウトは状態が不確定であることを示し、クライアントは接続を中止する。状況によっては DSO なしで再接続できる。非ゼロ応答コードは不成功を示すが、接続済みでセッションなしの状態で通常 DNS を続けられる場合がある。 [6]

もちろん、DSO はすべての障害を取り除かない。接続は失われる。中間装置は干渉する。サーバ容量は変動する。文書自体は、DSO が広く導入されていることも示さない。

それでも、名前を持つ状態は実務上価値がある。クライアントは、単に接続していたのか、セッションを交渉していたのか、成立していたのか、拒否されたのか、タイムアウトしたのか、終了中だったのかを記録できる。後のチームが調査するとき、「DNS が失敗した」よりもはるかに具体的な出発点を持てる。

沈黙は、異なる失敗を同じものに見せる

RFC 8906 は、この文章の中心問題を最も直接的に表している。Mark Andrews と Ray Bellis による文書で、DNS サーバが整形式の問い合わせに応答しないという、よくある運用上の問題を扱う。 [7]

何も返らない理由は一つではない。パケットが失われたのかもしれない。サーバが EDNS オプションを理解しなかったのかもしれない。ファイアウォールが落としたのかもしれない。攻撃中のサーバがレート制限したのかもしれない。未知タイプや未知フラグを見た壊れた実装が無視したのかもしれない。クライアント側からは、それらが同じ空白の待ち時間に見える。

この違いは重要である。リゾルバが沈黙を「EDNS 未対応」と解釈すれば、EDNS を外して再試行する。その結果、DNSSEC 検証や新しい機能が阻害される可能性がある。沈黙を単なるパケット損失と見れば、同じ要求を繰り返してアプリケーションの待ち時間を消費する。別のサーバにすぐ切り替えれば、権威サーバ側の恒常的な不具合を隠すかもしれない。

RFC 8906 は、通常条件では明示的な応答を返すことを求める。未知のデータタイプであれば、認識されたタイプにデータがない場合と同様の応答を返せる。未知の操作コードには not implemented に相当する応答がある。TCP での問い合わせにも答えるべきであり、TCP を拒否するファイアウォールは接続試行を黙って捨てるのではなく、明確に終了させるべきである。 [7]

文書は例外も認めている。攻撃を受けている nameserver は、パケットを落としたり応答を制限したりする必要があるかもしれない。これはローカルな安全判断である。問題は、そのような例外的な措置と、普通の条件下の壊れた沈黙が区別できなくなることである。

RFC 8906 は委任の保守にも言及する。上位ゾーンに置かれた委任用 NS レコードと、委任されたゾーン内の NS レコードが一致しているかを親ゾーン運用者が確認することを勧める。 [7] 古い委任は、利用者をもはや責任を持たないサーバへ向かわせることがある。正確な委任記録と明示的な応答は、どこに責任があるのかをリゾルバが判断する材料になる。

この考え方は、すべての問い合わせに無制限の資源を使うべきだという話ではない。否定応答、エラーコード、接続拒否、再試行信号は処理できる。沈黙は、推測の費用をクライアント、アプリケーション、支援窓口、利用者へ移す。

エラー応答は、クライアントの再試行予算を守る

アプリケーションは DNS を永遠には待てない。ブラウザ、メールサーバ、監視エージェント、ソフトウェア更新機能には、失敗を返すまでの時間がある。リゾルバは、その限られた時間の中で送信、接続、別サーバへの問い合わせ、fallback を選ぶ。

リゾルバが EDNS 付き問い合わせを送り、何も返らなかったとする。リクエストが失われたのか、サーバが EDNS 全般を無視するのか、特定のオプションだけが問題なのか、ネットワークがフィルタしたのか、レートリミットなのかは分からない。リゾルバは、同じ EDNS 問い合わせを繰り返し、普通の DNS に戻し、別の権威サーバを試し、TCP に切り替えるかもしれない。各分岐は合理的でも、合計すれば利用者の待ち時間を使い切る。

明示的な応答は、この分岐を短くする。形式エラーなら要求形式が問題だと分かる。未実装なら、その操作をサーバが支えないと分かる。通常の否定応答なら、サーバは質問を理解したが該当データがないと分かる。TCP 接続が明確に拒否されたなら、経路には到達したがサービスが利用できないことを示す。どれも成功応答ではないが、沈黙より運用価値が高い。

RFC 8906 は、非応答が EDNS を外す fallback を促し、それが DNSSEC や新機能の利用を遅らせる可能性を示す。また、通常 DNS が動くことを確認し、拡張付き要求を変化させ、元の要求を繰り返すことで、恒常的な不具合と普通のパケット損失を分ける試験手順を示している。 [7]

同じ発想は DSO にもある。非ゼロ応答コードはセッション確立が失敗したことを伝える。タイムアウトは状態が不確定であり、接続を中止する根拠になる。これらは異なる条件であり、ログ上でも分けるべきである。 [6]

RFC 10029 も同じ方向を向く。Multiple QTYPEs の応答オプションは、要求された追加タイプのうち何が完全に処理されたかを示す。必要なタイプが欠けていれば、クライアントは残りを単独問い合わせとして送る。拡張が未対応でも、主要な質問への答えは利用できる場合があり、その後に fallback できる。 [9]

ただし、すべてのクライアントが常にあらゆる分岐を試すべきではない。再試行は通信量を増やし、過負荷や攻撃を悪化させることがある。そこで運用者は再試行予算を決める。どの結果なら別方式を試すのか、何台のサーバまで試すのか、どれだけ待つのか、どの時点でアプリケーションにエラーを返すのかを明確にする。

有用な記録には、経過時間だけでなく、トランスポート、サーバ、質問タイプ、拡張、応答コード、切り詰めフラグ、接続結果、再試行理由、fallback 方法、最終結果が含まれる。プライバシーとデータ保持の制限は守る必要があるため、すべての利用者問い合わせ全文を保存する必要はない。状態を集計するだけでも、時間予算がどこで使われているかを見られる。

この利点はトラブルシュートを超える。新機能を導入するとき、未対応を明示する応答があれば、導入初期でも制御された fallback ができる。未対応サーバが沈黙するなら、クライアントは広い推測規則を長期間保持せざるを得ない。その規則は、古い壊れ方を正常に見せてしまう。

Bellis や他の著者たちは、世界中のリゾルバの再試行予算を決めていない。文書は、ソフトウェアと運用者が判断に使える応答情報と状態情報を定義している。容量、遅延、プライバシー、危険受容は各組織の判断である。標準の貢献は、その判断の前に、より多くの分岐を区別できるようにすることにある。

一つの質問を基点に、複数種類のデータを尋ねる

DNS メッセージには、質問数を表す QDCOUNT というフィールドがある。歴史的なワイヤ形式だけを見ると複数の質問を入れられるように見えるが、実装の世界では、一般的で相互運用できる複数質問の意味は定着しなかった。

RFC 9619 は Ray Bellis と Joe Abley の著者名で 2024 年に公開され、通常の DNS 問い合わせでは質問が通常一つであることを整理した。 [8] これは曖昧さを減らす。しかし、アプリケーションは同じ名前について複数種類のデータを必要とすることがある。接続準備では A、AAAA、HTTPS のような関連レコードを知りたい場合がある。別々に尋ねれば、追加の往復とサーバ作業が生じる。

RFC 10029 は、Bellis が著者として記録され、2026 年 7 月に Proposed Standard として公開された DNS Multiple QTYPEs を定義した。 [9] この文書は、不安定な複数質問解釈に戻らない。主要な質問を一つ保ち、その横に EDNS オプションで追加レコードタイプの一覧を添える。

応答側にもオプションがある。準拠するサーバは、有効な Multiple QTYPE 要求に対して、DNS 応答全体が切り詰められる場合でも応答オプションを返す。そこには、追加タイプのうち完全に処理されたものが示される。応答コードやフラグが合わない場合、または収まりきらない場合、サーバはそのタイプを含めず、完全成功であるかのようには扱わない。 [9]

クライアントには明確な fallback が残る。サーバがオプションを支えない、形式エラーを返す、または必要なタイプを省くなら、クライアントは残りのタイプを単独問い合わせとして送る。機能が使えるときは往復を減らし、使えないときは古い経路を保つ。

この RFC は、コストも隠さない。追加タイプを求めると、サーバ作業と DNS 応答の増幅可能性が増えることがある。そのため、運用環境に応じた設定可能な制限が必要だとしている。 [9] あるサービスが別のサービスより少ないタイプだけを許すことは、ただちに悪いわけではない。重要なのは、制限、未完了、fallback が観測可能であることだ。

ここにも、トランスポートやセッションに関する文書と同じ型がある。新機能は、対応、完了、資源制限、後退経路が見えるときに安全に進む。仕様は交換方法を定義する。実装者と運用者は、有効化するか、どこで制限するか、どの指標で測るかを決める。

標準化記録は、単独所有ではなく置き換えと引き継ぎを示す

2026 年 8 月 5 日時点の IETF Datatracker の Bellis プロフィールは、十件の RFC と active Internet-Draft なしという状態を示していた。 [1] これは、その時点で公開索引が示した文書記録である。完全な経歴表でも、影響度ランキングでもない。

記録内では、著者の形が変わる。RFC 5625 と RFC 5966 は Bellis を著者として示す。RFC 7766、RFC 7828、RFC 8490、RFC 8906、RFC 9619 は共同著者の文書である。RFC 10029 は Bellis を著者として示すが、IETF のプロセスを経た仕様である。 [2] [3] [4] [5] [6] [7] [8] [9]

RFC 5966 が RFC 7766 に置き換えられたことは、とくに重要である。早い文書は見えなくなったのではない。参照関係を通じて、実装者に新しい仕様を読むよう促している。後の文書は著者を増やし、運用経験を取り込み、要件を更新した。Bellis は両方に現れるが、標準は彼の私有物として提示されていない。

RFC 8490 は DNS over TCP の流れに、状態を持つ操作を加えた。RFC 10029 は RFC 9619 による一質問の整理に依存する。文書は互いに参照し、制約し、時には置き換える。この連鎖があるから、責任は更新され、古い貢献は消えず、しかし現時点の実装判断は新しい文書に合わせられる。

したがって、信用は記録に沿って書くべきである。Bellis は、公式資料に名前がある範囲で著者または共著者として記述できる。同時に、ワーキンググループ、他の著者、レビューした技術者、実装者、運用者の役割を消してはならない。ここで読んだ資料は、彼の私的な動機、人格、現在の雇用先、または DNS 導入を個人が支配したことを裏づけない。

残る価値は、個人伝説ではなく公開された仕様列にある。別の技術者が後から取得し、比較し、実装し、拒否し、更新し、稼働中のシステムで試せる文書群である。

未解決の仕事は、プロトコルと運用の境界にある

RFC が公開されても、古い中間装置は消えない。プロキシは拡張メッセージを誤処理するかもしれない。ファイアウォールは TCP を遮断するかもしれない。サーバは接続容量を使い切るかもしれない。anycast の経路変化は、持続接続を別サイトへ向けるかもしれない。リゾルバは、沈黙の後に長い推測を続けるかもしれない。

新しい仕組みは、新しい問いも生む。DSO は監視と保護が必要なセッション状態を作る。Multiple QTYPEs は別々の問い合わせを減らせるかもしれないが、サーバ作業と増幅リスクを増やすことがある。あるサーバを守る制限は、クライアントにとっては機能の便益を小さくするかもしれない。fallback は互換性を守るが、最終成功だけを測ると低い対応率を隠す。

これらは標準を拒否する理由ではない。仕様と結果を分けて扱う理由である。要件はテスト対象である。応答コードは証拠である。タイムアウトは状態遷移である。fallback は観測可能な分岐である。どれも、特定サービスが常に速く利用可能であることを保証しない。

Bellis の公開記録から読める一貫した教訓は、この限定の中にある。DNS は、参加者が自分の理解、完了、拒否、制限、次の試行可能性を伝えるほど、安全に進化しやすい。それは中央管理を作るのではなく、独立したシステムを観測しやすくする。

実装者とネットワークチームに残る問いは測定可能である。DNS がトランスポート、持続接続、拡張、複合問い合わせを増やすとき、稼働中のシステムは、アプリケーションが諦める前に失敗を分類できるだけの明示的な振る舞いを保っているか。RFC はすべてのネットワークの答えを持たない。だが、正確に尋ねる方法を与える。

出典

  1. IETF Datatracker, Ray Bellis のプロフィール.
  2. RFC Editor, RFC 5625: DNS Proxy Implementation Guidelines.
  3. RFC Editor, RFC 5966: DNS Transport over TCP — Implementation Requirements.
  4. RFC Editor, RFC 7766: DNS Transport over TCP — Implementation Requirements.
  5. RFC Editor, RFC 7828: The edns-tcp-keepalive EDNS0 Option.
  6. RFC Editor, RFC 8490: DNS Stateful Operations.
  7. RFC Editor, RFC 8906: A Common Operational Problem in DNS Servers: Failure to Communicate.
  8. IETF Datatracker, RFC 9619: In the DNS, QDCOUNT Is (Usually) One.
  9. IETF Datatracker, RFC 10029: DNS Multiple QTYPEs.