JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト


ドメイン名関連会議報告

2016年

第95回IETF会合(ブエノスアイレス)報告(後編)

~レジストリ関連/周辺会合における話題~

今回のFROM JPRS増刊号では前回に引き続き、第95回IETF会合(以下、IETF 95)の後編として、regext WGとIETF 95に併設される形で開催されたRegistrationOperations Workshop #4(以下、ROW#4)、IEPG会合、DNS-OARC Public Workshopにおける話題について報告します。

今回は、以下の項目に沿って会合の模様をお伝えします。

  • regext WG及びROW#4における話題
    - regext WGにおける話題
    - ROW#4における話題
  • IEPG会合における話題
    - ns.icann.orgの状況
    - TLD別の国際化ドメイン名(IDN)の利用状況
  • DNS-OARC Public Workshopにおける話題から
    - 2015年11~12月のルートサーバーへの大量トラフィックの分析
    - ルートゾーンにおけるZSKサイズの拡大予定
  • 次回のIETF会合について
会場となったHilton Buenos Aires

会場となったHilton Buenos Aires

regext WG及びROW#4における話題

レジストリ・レジストラ間の登録情報のやりとりに用いられるプロトコルを取り扱うregext WGが2016年4月4日に、レジストリの運用面を取り扱うROW#4が2016年4月2日に開催されました。

これらの会合には、ICANNやRIR、TLDレジストリを中心とした関係者が集い、EPP(*1)やRDAP(*2)などの話題が共通して扱われました。

(*1)
Extensible Provisioning Protocolの略称。
ドメイン名の登録情報をレジストリとレジストラの間で交換するために設計されたプロトコルです。拡張性の高さを特長としており、ドメイン名だけでなくIPアドレスなど、他の情報のレジストリにおける利用も考慮されています。
(*2)
Registration Data Access Protocolの略称。
登録情報にアクセスするためのプロトコル。URIによりデータが渡され、JSON(JavaScript Object Notation:JavaScriptのオブジェクト表記方法に由来する簡便なデータ記述法)の形式で応答が返されます。

regext WGにおける話題

EPPの機能拡張のために組織されたeppext WGの活動対象を拡大し、RDAPなどレジストリ関連のプロトコルを扱えるように再編成されたregext WGが、2016年3月4日に設立されました。今回がWG設立後、初の会合となりました。

今回のWGでは、eppext WGの残りの提案の標準化作業の状況が確認され、メーリングリストでコメントを確認した後にワーキンググループラストコール(WGLC)を実施することとなりました。

また、新しい提案として、EPPに関する提案3件(draft-brown-epp-fees、draft-zhou-eppext-reseller-mapping、draft-lozano-ietf-eppext-registrar-expiration-date)と、RDAPに関する提案1件(draft-lozano-rdap-nameservers-sharing-name)の内容が検討されました。

ROW#4における話題

Registration Operations Workshop(以下、ROW)(*3)は、DNSへの登録オペレーションの運用面を議論することを目的として設立されたフォーラムです。

(*3)
Registration Operations Workshops (ROW)
http://regiops.net/

4回目の会合となるROW#4では、RDAPの実装と運用に関する報告と議論が行われました。ここではROW#4で報告・議論された話題のうち、FROM JPRS編集局が注目したものについてご紹介します。

▽Verisign LabsでのRDAP実装実験報告

Verisign Labsがツバル(.tv)とココス諸島(.cc)のccTLDで進めているRDAPの実装実験の状況が報告され、RDAPにおけるクライアント認証の仕組みとしてOpenID Connect(*4)を利用していることが発表されました。

(*4)
OAuth 2.0(RFC 6749で定義される、HTTPサービスを用いたサービス認証の枠組み)を拡張した、運用主体が異なるサービス間におけるID連携のためのプロトコルであり、米OpenID Foundationが策定・普及活動を進めています。

▽.czでのRDAP実装報告

チェコ(.cz)のレジストリであるCZ.NICがオープンソースソフトウェアとして開発しているレジストリシステムFRED(*5)における、RDAPの実装状況が報告されました。

(*5)
FRED(Free Registry for Enum and Domains)
https://fred.nic.cz/

今回の報告では、FREDのRDAP実装における最新のRFCへの対応状況と適合性テストツールによるテストの実施状況、その中で確認されたRFCの不明確な箇所が説明されました。

▽ICANN RDAP Profileに対するパブリックコメントの紹介

ICANNではgTLDのレジストリ・レジストラ向けにRFCの仕様やICANNのポリシーをまとめたRDAPの運用プロファイルを作成・公開し、2015年12月3日から2016年3月18日まで、内容に関するパブリックコメントを実施しました(*6)。

(*6)
Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars - ICANN
https://www.icann.org/news/announcement-2015-12-03-en

今回、期間中に寄せられたパブリックコメントの内容がICANNから紹介・共有されました。なお、期間中にJPRSからRDAPの実装のプロファイルについて、4件のコメントをICANNに送付しています(*7)。

(*7)
パブリックコメントの内容は以下で公開されています。
Staff Report of Public Comment Proceeding
https://www.icann.org/en/system/files/files/report-comments-rdap-profile-25apr16-en.pdf

IEPG会合における話題

IEPG(Internet Engineering and Planning Group)は、IETF会合に先立って日曜日午前に開催される会合で、インターネットの運用に関連するさまざまなテーマを取り扱っています。

ここでは、今回のIEPG会合で報告・議論された話題のうち、FROM JPRS編集局が注目したものについてご紹介します。

ns.icann.orgの状況

ns.icann.orgはicann.orgに加え、.int、.museum、.ug(ウガンダのccTLD)などの権威DNSサーバーとして運用されているホストです。ns.icann.orgは長年にわたって運用されており、かつては.om(オマーンのccTLD)の権威DNSサーバーとしても運用されていました。

今回、ns.icann.orgを運用するICANNのスタッフから、ns.icann.orgに到達するDNSクエリの状況が報告されました。報告では、6bone(*8)でも利用され10年以上前に運用を終了したip6.int(*9)に対するDNSクエリが現在もns.icann.orgのDNSトラフィック全体の59%を占めていること、2012年に権威DNSサーバーから外された.omに対するDNSクエリが現在も到達し続けていることなどが紹介され、インターネットにおいて一度設定された内容は消えることなく残り続けてしまうという状況が共有されました。

(*8)
IPv6の実証実験用として1996年~2006年に運用され、国際的にIPv6の利用環境を提供してきた実験用ネットワークです。
(*9)
IPv6の逆引き用のDNSゾーンとして運用されていましたが現在はip6.arpaに移行され、ドメイン名そのものが廃止されています(RFC 4159)。

TLD別の国際化ドメイン名(IDN)の利用状況

JPRSの藤原和典が、JP DNSサーバーとルートサーバーのDNSクエリの状況から、TLD別の国際化ドメイン名(IDN)の利用状況を分析した結果について報告しました。

藤原からは、IDNに対するDNSクエリ数の比率がJP DNSサーバーでは全体の約0.2%、ルートサーバーでは同じく0.1%、また、クエリを送信するIPアドレス数の比率がJP DNSサーバーでは全体の約3%、ルートサーバーでは同じく2%にとどまっており、DNSクエリの状況からはIDNの普及率がまだ低いことを示している旨を報告しました。

ただし、IDNのクエリを送信するIPアドレスの割合については増加傾向が見られ、特に、ロシアのIDN ccTLD(.рф)では総クエリ数の15.7%がIDNによるものであったことを報告しました。

DNS-OARC Public Workshopにおける話題から

DNS-OARC(*10)が主催する、24回目のOARC Workshop(以下、OARC 24)が、IETF 95の前の2016年3月31日から4月1日にかけ、ブエノスアイレスで開催されました。

ここでは、OARC 24で発表された内容の中から2015年11~12月に発生したルートサーバーへの大量トラフィックの分析と、ルートゾーンにおけるZSKサイズの拡大予定についてお伝えします。

(*10)
DNS-OARC(DNS Operations, Analysis, and Research Center)はDNSの運用・分析・調査研究などを通じ、DNSをより安全で高品質なものとすることを目的として、2004年に設立された国際組織です。DNS-OARCではDNS運用者や研究者間における情報交換や議論を目的としたOARC Workshopを定期的に開催しており、DNS運用者や研究者の活動を支援しています。

2015年11~12月のルートサーバーへの大量トラフィックの分析

2015年11月30日と12月1日に発生したルートサーバーへの大量トラフィックについて、A-Root及びJ-Rootを管理するVerisignから見た状況が報告されました。

報告では、到達したトラフィックはIPv4のUDPによる通常のDNSクエリであったこと、クエリの内容の多くは特定の一つの名前に対するものであり、かつ送信元IPアドレスが偽装されていた可能性が高いと考えられること、防御策としてDNS RRL(*11)が有効に機能したことなどが共有されました。

(*11)
所定の条件によりDNSサーバーの応答頻度を制限するための技術であるDNS RRL(Response Rate Limiting)については、以下の資料をご参照ください。
■技術解説:「DNS Reflector Attacks(DNSリフレクター攻撃)」について
https://jprs.jp/tech/notice/2013-04-18-reflector-attacks.html

なお、この件ではルートサーバーのうちD-Root、L-Root、M-Root以外のサーバーにトラフィックが到達し、複数のルートサーバーのサービスに影響を及ぼしました(*12)。

(*12)
一部のクライアントにおいて、名前解決に遅延が発生した旨が報告されています。

ルートゾーンにおけるZSKサイズの拡大予定

2016年10月1日にルートゾーンのZSK(ゾーン署名鍵)サイズを1024ビットから2048ビットに変更する旨の計画が、VerisignのDuane Wessels氏から発表されました。

DNSSECで用いられる鍵にはKSK(鍵署名鍵)とZSKの2種類が存在し、ルートゾーンではKSKはICANNが、ZSKはVerisignが管理しています。このような背景から今回のZSKのサイズ変更については、ルートゾーンの運用を担当するVerisignの担当者から発表されたようです。

今回の変更の背景の一つとして、現在のZSKで使われている1024ビットの鍵が米国国立標準技術研究所(NIST)の定める安全性の基準を満たさなくなっていることから(*13)、安全性を確保可能な鍵への変更を図るためであることが推察されます。

(*13)
Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf

発表では、ZSKの更新(ロールオーバー)の手順とスケジュールが示され、通常周期による事前公開法で実施予定であること、2048ビットのZSKの事前公開は2016年9月21日を予定していることなどが報告されました。

▽フルリゾルバーにおける影響

ZSKサイズの増加により、DNSの応答サイズが増大します。また、DNSSEC検証を実施するDNSSECバリデーターにおける計算量も、若干増加します。

なお、BINDやUnboundなどDNSSECに対応したフルリゾルバーでは、DNSSEC検証を実施するように設定されているかいないかに関わらずDNSSEC OK(DO)ビットをセットしたクエリを送信するため、DNSSEC署名付きの応答を受け取っていることに注意が必要です。

Verisignからは、今回の変更による障害は発生しないと想定しているが、不測の事態に備えて1024ビットのZSKも作成する予定であり、また緊急時には古いZSKへのロールバックを実施する予定である旨が報告されました。

▽テスト用サイトの公開

会議開催後の2016年5月6日に、Verisignが本件について解説したブログと、DNS応答サイズの増大の影響を診断できるテスト用サイトを公開しました(*14)。

(*14)
Verisign公式ブログ:Increasing the Strength of the Zone Signing Key for the Root Zone | Between the Dots
http://blogs.verisign.com/blog/entry/increasing_the_strength_of_the
テスト用サイト:DNSSEC Key Size Test
http://keysizetest.verisignlabs.com/

Verisignではサイトでのテストに失敗し、かつ問題が解決できない場合、電子メールで連絡してほしい旨を呼び掛けています。

次回のIETF会合について

次回の第96回IETF会合(IETF 96)は2016年7月17日から22日にかけ、ドイツのベルリンで開催されます。

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