メインコンテンツへスキップ

トップページ > JPNICライブラリ > ニュースレター > バックナンバーオンライン版 > No.47


現在、マイクロソフト セキュリティ情報 MS10-090のパッチを適用したInternet Explorer 8をお使いの方は、 JPNIC Webサイトの内容が印刷できない状態になっています。 印刷をする場合には、 Internet Explorer 8以外のブラウザを利用してください。
この不具合の詳細と、その対処方法については、 マイクロソフトのWebサイトに掲載されている以下の技術情報をご覧いただくか、 マイクロソフトのサポートセンターにお問い合わせください。
 マイクロソフトの技術情報

ニュースレターNo.47/2011年3月発行

DNS関連WG報告

本稿では、DNSに関連した内容を議論するワーキンググループ(WG)で議論された概要をご紹介します。

dnsext WG(DNS Extensions WG)

dnsext WGでは、会合のまず初めに、dnsext WGのメーリングリスト(ML)が、今までのnamedroppers@ops.ietf.orgからdnsext@ietf.orgへと変更になるとアナウンスがありました。現在登録されている人はそのまま新しいMLに引き継がれます。

今回の会合での主な議題は、draft-yao-dnsext-identicalresolutionとdraft-vixie-dnsext-resimproveでした。どちらもWGdraftではありませんが、前者はIETF77から話題になっている、Zone Aliasingに関するドラフトです。後者は、上位ゾーンと下位ゾーンのNSセットが同期していない場合の、リゾルバサーバの挙動に関する改善を提案しています。

前者のdraft-yao-dnsext-identical-resolutionは、Zone Aliasingに関しての目的と提案されている方式、問題点をまとめたドラフトです。Zone Aliasingの方式として、BNAMEとCNAME+DNAMEという二つの提案が出ていましたが、IETF78の後、特に進展はありませんでした。そのため、期限を区切って本ドラフトを更新することが提案され、Suzanne Woolf氏を中心として作業が行われることとなりました。

後者のdraft-vixie-dnsext-resimproveに関しては、NSRRのTTLに応じて、ゾーンの委譲を再検証し、検証においてNXDOMAINが返ってきた場合には、そのゾーンに関してそれ以降の検索を止める、という提案です。リゾルバDNSサーバの挙動を変えるものであるため、いくつか否定的な意見が出ました。発表の後、WGdraftにするかの挙手による意思確認が行われましたが、ほとんど手は上がらず、議論はMLに引き継がれました。

その他には、DNSのリソースレコードとしてURI RRを追加する提案である、draft-faltstrom-uriや、AAAAレコードとAレコードを同時に問い合わせる手法を提案した、draft-kitamura-ipv6-simpledns-queryに関する発表がありました。最後に、DNSSEC History Projectに関する発表がありました。この発表はdnsop WGでも行われたため、以下のdnsop WG報告にて説明します。

dnsop WG(Domain Name System Operations WG)

dnsop WGの会合では、まずWG draftの確認がありました。draftietf-dnsop-name-server-management-reqsがIETF Last Callを通過したため、Informational RFCとして発行される予定であることが報告されました。また、draft-ietf-dnsop-default-local-zones、draft-ietfdnsop-as112-ops、draft-ietf-dnsop-as112-under-attack-help-helpの三つのdraftは、早めにAD(Area Director)レビューに回すことが確認されました。また、draft-ietf-dnsop-resolver-primingならびにdraftietf-dnsop-respsizeはExpireしているのですが、著者が更新に向けて作業をしているとの報告がありました。

次に、DNSSEC History Projectに関する発表がありました。これはDNSSECが実運用段階に入ったこと、ならびにDNSSEC提案から20周年であることを記念して、DNSSEC標準化と実運用までの記録を残すというプロジェクトです。https://wiki.tools.isoc.org/DNSSEC_History_Projectに情報が集められています。

他には、draft-ietf-dnsop-dnssec-key-timingに関する報告がありました。現状では、Algorithm RolloverやCSK Rolloverといった項目に関して述べていないが、これらを盛り込んでからWG Last Callを行うべきか、これらの追加の項目に関しては別ドラフトとして発行すべきか、という議論がなされました。結論としては、別ドラフトとして執筆し、現状のドラフトはWG LastCallに向けて更新を行うことが確認されました。

WG draft以外では、draft-livingood-dns-whitelistingimplicationsに関する発表がありました。これは、DNSクエリの送信元IPアドレスによって、応答にAAAAを返すかどうかを決定するという仕組みです。これによって、IPv6接続性が無い組織のDNSサーバからDNS問い合わせが来た場合に、不要なAAAAを返さないことによって、IPv6接続タイムアウトの発生を回避することができるという提案です。これに関しては、いくつかの質問とコメントが出されましたが、dnsop WGとしては好ましくない手法であるとの意見が大勢を占めました。

最後に、Name Server Control Protocolに関する議論が行われました。これは、DNSサーバを制御するための共通のプロトコルを定めようという試みです。Nameserver Management Requirementsに関するドラフトがIETF Last Callを通過したため、次にそのプロトコルに関して定義しようというものです。具体的には、draft-kong-dns-conf-auto-sync、draft-dickinsondnsop-nameserver-controlといったドラフトが提案されています。主にNETCONFの枠組みを利用して、DNSサーバの設定や制御を行うという提案です。会場での活発な議論が行われ、引き続きMLで議論を行うことが確認されました。

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


参考:第78回IETF報告[第2弾]DNS関連WG報告
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2010/vol774.html


このページを評価してください
このWebページは役に立ちましたか?
役に立った。
役に立たなかった。
どちらとも言えない。

ページの改良点等がございましたら自由にご記入ください。
  • このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、 お問い合わせ先 をご利用ください。
  • 文中でのHTMLタグ使用はご遠慮ください。
ページトップへ