第88回IETF Meeting報告（前編）

第88回IETF Meeting（以下、IETF 88）が、2013年11月3日から11月8日にかけてカナダのバンクーバーで開催されました。FROM JPRSでは今回から2回にわたり、IETF 88及びそれに合わせて開催された会議で報告・議論された内容について紹介します。

前編となる今回はDNS関連WGにおける話題として、dnsop WG とdnssd WGの状況をお伝えします。

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、DNSの運用全般におけるガイドラインの開発を目的として組織されています

ここでは今回のdnsop WGにおいて議論された話題のうち、FROM JPRSが特に注目したものについてお伝えします。

子から親へのリソースレコードの同期

前回のIETF 87から継続して議論されている、DNSにおける親子間の関係を構築するために親ゾーンに登録されるリソースレコード（DS、NS、グルー）を、子ゾーンにおいて記述・公開するための複数の提案が議論されました。

本件についてはこれまで、CDSとCSYNCという二つの提案が議論されてきました。今回はそれに加え、レジストリ・レジストラモデルにおいてDynamic Update（*1）経由でこれらのリソースレコードを登録するための新たな提案が議論されました。

今回議論された三つの提案の概要を以下に示します。

1）CDS/CDNSKEY（draft-kumari-ogud-dnsop-cds）
CDS/CDNSKEY（Child DS/Child DNSKEY）というリソースレコードを新たに定義し、これらのリソースレコードを用いて更新対象となるDS/DNSKEYリソースレコードを、子のゾーン頂点に記述します。

2）CSYNC（draft-hardaker-dnsop-csync）
CSYNC（Child To Parent Synchronization）というリソースレコードを新たに定義し、このリソースレコードを用いて更新対象となるNS/グルーレコードを、子のゾーン頂点に記述します。
前回のIETF 87以降の調整によりDNSSEC関係のリソースレコードはCSYNCの対象から外され、NSとグルーをその対象とすることになりました。

3）Dynamic Update（draft-andrews-dnsop-update-parent-zones）
レジストリ・レジストラモデルにおいてレジストラが登録者からリソースレコードの書き換えを受け付ける際、Dynamic Updateを使用してリクエストを受け付けます。登録者の認証は、レジストラが登録者にTSIG（*2）の鍵を発行することで実施します。

会議では、Dynamic Updateが採用しているプッシュ型（登録者から能動的に更新を伝達）の機構についても議論内容に含めた上で、今後も継続して検討を進めていくことになりました。

バリデーターの増加に伴うDS問い合わせ数の増加とその対応

DNSSECの普及促進を図る際にTLDにおいて特に問題となりうる、バリデーターの増加に伴うDS問い合わせ数の増加とその対応について、JPRSの藤原が発表を行いました（draft-fujiwara-ds-query-increased）。

DNSSEC普及の初期段階ではDNSSECに対応しているドメイン名の数が少ないため、TLDゾーンにおけるDSレコードの登録数も少なくなります。この状況ではTLDの権威DNSサーバーに到達するDSレコードの問い合わせの多くが不在応答（そのリソースレコードは存在しない）となり、この応答のキャッシュとして、TLDゾーンのネガティブキャッシュのTTLが使用されます。

.jpゾーンでは、この値は900（15分）に設定されています（*3）。そのため、

1）DNSSECに対応していない（DSレコードが登録されていない）
2）かつ、頻繁にアクセスされる（例：毎秒1回以上）
3）かつ、A/AAAAレコードのTTLが900よりも短い（例：300）

という三つの条件を満たしたドメイン名の場合、バリデーターからTLDの権威DNSサーバーへのDSレコードの問い合わせが、最短の場合15分に1回という短い間隔で発生することになります（*4）。

藤原からは、将来のバリデーターの数の増加によりTLDの権威DNSサーバーへのDSレコードの問い合わせ数が急増し、TLDの権威DNSサーバーの負荷やネットワークの帯域が増大する可能性があることを指摘しました。

そして、その対策として

・負荷の増大に対応するための回線や機材を増強する
・TLDのネガティブキャッシュのTTLを長くする
・そのTLD内においてDNSSECに対応したドメイン名の数を増やす

といったもののほか、安全でない委任（unsecure delegation）を明示的に定義するためにDSレコードにおいて新しいダイジェストタイプを追加する案を示した上で、有効な対策方法について会場の参加者にコメントを求めました。

会場からは、DNSSEC対応を促進するためにDNSSEC対応／未対応のドメイン名で価格差をつけるのが有効ではないかというコメントや、Google Public DNSでは未知のダイジェストタイプを持つDSレコードを設定したドメイン名がDNSSEC検証エラーになったという報告がありました。

また、WGチェアから藤原に対し、本件については現時点では問題が顕在化していないが将来のために文書化しておくことが重要であり、今回コメントを受けた問題点とその対応策について文書に反映・更新するように、という指示があり、今後も文書の更新作業を進めていくことになりました。

AS112プロジェクトの改善案

AS112プロジェクト（以下、AS112）は、インターネット上には存在しないプライベートアドレスやリンクローカルなどの逆引きゾーンをルートゾーンから委任することにより、本来送られるべきではない不正なDNS問い合わせをルートサーバーから分離するために始められました。

AS112では、IP Anycastを用いたサーバーノードの冗長化が採用されています。しかし、権威DNSサーバーにおける通常のIP Anycastとは異なり管理対象のゾーン情報が構成するノード間で同期されておらず（*5）、対象となるゾーンが追加された場合に個々のノードにおいて速やかにゾーンを設定・公開することが難しいという問題点が指摘されていました。

そこで、親ゾーンにおいて対象のゾーンを委任する代わりにDNAMEレコードを設定することでこの問題を解決する提案が示され、前回のIETF 87において実環境への適用を進めていくことが合意されました。この提案が実現された場合AS112を構成するノードではempty.as112.arpaというゾーンのみが管理され、対象となるゾーンはこのゾーンへのDNAMEとして設定されます。

会議では前回の合意に従い、提案文書を更新したことが報告されました（draft-jabley-dnsop-as112-dname）。今後この文書はWGドキュメントとして、6304bis（RFC 6304の更新版）の名で更新作業を進めていくことになりました。

前回のIETF 87でdnssdext BOFとして開催されたdnssdが、2013年10月25日付で正式なWGとして発足しました。

dnssdはExtensions for Scalable DNS Service Discovery（スケーラブルなDNSサービス発見のための拡張）に由来しており、DNSを用いたservice discovery（サービス発見：提供可能なサービスを検索・通知する手法、DNS-SDとしてRFC 6763で定義）の仕様を拡張し、企業や大学などといった大規模なネットワークにおいても動作可能にするための手法を標準化することを目的としています。

今回のdnssd WGでは当面の目的であるDNS-SDとRFC 6762で定義されるMulticast DNS（以下、mDNS）を、現在運用されているDNSと共存しうる形で拡張するために必要な各項目についての議論が進められました。

ローカルな名前解決のためのTLDの予約

DNS-SDや組織内におけるローカルな名前解決を円滑に実施するためには、ローカルな（インターネット上に存在しないことが保証されている）TLDを使用することが有効な手段となります（*6）。

会議では今後標準化を進める拡張規格において、このTLDをどのように選択・決定するかについて議論されました。会場からは、

・現在の.localを転用する
・新しいTLDを予約する
・TLDではなくSLDを使用する

などの候補が挙げられましたが結論には至らず、今後も継続して検討を進めることになりました。

スケーラブルなDNS-SD／mDNSの拡張

DNS-SD／mDNSを拡張するために必要となる要件定義の項目について発表・議論されました（draft-lynn-dnssd-requirements）。

発表では、

・同一リンク内からインターネットまでの名前解決に対応すること
・使いやすいこと（Usability）
・スケーラブルであること（Scalability）
・段階的な普及、小型デバイスでも動作し、大規模な機器を必要としないと いった、普及可能性（Deployability）
・使用するにあたっての安全性（Security）

などが項目として示され、その後の議論において、既存のDNS-SD/mDNSに悪影響を及ぼさないことも要求事項とされました。議論の結果、要件定義について今後WGとして検討を進めていくことが合意されました。

国際化ドメイン名の表現形式

DNS-SDの現在の規格（RFC 6763）では国際化ドメイン名の表現形式としてU-Labelを使用することが推奨されており、DNS問い合わせに対し不在応答が返された場合、クライアントソフトウェアは当該のU-LabelをASCII互換形式のA-Labelにより再問い合わせを実行してもよいと定められています（*7）。

この手法を広域ネットワークにおいてそのまま使用した場合、インターネット上のDNSサーバーに対するU-Labelによる問い合わせが発生し、DNSの運用に悪影響を及ぼす可能性があります。

会議では、拡張規格において国際化ドメイン名の表現形式をどのように定義すべきかという問題提起がされました（draft-sullivan-dnssd-label-miprofile）。会議では、DNS-SDのAPIにおいてU-LabelをA-Labelに変換するなどのアイディアが出されましたが結論には至らず、今後も継続して検討を進めることになりました。

後編となる次回のFROM JPRS増刊号では、DNS関連以外のWGにおいて議論された注目すべき話題、IETFに併設される形で開催されたIEPG Meetingにおける話題についてお伝えします。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。