メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
    __
    /P▲        ◆ JPNIC News & Views vol.1304【臨時号】2015.4.30 ◆
  _/NIC
===================================
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1304 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2015年3月下旬に米国のダラスにて開催された、第92回IETFミーティングのレ
ポートをvol.1298より連載にてお届けしています。連載最終回となる本号で
は、DNS関連WGの動向をご紹介します。

DNS関連WG報告以外の、全体会議、暗号技術に関する動向、IPv6関連WGの各報
告については、下記のURLからバックナンバーをご覧ください。

□第92回IETF報告 特集
  ○[第1弾] 全体会議報告 (vol.1298)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1298.html
  ○[第2弾] IETFにおける暗号技術に関する動向(楕円曲線) (vol.1299)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1299.html
  ○[第3弾] IPv6関連WG報告 ~6man WG、v6ops WG、sunset4 WG~ (vol.1301)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2015/vol1301.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第92回IETF報告 [第4弾] DNS関連WG報告
                             JPNIC DNS運用健全化タスクフォースメンバー
                                             東京大学 情報基盤センター
                                                              関谷勇司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2015年3月22日(日)から27日(日)にかけて、第92回IETF会合が開催されまし
た。本稿では、DNSに関連した議論の動向として、DNSへの問い合わせをプラ
イバシー情報と見なして前回の第91回IETFから検討を行っているdprive WG
と、定例的に報告しているdnsop WGの活動を取り上げてご紹介します。


■ dprive WG (DNS Private Exchange WG)報告

DNS Private Exchange WGの会合は、2015年3月23日(月)の午後に90分間のセッ
ションとして開催されました。このWGは、前回の第91回IETFから活動してお
り、今回で2回目の会合となります。DNSに問い合わせた名前はプライバシー
に関する情報であり、この情報を攻撃者が盗み見ることによって、多くの情
報を得ることができてしまうという問題を解決するためのWGとなります。

まず、Internet-Draftの確認から行われました。DNSのプライバシーに関する
検討事項について述べたドラフト文書が、IESG (Internet Engineering
Steering Group)のレビューに回されたことが確認され、このプライバシーに
関する検討事項を解決するために現行提案されている手法について、確認が
行われました。

次に、draft-am-dprive-eval-00に関する発表が行われました。この文書は、
DNSの問い合わせに含まれるプライバシー情報を、攻撃者が盗み見る手法に関
してのパターン分類や、それを防ぐための代表的な手法と、その効果の評価
手法に関して述べたものです。dprive WGの出発点となる文書となっていま
す。この発表に関しては、攻撃者が何を狙っているのか、また攻撃のパター
ン分類は適切かといった議論、ならびに「攻撃者」という定義が当てはまる
のかといった用語的な議論が行われました。引き続き、議論される模様です。

さらに、Private DNSに関する発表が行われました。これは、プライバシーを
保った状態で使うことのできるDNSサーバ、もしくは名前解決の仕組みを提供
する手法をまとめた発表でした。Online Certificate Status Protocol
(OCSP)での経験を元に、プライバシーが確保されることで、ネットワーク環
境によって動作しなかったり、名前解決が遅延してしまうようなことが発生
してはならない、という目標が示されました。また、実現手法として、HTTPS
上でのJSON (JavaScript Object Notation)を用いた名前解決や、TCPでのTLS
(Transport Layer Security)を用いた名前解決が提案されました。誰もが名
前解決に使える従来のようなDNSサーバと、プライバシーを確保したい場合に
用いるDNSサーバを、ユーザーが用途に応じて切り替えられることが必要だ、
という議論が行われました。

関連して、draft-hzhwm-dprive-start-tls-for-dnsに関する発表と議論が行
われました。これは名前の通り、DNSのトランザクションにTLSを用いる、と
いう提案です。通常の53番ではなく、TLSを用いたTCPにて通信するための専
用ポート番号を割り当てることを提案しています。この提案に関しては、DNS
はUDP53番ポートと定義しているミドルボックス等も存在するため、新たな
ポート番号での名前解決が、必ずどの環境でもできるとは限らないといった
指摘がありました。また、TLSのオーバーヘッドに関する質問も出ました。こ
れに関しては、実装上の工夫として、TCP Fast Open (RFC7413)(*1)の利用等
が提案されていました。

(*1) RFC7413 "TCP Fast Open"
     https://tools.ietf.org/html/rfc7413

draft-wijngaards-dnsop-confidentialdnsに関する発表と議論も行われまし
た。この文書は、opportunistic encryption、つまり必要な場合だけ暗号化
を要求することを、DNSサーバとクライアントとの間で可能にする手法を提案
したものです。ENCRYPTというリソースレコード(RR)を定義し、このRRを用い
て鍵を交換することで通信を暗号化します。TLSに比べてアプリケーションレ
ベルで暗号化を行うため、この方が負荷が高いのではないかといった議論や、
鍵のやりとりはTCPにするべきでは、といった議論が行われました。引き続き
議論が行われるようです。

最後に、このWGをどのように進めるべきか、の議論が行われました。現在出
ている提案が列挙され、ハミングによる確認が行われました。有力であった
のはDNS over TLSでしたが、引き続き議論が行われます。


■ dnsop WG (Domain Name System Operations WG)報告

dnsop WGの会合は、3月24日(火)の午後、2時間のセッションとして開催され
ました。まずいつも通り、Internet-Draftの確認が行われました。その後、
draft-ietf-dnsop-qname-minimisationに関する発表が行われました。この文
書は、DNSのプライバシー確保にも関連するものであり、DNSへの問い合わせ
において省けるものはなるべく省いて、名前問い合わせを減らそうという提
案です。最終的に解決したい名前を問い合わせるDNSサーバの数を減らす、も
しくは名前を問い合わせる回数を減らすことで、プライバシー情報である、
解決したい名前が漏れることを防ぎます。大きな反対はありませんでしたが、
引き続き議論が行われることとなりました。

次に、draft-ietf-dnsop-root-loopbackに関する発表がありました。前回の
第91回IETFにてWG draftとなった文書で、ホスト自身がルートDNSゾーンを有
して、ユーザーからの名前解決要求に応じて、手元に保持するルートDNSゾー
ンから、TLDに関するRRの検索を行うことを可能にする提案です。これによ
り、今までルートDNSサーバに問い合わせて得ていた情報が、手元に保持する
ゾーンにて得られるため、名前解決に要する最終的な時間を短縮することが
可能になります。また、手元に保持しているゾーンの情報が正しいものであ
るかどうかは、DNSSECを利用して確認します。ルートDNSゾーンはDNSSECにて
署名されているため、改竄から守られており、手元に保持しているものが改
竄されたとしても判別できます。

さらに、draft-ogud-dnsop-any-notimpに関する発表が行われました。この文
書は、DNSサーバに対する問い合わせを拒否するための手法について提案した
ものです。例えば、明らかに攻撃であり、返答を行いたくないような問い合
わせに対しては、REFUSEDやNOTIMP、もしくはRTYPE=NULLなどの返答を行うと
いう提案であり、またそのためのフィルタリング記述方法を定義しようとい
う提案です。この提案に関しては、多くの意見が出されました。その動機が
うまく述べられていないため誤用される心配があるといった指摘や、必要に
応じて既に行われているのだから標準化してしまえばいいといった意見が出
されました。引き続き議論が行われます。

他にも、

・Minimal IXFR (Incrememtal xfer)に関する発表と議論
・アプリケーションによって隠れて使われているTLDの存在の紹介
・ICANNの新gTLDプログラムの現状に関する報告
・NSEC (Next Secure)を用いたネガティブキャッシュの提案
・EDNSの正しい実装の普及具合

に関する報告等が行われました。

Minimal IXFRは、DNSSECで署名されたゾーンを転送する場合の、データ転送
量を削減するための提案です。アプリケーションによって隠れて使われてい
るTLDとして、.onionの紹介があり、さらに.mailや.home、.corpといったも
のも、実際のTLDとして使うことを避けた方がよい、という提案がなされまし
た。NSECによるネガティブキャッシュの提案は、NSECを用いることで存在し
ないとわかっている範囲の名前は、積極的にネガティブキャッシュとして保
持することで、DNSサーバへの無駄な問い合わせを減らすという提案です。特
に、RFC6761(*2)にて定義される特別なドメイン名や、今回の会合で紹介され
たような特別なTLDに関しては、取り出して集中議論する必要があるという意
見が出され、次のIETF会合までにWebEXによる中間会合が開催されることとな
りました。

(*2) RFC6761 "Special-Use Domain Names"
     https://tools.ietf.org/html/rfc6761


     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1304/7e5bd828d1d97e1f1fa14d47d30dc4bc┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1304/76978486622432b3a1cbbebecbd6867b┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
___________________________________
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
===================================
 JPNIC News & Views vol.1304 【臨時号】

 @ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 @ 問い合わせ先  jpnic-news@nic.ad.jp
===================================
___________________________________
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
___________________________________
■■■■■     News & ViewsはRSS経由でも配信しています!    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

■■◆                          @ Japan Network Information Center
■■◆                                     @  https://www.nic.ad.jp/
■■

Copyright(C), 2015 Japan Network Information Center
            

このページを評価してください

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2020 Japan Network Information Center. All Rights Reserved.