DNSの仕組みの中でも特に面倒くさい情報!? 「グルーレコード」の現状を知る――「ランチのおともにDNS」より

　「Internet Week 2023」において11月21日に行われた「ランチのおともにDNS」では「グルーレコードについて改めて考える」をテーマとして、株式会社日本レジストリサービス（JPRS）の森下泰宏氏と礒浪直生氏による講演が行われた。

　DNSの名前解決において「グルーレコード」はとても重要な存在である。また、その設定をする、または考える際に「内部名」と「外部名」という言葉を使ったことがある方も多いものと思う。今回の講演では、その内部名と外部名に代わる用語が再整理された話題や、今後のあるべき姿の提案なども述べられている。

グルーレコードは、親ゾーンと子ゾーンを接着するもの

　セミナーの冒頭で森下氏は、今回のテーマであるグルーレコードについて、この話題を扱うに至った背景の説明を行った（図1）。グルーレコードはDNSにおいて重要、かつ登録者・運用者が直接取り扱う基本情報であるにもかかわらず、仕様の曖昧さや取り扱いの不備により、トラブルやセキュリティインシデントの原因となっている。そうした状況の一端を解説することでグルーレコードの現状を知り、DNSのより良い運用に役立ててほしいというのが、今回のテーマ選択の理由であるとのことであった。

図1　今回のテーマであるグルーレコードの説明

　本題に入る前に、グルーレコードとは何かについて簡単に説明しておこう。DNSの名前解決の仕組みでは、そのゾーンを管理するネームサーバー[*1]の名前が委任先のゾーンで管理されている場合、名前解決においてループが発生してしまう。例えば、example.jpゾーンをns.example.jpというネームサーバーが管理している場合に、利用者がwww.example.jpのIPアドレスを知りたくなったとしよう。この場合、「www.example.jpのIPアドレスを教えて」という問い合わせ（クエリ）に対し、委任元であるjpのネームサーバーは「example.jpのことはns.example.jpに聞いて」という応答（レスポンス）を返す。しかし、ネームサーバーであるns.example.jpのIPアドレスを知るための何らかの仕組みが無いと、「委任先のネームサーバーのIPアドレスを知るためには、委任先のネームサーバーにアクセスしなければならない」状態になり、名前解決がループしてしまうのである。

　グルーレコードはこの問題を解決し、DNSの名前解決を円滑に動かすための情報として、委任元ゾーンのネームサーバーに設定される。言葉で書くとややこしいかもしれないので、ピンと来なかった方にはJPRSの用語辞典で「グルーレコード」の項目[*2]を見ていただくことをお勧めする。そちらには図解があるので、挙動がイメージしやすいと思う。

　講演前半の「グルーレコードの概要と役割」を担当した礒浪氏は、その説明の中で「グルー（glue）とは、何かと何かを接着する接着剤である」と述べたが、グルーレコードにおける「何かと何か」は「親ゾーンと子ゾーン」ということになる（図2）。DNSは委任先のネームサーバーを名前で指定するかたちで設計されたため、何らかの方法で名前に対応するIPアドレスを知る必要があり、そのために生まれた仕組みがグルーレコードによるA/AAAAレコードの追加であると述べている（図3）。

図2　グルーレコードが接着するもの

図3　接着剤によるIPアドレスの追加が必要な理由

　今の若い方々は知らないかもしれないが、DNSが誕生した1980年代のコンピューターネットワークは百花繚乱で、ベンダーごとに異なるシステムを使用していた。ここでは詳細には触れないが、代表的なところでは、IBMのSNA、DECのDECnetといったところが独自プロトコルとして開発され、顧客の囲い込みに使われていたのである。そのことが、「当時は、IPがデファクトスタンダードになるとは限らなかった」という説明の背景の1つであるが、そうした点からもネームサーバーの指定には抽象度の高い“名前”が使われ、接続のためのアドレスの情報は別途追加するように設計されたのは自然な成り行きであったのであろう。

RFCにおいて「用語の再整理」が行われたことはとても重要

　さて、ここから森下氏が話者となり「グルーレコードに関する最近の動きと現状」についての話題に移るわけだが、グルーレコードについて考える場合、IETFで進められている委任先ゾーンとネームサーバーホスト名の関係を示す用語の再整理の話が重要になる。そのため、以降ではその部分について少し詳し目に扱うことにする。

　森下氏は、DNSの用語を定義するRFC 8499において、委任先ゾーンとネームサーバーホスト名の関係が4種類に整理されていることを述べた（図4）。RFC 8499は、DNS用語の定義の明確化を目指したRFC 7719を改版したもので、DNSで使われているさまざまな用語をまとめ、その定義を解説したものである[*3]。

図4　委任先ゾーンとネームサーバーホスト名の関係（RFC 8499における用語の説明）

　ただし、図4内の表を見ると分かるが、従来の定義では「In-」で始まる用語が2種類存在しているため、日本語の「内部名」の定義・用法にも揺れがあり、英語でも「In-bailiwick」が「In-domain」の意味で使われている文書が存在するなど、用語の使われ方に混乱があることが問題視された。そのため、RFC 8499を置き換える新たなインターネットドラフト（draft-ietf-dnsop-rfc8499bis）では従来の4種類の用語が3種類に再整理されており、すでに現時点でRFC発行待ちの状態になっているということが解説された（図5）。

図5　委任先ゾーンとネームサーバーホスト名の関係を示す用語の再整理

　図6で示されたように、新しい定義では、委任先ゾーンとネームサーバーホスト名の関係が「In-domain」「Sibling domain」「Unrelated」の3種類に分類される。また、「In-bailiwick」と「Out-of-bailiwick」は歴史的（historic）として非推奨とされたということで、すっきりしたと感じるのは筆者だけではないだろう。

　また、図6の下の方に「『内部名』『外部名』は混乱を避けるため、本セミナーでは使用しない」とあるが、本質的には外部名であるはずのSibling domainの扱いがぶれると、内部名と外部名という言葉の使い分けが怪しくなってしまうため、本セミナーに限らず、思い切ってこれからはIn-domain/Sibling domain/Unrelatedの3種類以外の用語は使わないとして欲しいと感じる[*4]。内部名と外部名という用語を使う方々は多いが、他の模範となるためにもぜひご一考いただきたい。

図6　In-domain/Sibling domain/Unrelatedという分類に

　図7は、それぞれの関係におけるグルーレコードの取り扱いを示したものである。詳細は図を見ていただきたいが、In-domainの場合、名前解決においてグルーレコードが必要で、フルサービスリゾルバー（キャッシュDNSサーバーとも呼ばれる）はグルーレコードを受け入れる。Sibling domainの場合、名前解決においてグルーレコードは必ずしも必要ではないが、多くのフルサービスリゾルバーの実装が受け入れる、という違いがある。なお、Unrelated（関係ない＝無関係という意味）の場合、名前解決においてグルーレコードは有害であり、追加されていても受け取り側で破棄される（有害である理由は後述する）。

　ここからは、発表に従い、それぞれの分類ごとに取り扱いの違いを見ていくことにする。

図7　それぞれの分類におけるグルーレコードの取り扱い

　In-domainの場合、名前解決においてグルーレコードが必要である（図8）。これは先に書いたように、グルーレコードが無いと名前解決においてループが発生してしまうため、当然である。注目したいのは、2023年9月に発行されたRFC 9471[*5]で、In-domainの場合にはレスポンスに全てのグルーレコードを含めるか、レスポンスサイズに制約がある場合は再問い合わせを促さなければならない（TCビットを“1”に設定しなければならない）ことが明確化された点であろう。

　多くのフルサービスリゾルバーは、レスポンス内のTCビットに“1”がセットされているとTCPを用いてクエリを再試行する。最近のフルサービスリゾルバーはEDNS0を用いた問い合わせをすることが一般的であるため、TCビットに“1”が設定されるケースは多くないと思われる（EDNS0の仕様（RFC 6891）では、EthernetネットワークにおけるDNSメッセージサイズの推奨値として、1280バイトから1410バイトまでの間が妥当としている）が、EDNS0への対応が不適切なルーターやファイアーウォールなどを使用している場合、問題が発生する可能性がある[*6]。

　いずれにしても、自分自身が使用しているネットワーク機器の見直しは必要になるであろう。DNSにおけるEDNS0とTCPのサポートは必須である。

図8　In-domainの場合の取り扱い

　Sibling domainの場合、名前解決においてグルーレコードは必ずしも必要ではない（図9）。しかしながら、RFC 9471では「ほとんどのネームサーバー実装は名前解決の効率を上げるために、グルーレコードを提供する」と記述されている。そして、前述したように多くのフルサービスリゾルバー実装は、Sibling domainのグルーレコードを受け入れるようになっている。

　フルサービスリゾルバーがIn-domainでないグルーレコードを受け入れてもよいのは、そのグルーレコードの内容が正しいと判断できる場合のみである。現在のドメイン名の運用では、グルーレコードの元になるネームサーバーホスト情報のレジストリへの登録は、ネームサーバーホスト名が属するドメイン名の登録者（例えば、ネームサーバーホスト名がns1.example.comである場合、example.comの登録者）がすることになっており、Sibling domainの場合、委任先ゾーンとグルーレコードは同一のTLDとなる。そのため、そのTLDレジストリのネームサーバーは自分が管理する情報としてグルーレコードを提供し、フルサービスリゾルバーはそれを受け入れる形で運用されている、ということなのだろう。

図9　Sibling domainの場合の取り扱い

　Unrelatedの場合、名前解決においてグルーレコードは有害である（図10）。名前解決においてグルーレコードは応答に追加されず、追加されていても受け取り側のフルサービスリゾルバーで破棄される。

　この動作は、1997年に実行された「Kashpureff型攻撃手法」への対策として導入された。Kashpureff型攻撃手法は、攻撃者が管理するネームサーバーに何らかの問い合わせをさせるように仕向け、そのレスポンスに管理外のA/AAAAレコードを設定して、フルサービスリゾルバーにその情報を受け入れさせることで攻撃を成立させる、キャッシュポイズニングの一種である。当時、AlterNIC[*7]を運営していたEugene Kashpureff氏がこの攻撃を実行し、InterNICへのアクセスをAlterNICに誘導した[*8]。このあたりの話にご興味がある方は、Internet Week 2008のDNS DAYにおいて使われた資料が公開されているので、そちらをご覧いただくのが良いだろう[*9]。

図10　Unrelatedの場合の取り扱い

　ここまで話を進めてきて、察しの良い読者の方は、グルーレコードの取り扱いには現在のドメイン名の登録と運用が深く関係している、ということが読み取れたと思う（ドメイン名の登録における取り扱いについては次で説明する）。森下氏はこの話題のまとめとして「多くの人々にとってグルーレコードがこれほど分かりにくくなってしまった理由の1つには、グルーレコードには目的が異なり、取り扱いも異なる2種類のものが存在することが理解されていないことにあるのではないか」と述べている（図11）。

図11　まとめ：目的の異なる2種類のグルーレコード

　グルーレコードを巡るもやもやについては、レジストリにおけるネームサーバーホスト情報の取り扱いを見ると、その違和感がより具体的になりそうである。森下氏は、.jpと.com/.netにおけるネームサーバーホスト情報の取り扱いの現状について、表を交えて解説した（図12～図14）。.jpのシンプルさに比べ、.com/.netでは「登録ドメイン名とネームサーバーホスト名のTLDを同じレジストリが管理している場合、グルーレコードとして追加されない場合であってもネームサーバーホスト情報の登録が必要になる」という、ドメイン名登録者や利用者が混乱しそうな仕様が存在している。

図12　.jpにおける取り扱い

図13　.com/.netにおける取り扱い

図14　まとめ：.jpと.com/.netにおけるネームサーバーホスト情報の取り扱いの違い

　さらに森下氏は、「.com/.netにおけるこのような取り扱いはVeriSign社の独自仕様かと思って調べてみたところ、他のgTLDでも同様の仕様となっているところを複数見つけた」「この仕様はもしかすると、EPP[*10]の仕様と関連しているのかもしれない」と述べ、「いずれにしても、ホスト情報の取り扱いとその仕様のTLD間における違いが、グルーレコードに関する理解の妨げになっている」という点を強調した。

今後のドメイン名とDNSの運用におけるグルーレコードと我々のあるべき姿とは

　講演最後の「DNS運用におけるあるべき姿」では、森下氏より今後のドメイン名とDNSの運用におけるグルーレコードと我々のあるべき姿が提案された。

　まず、森下氏は前述した2つの話題について、2021年のランチセミナーで解説した「設計時に悪意の存在を想定していなかったこと」がKashpureff型攻撃手法の原因になったこと、2022年のランチセミナーで解説した「委任情報の取り扱いはDNSの仕様・設計における代表的な弱点の1つであり、さまざまなトラブルや脆弱性の原因になっていること」が、委任情報の一部であるグルーレコードにも及んでいることを解説した（図15）。

図15　こうなってしまった原因は……

　続けて、DNSを開発する際に委任先を名前で指定するのではなくIPアドレスで指定するように設計しておけば、グルーレコードという仕組みを使う必要はそもそもなかったのではないか、名前で指定するにしてもIn-domainしか許さないようにし、グルーレコードを常に使うように設計しておけば、今日のグルーレコードをめぐる混乱は存在しなかったのではないかと述べている。その一方で、現在の設計だから良かったこともあるとも述べ、いくつかの例を提示した（図16、図17）。このあたりの話はたらればではあるのだが、当時の事情を知る者の一人として、悩ましく感じる部分でもある。

図16　こう設計しておけば良かったのかも……

図17　でも、今の設計だから良かったこともある

　基本としては、続くスライドにあるように、グルーレコードの、そしてDNS運用のあるべき姿は時代とともに変わる、変えていく必要があるということであろう（図18、図19）。DNSを自前で運用するのが当たり前であった時代と、インターネットの重要性が増し、信頼できるDNSサービス提供事業者（以降、「外部DNSサービス」と記述する）を利用することが当たり前になった現在とでは、考え方を根底から変えていかなければならないからだ。

　図19の右下に「外部名のほうが、エラー率が少ない」という調査結果が引用されている。考察に書かれている「おそらく運用サービスなので正しく運用されている」「一般の登録者はDNSプロバイダ（外部DNSサービス）に任せると間違いが少ない」は、DNS運用の現状を表しているとも言える。

図18　グルーレコードのあるべき姿は？

図19　あるべき姿は時代とともに変わる

　それらを踏まえたうえで、森下氏はDNS運用者がすべきこととして、図20の内容を示した。要は、DNSのゾーン管理者は以下のことをきちんと行うべきであるということである。

1. グルーレコードに使われるネームサーバーホスト情報を適切に管理すること
2. 委任元のネームサーバーから応答されるグルーレコードの内容を把握すること

　箇条書きの1.は当然だが、2.については親子間におけるネームサーバー設定の不一致の発生状況、本稿でも解説したドメイン名の登録におけるネームサーバーホスト情報とグルーレコードの関係の複雑さなどを考えると、意外と見落とされがちな点であり、注意が必要であろう。

図20　グルーレコードについてDNS運用者がすべきこと（1/2）

図21　グルーレコードについてDNS運用者がすべきこと（2/2）

　また、図21の最初の箇条書きについて会場から質問が投げ掛けられた。内容的には、「この書き方だと外部DNSサービスを買った利用者側が、業者側から指定されたIPアドレスを自分自身のIn-domainとして設定してしまうのではないか」というものである。それに対し森下氏は、誤解されるリスクがあるとして、次のように説明した。

　「おっしゃるように、外部DNSサービスを買ってこういう風に設定しろと言われているのに、利用者側が勝手にIn-domainの設定をするというのは最もやってはいけないことです。ここで言っていることは、外部DNSサービスを“提供する側”は、ネームサーバーをIn-domainで設定しろということであって、利用者側は事業者が言うとおりの設定を行わなければいけません。」

　このあたりの話は、Internet Week 2016で株式会社インターネットイニシアティブ（IIJ）の山口崇徳氏の発表[*11]でも述べられている。その資料の21ページ目に書かれているが、もしネームサーバーのアドレスを変更しなければいけなくなったときにそれだけの差があるということである。なお、本件については2017年に、JPRSでも情報発信をしている[*12]。

• 外部名で設定：外部DNSサービスを提供している側がA/AAAAリソースレコード（RR）を変更するだけで済む
• 内部名として設定してしまうと：利用者側がA/AAAA RRを変更し、レジストラにグルーレコードの変更を申請する必要がある

　結局のところ、DNSだけでなくドメイン名を登録・管理する側もグルーレコードとは何かという本質的な部分をきちんと理解しないと、グルーレコードを正しく運用するのは難しそうである。

　森下氏は、「おわりに」として図22を提示した。黒塗り部分には「沼」や「落とし穴」とかではなく、「学び」とか「参考」のような前向きな言葉を入れてほしいと述べたのは、先に書いたように「グルーレコードのあるべき姿は時代とともに変わる、変えていく必要があると」いうことを言いつつ、グルーレコードを正しく理解していくことが現状を改善するためにも必要であると言いたかったのではないだろうか。

　さらに、余談として図23を示したが、「もしかしたら、グルーレコードと虫垂には、一脈通じるものがあるのかもしれません」というのは、個人的にはSibling domainのことかなと思えてしまう。当初、.com/.net/.orgの登録システムは同一であったため、データベースがひとまとめに管理されていたという歴史的経緯が、ドメイン名の管理やDNSの運用にも影響していたのではないだろうか。

図22　おわりに

図23　グルーレコードと虫垂の共通点？

　これまでの説明を聞いてきた筆者は、新しい定義では、委任先ゾーンとネームサーバーホスト名の関係が「In-domain」「Sibling domain」「Unrelated」の3種類に分類に再定義されるという話が一番印象に残ったが、読者の皆さまはいかがだろうか。あらためて今回の講演をまとめると、以下のようになると思う。

• 関連する用語が再定義されます
• ネームサーバーホスト情報は適切に管理しよう
• 親のネームサーバーホスト情報と子のネームサーバー設定の双方をちゃんと意識し、合致するように運用しよう

　会場となった東京大学伊藤謝恩ホールは立地的に、限られた時間での食事に難があると感じていることから、このように食事付きで役立つ講演が聞けることはたいへんにありがたいと感じる。読者の皆さまも、ぜひInternet Weekへのご参加をご検討いただきたい。