熱い議論の続く、DNSプロトコル拡張と今後

　前回に引き続き、DNSプロトコルの標準化動向について取り上げる。今回は、最近のDNS Operations（dnsop）WGの活動を紹介する。

　dnsop WGはDNS運用に関するガイドラインを作成するという目的に加え、既存または新しく発生するDNSの問題に対応する場を提供するという役割を持つ。dnsop WGには完了条件がなく、明確なマイルストーンが設定されていないが、最近のdnsop WGではDNSプロトコル拡張やBCPドキュメントを積極的に作成しており、2015年には8本のRFCを発行し、2016年には9本のRFCを発行した。

　2017年には、8月4日現在、4本のRFCを発行し、1本がRFC発行間近（IESGに提出）である。こうしたRFCの発行状況も、30年前の古い仕様であるRFC 1034/1035がいまだに有効であり、がつ多数の機能拡張（つぎはぎ）を積み重ねているというDNSの状況を裏付けている。

　2015年以降に発行されたRFCと、dnsop WGからIESGに提出された提案を表に示す。

　これらのうち何本かについて紹介する。

TCP通信路（RFC 7766）について

　RFC 7766では、DNSでのTCP通信路の要求仕様のアップデートを行った。従来はRFC 1123に"MUST send a UDP query first"と書かれていたが、RFC 5966で"SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason"と再定義されたあと、RFC 7766では"TCP MAY be used before sending any UDP queries."と再定義され、最初からTCPで問い合わせてもよくなった。

　また、1つのTCPセッションで複数クエリを連続して送ること（応答を待たなくてよいこと）や複数のクエリを送った場合の応答は順不同でUDPと同じであること、TCPセッションを張りっぱなしにしてときどきクエリを送ることも可能であること、TCP closeなどについて明確化された。

　また、通信が流れていないTCPセッションを切るタイムアウト値を指定するEDNS0オプションがRFC 7828で定義された。TCPの取り扱いに関する拡張の目的の1つは、DNS over TLSなどを効率的に実現するためである。

クエリ情報漏洩の最小化（RFC 7816）について

　RFC 7816では、フルサービスリゾルバでの名前解決時に、権威DNSサーバーへ漏れる情報を最少化する名前解決アルゴリズムが実験的プロトコルとして標準化された。

　従来、フルサービスリゾルバは名前解決時にスタブリゾルバ（クライアント）から受け取ったクエリ名・クエリタイプをそのままルートやTLD、各組織などの権威DNSサーバーに送っていたが、結果としてエンドユーザーが問い合わせた具体的な名前やクエリタイプがルートやTLDなどの権威DNSサーバーにそのまま伝わっていた。実際にはフルサービスリゾルバのキャッシュ機構のためにすべてがルートやTLDに伝わるわけではないが、ルートやTLDのクエリ情報を調べることで多くの情報を得ることができた。

　そこで、ルートサーバーにはTLDのNSリソースレコードを聞き、TLDの権威サーバーには各組織（セカンドレベルやサードレベル、フォースレベル）のNSを聞き、各組織の権威DNSサーバーだけにクエリ名・クエリタイプを明かすようにするという提案である。ゾーンカットはドメイン名のラベルの区切りに必ず存在するわけではないため、提案手法ではかなりの無駄が発生する可能性はあるが、ルートサーバーやTLDの権威サーバーにエンドユーザーが問い合わせたクエリ名やクエリタイプを送信しなくなり、情報の露出を軽減できる。

名前解決の性能向上（RFC 8020）について

　RFC 8020では、名前解決時に受け取った名前不存在エラー（NXDOMAIN, NameError）をキャッシュすることと、その子孫の名前すべてを存在しない（NXDOMAIN）として扱うことが規定された。従来のDNS標準ではキャッシュされた情報のうち不存在情報の扱いは非常に限定的であったため、大きな変更点である。

例：フルリゾルバがexample.jpのNXDOMAINを受け取り、キャッシュしている場合に、sub.example.jpクエリを受け取るとNXDOMAINを返してよい

DNS用語集（RFC 7719）について

　2015年以降に発行されたRFCのうち筆者がかかわっているものが2本ある。

　筆者が2014年11月にDNS用語にあいまいさがあることを示すInternet Draftを投稿したところ、同様のことを考えていたPaul Hoffman氏から誘いをいただき、Andrew Sullivan氏と3人でDNS用語をまとめるdraftを進めることとなった。IETFで大活躍されている2人とドキュメントを進めることで、最初の提案から1年でRFCとして発行された。アイデアの標準化には、要求やいいアイデアだ
けではなく、いい共著者が重要である。現在は、さらに用語を収集し、用語の再定義を進めている。特に、"domain name"の定義を変更しようとしているので、コメントを求む。

DNSSEC検証時の性能向上（RFC 8198）について

　RFC 8198は、DNSSECの不存在情報を用いて名前解決を効率化するものであり、実装するとルートDNSサーバーへのクエリを劇的に減らすことが期待できる。筆者と慶應義塾大学／WIDEプロジェクトの加藤朗先生とで2015年3月にdraft-fujiwara-dnsop-nsec-aggressiveuseとして提案したところ徐々に興味を持たれ、1年後にはルートだけで対応するという簡略化した対抗案が提案された。2016年4月のミーティングで我々の提案と簡略化した提案のどちらが好ましいかという議論が行われ、我々の提案が好まれた。

　そのあと、対抗案の著者の1人であるGoogleのWarren Kumari氏に共著者になっていただき、dnsop WGでの標準化を進めた。その過程で、すばらしいコメントが多数寄せられ、細かい手順などの記載を削除し、RFC 4035やRFC 5155に書いてある方法で検証するといった簡素な表現に変更することができた。

　また、GoogleではGoogle Public DNSに提案手法を実装し、ルートへの無駄な不存在応答となるクエリが激減したそうである。その結果、標準化作業が進展し、最初の提案から2年でIESGに提出でき、2017年6月8日にIESGにて発行が承認され、7月25日にRFC 8198として発行された。

プロトコルで使用するTLDの予約について

　2014年ごろからdnsop WGで活発な議論が行われているテーマの1つはトップレベルドメイン（TLD）の予約である。Torで使用される.onionは広く使用され、正式な証明書が発行されていた。プロトコルで使用するTLDとしての.localの予約に気付いた人たちがTorなどで使用している多くのTLD、.onionや.exitなどの予約提案をしたことが議論の原因であり、.localの反省でdnsop WGが議論を取り扱うこととなった。

　TLDの委任や予約についてはICANNの守備範囲であり、IETFでは取り扱いたくないという意見や、ICANNに登録すると高い金がかかるため、IETFで無料で予約したいといった意見があり、結論が出ずに議論が続いていた。

　.onionについては正式な証明書が発行されており、証明書発行の業界団体から予約されない場合の発行済証明書の無効化期限を示されたため、2015年10月にRFC 7686で.localと同じ方法で予約された。

　また、家庭のネットワーク環境を実現するhomenet WGでは、RFC 6761の手続きなしに.homeというTLDを予約して使うというRFC 7788を標準化してしまい、大問題となり、最終的にIETFチェアが誤りを認める事態となり、.homenet TLDを予約する提案に変更した。

　その後もTLD予約は結論が出ない議論となっていたが、IAB（Internet Architecture Board）が2017年3月30日、IETFのプロトコルで使用する特殊用途のドメイン名を.ARPA TLD以下に用意することが適切であるという声明を発表した。そのため、homenet WGは、.home.arpaを使用するという提案に変更した。

最新の議論

　IPv6の実装に伴い2000年ごろから1つのクエリでAとAAAAの両方を得たいという要求が何度も提案されたが、標準化には至らなかった。また、dane WGで標準化したTLSAリソースレコードを、サーバーのIPアドレスと同時に得たいという要求もある。TLSAの場合はクエリ名が異り、"_443._tcp.サーバーのドメイン名"となる。

　最近になって、1つのクエリで複数の応答を返す提案の議論が再開された。これまでに複数のタイプのクエリを同時に送る提案（draft-bellis-dnsext-multi-qtypes）、ゾーン管理者がAdditional sectionに応答を追加する提案（draft-wkumari-dnsop-multiple-responses）、通常のクエリに別のクエリを追加して送り、複数の回答を1つのDNS応答に混ぜる提案（draft-yao-dnsop-accompanying-questions）があり、それ以外にもいくつかの方法が考えられる。今後、より深い議論が行われる見込みである。

　また、DNSの応答コード（RCODE）は4ビットであり、0から15の値しか返せないが、EDNS0には8ビットのEXTENDED-RCODEが用意されているため、これを使ってDNSSEC検証についての詳細なエラーコードなどを返すことが提案されている（draft-wkumari-dnsop-extended-error）。

　DNSに大きな影響を与えそうな提案も行われている。ゾーン頂点には必ずNS,SOAリソースレコードがあるため、CNAMEリソースレコードを書けないが、ゾーン頂点ドメイン名のウェブサーバー（例えばhttp://example.jp/）をCDNに預ける場合、example.jpにCNAMEを書きたいという要求がある。これに対応するため、いくつかのCDN事業者がゾーン頂点へのクエリに対してCNAMEを返す権威DNSサーバーを実装・運用しているが、この動作はDNSでは推奨されていない。この問題を解決するために、ゾーン頂点にCNAMEの代わりとなるANAMEリソースレコードを書けるようにして、クエリを受け取った権威DNSサーバー側で名前変換を行うという提案（draft-ietf-dnsop-aname）が行われ、熱い議論が行われている。

終わりに

　DNSは30年以上使用されている非常に古いプロトコルであるが、現在も活発な機能拡張が続けられている。従来との互換性を保った上での機能追加や攻撃耐性向上のためのチャレンジは非常に興味深いため、参加する人が増えることを期待する。また、変更されると困る人も議論に参加されたい。