ニュースレターNo.62/2016年3月発行

第94回IETF報告　DNS関連WG報告

dnsop WG (Domain Name System Operations WG)報告

dnsop WGの会合は、150分枠で開催されました。 まずは恒例の、Internet-Draftの状況確認から行われました。 前回の会合から、3本のRFCが発行されたことが報告されました。 RFC7583、RFC7646、RFC7686です。 他にもWGラストコールが行われているInternet-Draftが6本あり、 活発な活動が行われていることを感じられました。 次に、draft-jabley-dnsop-refuse-anyに関する発表と議論が行われました。 このInternet-Draftは、 ANYクエリによってパケットサイズの大きな返答が返ってしまうことを防ごうという趣旨の提案です。 昨今、DNSを用いた増幅攻撃が問題となっているため、 ANY!=ALLの解釈のもとに、 返答パケットのサイズを減らす提案が行われました。 WG Internet-Draftとする方向で議論が行われました。

さらに、RFC6761bisに関する発表と議論が行われました。 RFC6761は、“Special-Use Domain Names”というタイトルであり、 ドメイン名の空間をDNS以外の用途(「従来のドメイン名とIPアドレスの相互変換ではなく、 サービス発見のため」「DNSの仕組みは使いながらも、 そのセマンティクスは従来のDNSではない」など)に使う場合の注意事項を述べたものです。 しかし、この特別なドメイン名を決定するプロセスや条件に関する記述が不十分だという意見が出され、 文書を改定するためのデザインチームから報告が行われました。 特に、RFC2860にて述べられているIANAの役割定義に関するMoU (覚書)に反するのではないかといった意見が出され、 議論が続きました。 今後も議論が継続される模様です。

他にも、draft-jabley-dnsop-ordered-answers、 draft-ogud-dnsop-maintain-ds、 draft-muks-dnsop-dns-message-checksums、 draft-muks-dns-message-fragments、 draft-wessels-edns-key-tagに関する発表と議論が行われました。 それぞれの概要を紹介します。

draft-jabley-dnsop-ordered-answersは、 DNSの返答パケットにおけるそれぞれのセクションにて、 どの順番でRR (Resource Record)を並べるかを提案したものです。

draft-ogud-dnsop-maintain-dsは、DSレコードの管理において、 DSを初めて導入する場合とDSを消す場合について、 CDSとCDNSKEYレコードを用いて子ゾーン側からその意思を示す手法を提案しています。

draft-muks-dnsop-dns-message-checksumsは、 UDPパケットのフラグメントを用いて偽の情報を覚え込ませようとする攻撃を防ぐために、 EDNSオプションとしてDNSメッセージのチェックサムを定義しようという提案です。

draft-muks-dns-message-fragmentsは、 DNSの返答パケットがフラグメントされる場合の問題点を述べ、 DNSメッセージのフラグメントを廃止しようという提案です。

最後に、draft-wessels-edns-key-tagは、 RootゾーンのKSK更新が計画されているため、 新しいKSKに更新された際に、 リゾルバサーバのトラストアンカーがどの程度更新されたかを判別できるように、 Key IDをつけようという提案です。

他にもいくつかの発表と議論が行われ、 時間いっぱい会合が行われました。 dnsop WGは、引き続き活発な議論が行われていくと思われます。

dprive WG (DNS Private Exchange WG)報告

dprive WGの会合は、120分の枠で開催されました。 まず、Internet-Draftの状況が確認され、 続いてdraft-ietf-dprive-dnsodtlsに関する議論が行われました。 この文書は、DTLS (Datagram Transport Layer Security)をDNSに用いるという提案です。 今回は、DTLSでのパケットサイズ増加による、 フラグメントの問題に関して議論が行われました。 どのようにフラグメントを防ぐか、という意見が交換されましたが、 DNSに限らずDTLSを利用した場合に発生する問題であるため、 フラグメント自体を発生しないようにする手法を提案する方向になりました。

次に、draft-ietf-dprive-dns-over-tlsに関する発表と議論が行われました。 DNS-over-TLSのドラフトは、 WGラストコールに向けて問題点を改善しており、 その経過報告が行われました。 この文書は、TLSを用いたDNSサーバの認証を提案しており、 その実装の進捗状況についても報告されました。 ポート番号としては、853番が割り当てられています。

さらに、 draft-krecicki-dprive-dnsencについての発表と議論が行われました。 これは、トランスポート層プロトコルとは独立させて、 DNSのトランザクションを暗号化しようという提案です。 NSK RRという新しいリソースレコードで、 サーバの公開鍵を公開することで、 DNSトランザクションを暗号化します。 当然、DNSSECとの併用が必要となります。 この提案に対して、 サーバに対してのDDoSを容易に行うことができるのではないか、 またアプリケーションレベルで暗号化を再度定義するのは冗長なのではないか、 といった意見が出されました。 引き続き議論が行われます。

この他にも、draft-wing-dprive-profile-and-msg-flows、 draft-am-dprive-evalといった文書に関して、 発表と議論が行われました。 drpive WGでは、DNS over DTLS、 DNS over TLSといった提案を基本とし、 DNSのプライバシー問題解決という重要かつ困難な問題を解決するため、 引き続き議論が行われます。

dnssd WG (Extensions for Scalable DNS Service Discovery WG)報告

dnssd WGは、DNSを用いたサービス発見を、 さまざまな範囲にて行うプロトコルを実現するためのWGです。 まず、Internet-Draftの確認が行われました。 draft-ietf-dnssd-hybridならびにdraft-ietf-dnssd-pushがWGラストコール直前であること、 またdraft-ietf-dnssd-mdns-dns-interopのWGラストコールが終了し、 IESGレビューに回す前の修正段階であることが報告されました。

会合では、draft-otis-dnssd-scalable-dns-sd-threatsについての発表と議論が行われました。 これはdnssdを実現するにあたっての、 セキュリティ脅威を分析した文書です。 dnssdにおけるサービス発見範囲はマルチキャストによって限定されているため、 いくつかのセキュリティ的な懸念点が存在することを述べています。 まだ広く理解を得られる文書となってはいないといった指摘があり、 引き続き議論が行われます。

次に、draft-ietf-dnssd-pushと、 draft-ietf-dnssd-hybridに関する発表と議論が行われました。

draft-ietf-dnssd-pushは、 DNSのレコードが変更された場合にその更新を動的に通知する仕組みを提案した文章です。 今までのDNSでは、 たとえ権威DNSサーバにおいてレコードが更新された場合でも、 リゾルバDNSサーバにおいてキャッシュの保持時間が残っている間は、 再度権威DNSサーバへの問い合わせを行わない仕様となっています。 そのため、 ユーザーには古いレコード情報が返答される結果となります。 この提案では、 限られた範囲内のリゾルバDNSサーバに対してレコードの更新を通知することで、 頻繁なレコード更新に追従できるサービス発見を実現することを目的としています。

またdraft-ietf-dnssd-hybridは、 Multicast DNSによるサービス発見の結果を、 Unicast DNSの名前空間にマッピングする手法を提案しているものです。

どちらの発表も、前回会合からの改善点についてのまとめでした。 また、大きな問題点の指摘も無く、 WGラストコールが行われることが確認されました。

最後に、 draft-aggarwal-dnssd-optimize-queryに関する発表と議論が行われました。 この文書は、dnssdの規模性を危惧し、 その規模性を向上させるために、 TXT RRにAllJoynに従ったkey/valueペアの情報を入れることで、 クライアントに検索のためのヒントを与え、 検索回数を減らすという提案です。 AllJoynは、 AllseanアライアンスによってIoTのために制定された規格であり、 機器のプロファイルや、 機器と機器の連携に関する情報などを提供するフレームワークです。 このAllJoynをどうdnssdに組み込んでいくのか、 今回の発表と文章からでは、まだはっきりと理解できませんでした。

(JPNIC DNS運用健全化タスクフォースメンバー／東京大学 情報基盤センター 関谷勇司)