進化するインターネット技術/IETFトピックス2016-17

第6回

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

インターネット技術の普及に向け、IPv6、DNS、HTTPなど基本となるプロトコルを定めてきたIETF(The Internet Engineering Task Force)。今年11月には、100回目の会合(IETF 100)がシンガポールにて開催される予定である。IETFがこれまで手がけてきたインターネット技術も、技術の進歩と普及により、現在も多くの分野において議論が継続され、まだまだ目が離せない状況が続いている。本連載では、インターネットの普及と発展を目的に日ごろIETFを中心に活動を行っているISOC-JP(Internet Society Japan chapter)メンバー有志が、ここ最近のIETFでの活動状況について紹介していく。

 今回から2回にわたり、IETFの活動のうち、DNSプロトコルについての標準化動向を取り上げる。まずは今回、これまでの標準化の経緯とワーキンググループ(WG)の構成について述べ、dprive WG、dnssd WG、dane WGを紹介する。

DNSプロトコル標準化の歴史

 DNSは1987年に発行されたRFC 1034、RFC 1035が有効であり、30年以上使い続けられている非常に古いプロトコルである。古いプロトコルではあるが、新しいアプリケーションへの対応や攻撃への対策、性能・機能向上などのためにさまざまな拡張が行われてきた。拡張の場合には、従来のプロトコルとの互換性が最大限考慮されている。

 初期にはドメイン名からIPアドレスへの対応付け(Aリソースレコード)やメールの配送(MX)、逆引き(PTR)が主なアプリケーションであったが、IPv6アドレスへの対応(AAAA、RFC 1886、1995年)やサービスロケーションの指定(SRV、RFC 2052/2782、1996年)などの新しいアプリケーションへの拡張が行われた。SRVは、IP電話で使用されるSIPや、サービスディスカバリで使用される。

 1990年代後半にはインターネットの急速な普及に対応するため、差分ゾーン転送(IXFR、RFC 1995、1996年)、ゾーンの更新通知(NOTIFY、RFC 1996、1996年)、動的更新(Dynamic Update、RFC 2136、1997年)といった機能が追加された。また、DNSSECやIPv6に対応するため、512バイトを超えるメッセージサイズをUDPで扱えるようにし、フラグや応答コードも拡張したEDNS0(RFC 2671→RFC 6891、1999年)も標準化された。1994年から2008年にかけて標準化されたDNS Security Extensions(DNSSEC、RFC 4033/4034/4035/5011/5155など)は、DNSに電子署名を付加し、改ざん検知機能を追加した。

 2008年以降にはDNSSECの普及に必要な拡張や攻撃対策のための拡張が行われた。例えば、2009年にはキャッシュ汚染攻撃対策技術のまとめと、ソースポートランダマイゼーションの実装を勧めるRFC 5452が発行されている。また、DNS/UDPの攻撃耐性を上げるため、DNSクエリに64ビットのCookieを添付、サーバーがそのCookieを応答にコピーし、送信Cookieと受信Cookieが異なる場合には異常とするDNS Cookiesが標準化され、RFC 7873として2016年に発行された。

 また、2013年には、単一リンク内のみで最小限の設定で動作するDNSライクな名前解決機能を提供するMulticast DNSが標準化された。Multicast DNSは、2003年ごろにDNSプロトコル拡張を担当するdnsext WGでの標準化が提案されたが、WGに提出されたAppleの提案とMicrosoftの提案は双方とも企業が開発したプロトコルがベースとなっていたことと、インターネットで使用するプロトコルではないために、dnsext WGでは扱われなかった。そのあと2008年に、AppleのプロトコルをベースとしたMulticast DNSがIETFのWG以外からの標準化としてIESGに提出され、2013年に標準化された。

 このMulticast DNSの仕様の一部に特定のプロトコルで使用されるTLDの予約方法と.local TLDの予約が含まれていたことから、dnsext/dnsop関係者が気付きにくいかたちで標準化が進み、RFC 6761として発行された。

DNS年表
1983年DNSの最初のバージョンRFC 882/883
1983~1985年に実装
1985年最初の.comドメイン名の登録と使用開始(symbolics.com)
1987年DNSプロトコル(RFC 1034、RFC 1035)発行
1994年DNSSEC標準化開始
1996年差分ゾーン転送(RFC 1995)、 NOTIFY(RFC 1996)
1997年Dynamic Update(RFC 2136)
1995年IPv6対応(AAAAリソースレコードの追加、RFC 1886)
1996年SRVリソースレコードの追加(RFC 2052)
1999年EDNS0(RFC 2671)
2005年DNSSECの基本プロトコル発行(RFC 4033/4034/4035)
2008年DNSSECをTLDで実装する上で必要とされていたNSEC3(RFC 5155)
2010年DNSSEC運用開始(RootがDNSSEC対応)
2013年Multicast DNS(RFC 6762)と.localの予約(RFC 6761)
2016年DNS Cookies(RFC 7873)

DNS関連ワーキンググループの紹介とそれぞれの目的

 IETFでは、標準化の要求・必要性ができると、範囲や目標を定めたCharterをIESGに提出し、ワーキンググループ(WG)を作り、標準化を行い、完了すると解散する。

 DNS関連プロトコルの標準化は、2015~2017年には、dnsop、dprive、dane、dnssdの4つのWGで行われている。

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のサーバー証明書をDNSに載せる場合

_443._tcp.www.example.com. IN TLSA (1 1 1 d2abde240d7cd3ee6b4b28c54df034b9
7983a1d16e8a410e4561cb106618e971 )

www.example.comのTCPポート443(HTTPS)で使用するサーバー証明書のSHA256

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

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

例:hugh@example.comというメールアドレスのOpenPGPKEYを登録する場合

c93f[...]d6._openpgpkey.example.com IN OPENPGPKEY mQCNAzIG[...]

  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の最近の活動を紹介する。