インターネットを支え続ける老舗プロトコル、「DNS」30年超の歴史を振り返る

dnsop（DNS Operations）WG

　DNSプロトコルそのものの標準化は、DNSプロトコル拡張を行っていたDNS Extensions（dnsext）WGが2013年に完了すると、DNSの運用ガイドラインを作成するDNS Operations WG（dnsop）に引き継がれた。dnsop WGは、従来はDNSに関する推奨される運用手順などを作成してきており、ルートDNSサーバーの運用要求仕様（RFC 2870→RFC 7720)、DNS Anycast（RFC 3258）やDNSでのIPv6トランスポートの運用ガイド（RFC 3901）、DNSを用いた攻撃対策（RFC 5358）など、多数のドキュメントを作成してきている。dnsop WGのCharterには、DNSの運用に関するガイドラインを作成するという目的に加え、2014年に既存または新しく発生するDNSの問題に対応する場を提供するという機能が追加された（"Serve as a home for drafts that document the problem space around existing or new DNS issues"）。そのため、dnsop WGには完了条件がない。

※最近の標準化については次回、紹介する。

dprive（DNS PRIVate Exchange）WG

　米国政府による情報収集活動の実態が2013年に暴露されたことに伴い、IETFは広範囲の通信傍受は攻撃であるという立場をとり、すべての通信の暗号化を進めることとなった。ところが、DNSではDNSSECも含めてすべての通信は平文であったため、IPアドレスごとの問い合わせ内容（クエリ名、クエリタイプ）を傍受可能であった。この問題を解決するため、dnsop WGではDNS通信路の暗号化を行う活動を別のWGで行うこととし、2014年にdprive WGを立ち上げた。

　dprive WGでは、当初はいろいろな暗号方式が提案されたが、IETFが策定した暗号通信路であるTLSおよびDTLSにDNSプロトコルを通すDNS over TLSとDNS over DTLSとして標準化を完了した。DNS over TLSは2016年5月にスタンダードトラックのRFC 7858として発行され、DNS over DTLSは2017年2月に実験的プロトコルのRFC 8094として発行された。

　DNS over TLSのサーバーはTCPポート853で待ち受け、接続を受け取るとすぐにTLSの接続処理を開始し、復号したデータを従来のDNSサーバー機能が応答する。TLS通信路を流れるデータはTCP通信路を通るDNSデータの形式（ネットワークバイトオーダーで16ビットのDNSデータ長とDNSデータ）である。

　DNS over TLSはすでに実装されており、サーバーとしてUnbound、クライアントとしてgetdns APIを使用すると使うことができる。

　これまでは、スタブリゾルバとフルサービスリゾルバの間の通信の暗号化に取り組んできたが、今後はフルサービルリゾルバから権威DNSサーバーの間の通信の暗号化の標準化作業を進める見込みである。

dane（DNS-based Authentication of Named Entities）WG

　DNSSECが使用可能になると、DNSSECを用いて認証や暗号通信を行うという要求が現れ、DNSにTLSで使用される証明書やOpenPGPの公開鍵を載せるというプロトコルを標準化するdane WGが2010年に設立された。

　dane WGでは、2012年にDNSにサーバー証明書やCA証明書を載せるTLSA RRが定義された。2015～2017年には、SMTPでの使用法や、OpenPGPの個人証明書、S/MIMEの個人証明書の扱いなどが議論された。OPENPGPKEY RRは2016年8月にRFC 7929として発行された。残るSMIMEAドキュメントは2017年3月20日にIESGから発行承認され、 2017年5月31日にRFC 8162として発行された。 dane WGは、目標が完了したため、SMIMEAドキュメントの発行承認の翌日、 2017年3月21日に完了（Concluded）した。

　TLSAリソースレコードを用いると、サーバー証明書をTLSAリソースレコードに記述してDNSSECで守るという使い方ができ、ブラウザーはDNSSEC検証をもとにサーバー証明書を信用するという使い方ができる。

　ブラウザーはwww.example.comを閲覧する際に、"_443._tcp.www.example.com TLSA"クエリを送り、サーバー証明書情報を入手したあと、www.example.comのTCPポート443に接続することで、サーバー証明書が一致することを確認できる。

　OPENPGPKEYやSMIMEAは、メールアドレスに対応するOPENPGPやS/MIMEのクライアント証明書の情報をDNSに載せるという提案であり、この仕組みが広まるとPGPのKey serverが不要になり、すべての情報をDNSに載せることができるようになる。

　 OPENPGPKEYで署名するメールを送る場合には、相手のメールアドレスに対応するOPENPGP公開鍵を知る必要があり、従来は複数のKey serverから取り出すか事前に設定しておく必要があった。今後、OPENPGPKEYの使用が広まった場合は、送り先メールアドレスをもとにOPENPGPKEY RRを取り出すことで、送信先のOPENPGP公開鍵を安全に取り出すことができ、それをもとに暗号メールを送ることができる。受信時も同様である。

dnssd（Extensions for Scalable DNS Service Discovery）WG

　dnssd WGはDNSを使ったサービスディスカバリを作るWGで、Multicast DNS（mDNS、RFC 6762）とDNS-SD（RFC 6763）をベースに、複数ネットワークセグメントに対応したものを標準化しようとしている。Multicast DNSは、単一リンク内での名前解決機構であり、複数のリンクがある大規模組織で利用するには、リンク間を中継する機構がいる。現在、複数のリンクに接続するハイブリッドプロキシーを準備し、リンクごとにドメイン名を設定して、ハイブリッドプロキシーがドメイン名やMulticast DNSの問い合わせと応答を書き換えるという仕組みによる標準化が進んでいる。

　Multicast DNSでは、図のように、各ノードは自分の名前とIPアドレスの対応を知っていて、マルチキャスト（FF02::FBまたは224.0.0.251 ポート5353 UDP）での問い合わせに応答する。全ノードへの問い合わせもできる。

　DNSを使ったサービスディスカバリでは、指定した名前でサービスのリストを取得するという仕組みで、1つのサービスに複数の機器が対応する場合、Multicast DNSの場合には複数の機器が同時に応答するかたちで発見し、通常のDNSを用いる場合は管理者が静的に列挙しておくかたちとなる。

　Multicast DNS、DNSを使ったサービスディスカバリは、フリーソフトウェアのAvahiとAppleのOSに実装されている。また、今後標準化するプロトコルとして、Appleがすでに実装しているいくつかの機能が紹介され、好意的に議論されている。

　Multicast DNSでは同じリンク内のクライアントからのクエリには無条件で答えるため、プライバシーの懸念があり、プライバシー拡張の議論が進められている。具体的には名前解決を行いたい2台のデバイス間でPIN（暗証番号）を入力したり、QRコードを利用して暗証番号を交換することとし、暗証番号を知らないクライアントは名前を知ることができないという仕組みである。

　今回は、DNSに関する標準化と、いくつかのWGの標準化活動を紹介した。次回は、dnsop WGの最近の活動を紹介する。