Meetingにおける話題についてお伝えします。Serviceに由来しており、現在のWHOISを置き換えるプロトコルであるRDAP(*1)の開発、各RDAP実装の相互接続性の確認などを目的としています。BOFにおける話題から~」をご参照ください。Pathの仕様(draft-ietf-appsawg-uri-get-off-my-lawn)に準拠していないという指摘があり、問題を解決するための議論が進められました。Group」に由来しており、アプリケーションエリア全般の話題を総合的に取り扱うWGです。Pathの仕様に準拠した形に更新する方向で検討を進めることとなりました。この方針に従い、会議終了後にdraft-ietf-weirds-rdap-queryが07から08に更新されています。Consortiumの略称。Webで利用される一連の技術の標準化を進めることを目的として、1994年に設立された非営利団体です。Matching)と正規化(Normalization)の仕様について議論されました(draft-hollenbeck-weirds-rdap-search)。会場からは、検索の仕様についてはもっと詳細に文書化した方が良い、レジストリごとに異体字(variant)の仕様やポリシーが存在する、といったコメントがあり、今後も継続して検討を進めることになりました。87から継続して議論されている問い合わせ名からRDAPサーバーへの到達方法について、これまでに提案された二つの方式(*4)、1)DNSによる検索(draft-blanchet-weirds-bootstrap)2)IANAレジストリ方式(draft-blanchet-weirds-bootstrap-ianaregistries)に加え、SRVまたはNAPTRレコードを用いることでIANAへの登録を不要とする新たな方式(draft-blanchet-weirds-bootstrap-autonomous)が提案されました。Meeting報告(後編)~DNSの運用とセキュリティにつながる話題、レジストリ関連WGにおける話題~」をご参照ください。WGで進めている相互接続試験の状況が報告されました。89でも試験を再度実施し、相互接続性の改良を進めていくことが確認されました。BOF」というセッションが開催されました。session」と同様、インターネットガバナンスに関する状況をIETF参加者と共有・議論することを目的としています。IETF及びIESGによる標準化プロセスを監督し、RFCの発行・IANAの資源割り当てについて責任を負います。IETF議長及びIESGエリアディレクターの承認、ISOCへの技術的アドバイスなど、インターネット全体にかかわる重要な役割を担っています。今回のセッションでは、次世代WHOISに関する話題が取り上げられました。WGの活動状況が紹介されました。その後、IGF(*6)における検討状況が共有され、マルチステークホルダーモデルの中でIETFがどのような役割を果たしていくべきかについて、参加者の間で議論されました。関連する議論は今後、Internetgovtechメーリングリスト(関連URIを参照)において継続される予定となっています。インターネットガバナンスについて話し合う、国際連合が管轄するフォーラムです。Society(世界情報社会サミット:WSIS)」で採択された「チュニスアジェンダ」により開催が決定され、2006年から年に1回の割合で開催されています。Meetingに先立って日曜日午前に開催される略式の会合で、インターネットの運用に関連するさまざまなテーマを取り扱っています。JPRSが特に注目したものについてお伝えします。Huston)氏から発表されました。DNSと他のキャッシュDNSサーバーを併用しているものが全体の1.9%であったことが報告されました。DNSと他のキャッシュDNSサーバーを併用しているものは、逆に全体の2%台に増加という変化があったことが報告されました。DNSの国別の利用率と、スノーデン事件以降のその変化の状況も併せて報告されました。Wijngaards)氏から発表されました。(*7)draft-wkumari-dnsop-hammer。関連WGにおける話題~」をご参照ください。HAMMERからの変更点は、1)プリフェッチ実行の条件HAMMER:クライアントからDNS問い合わせを受けた時点で、そのレコードのキャッシュTTLが2秒以下に減少していた場合Unbound:クライアントからDNS問い合わせを受けた時点で、そのレコードのキャッシュTTLがオリジナルTTLの10%以下に減少していた場合2)プリフェッチ実行の除外条件HAMMER:オリジナルTTLが6秒以下であった場合Unbound:オリジナルTTLが9秒以下であった場合の2点とのことで、同氏はその理由として、権威DNSサーバーやUnbound自身の負荷上昇の防止を挙げています。Time」)が短いものが増加したことが発表されました。name)」と定義したこと、プリフェッチは本来のターゲットである「人気のある名前」に加え、「人気はないが大きなTTLが設定されている名前」に対しても有効であると考えられることが示されました。Vixie)氏から発表されました。RRLにおけるslip(*8)の設定変更(*9)、ANYレコードに対する対策の三つについて、コストの面から検討した結果が示されました。RRLでは応答制限時にも名前解決ができるように、制限発動時の応答の一部について、slipと呼ばれる動作をします。slipでは応答を廃棄する代わりに切り詰め(TC)ビットをセットされた応答を返すことで、送信元にTCPによる再送を促します。RRLの悪用によりキャッシュポイズニング攻撃のリスクが高まることが指摘され、その対策としてslipの設定変更(応答制限時にすべての応答をslipとする)が提案されました(関連URIを参照)。RRL)がある点が示され、セキュリティは経済(economics)であり、過去から現在、未来になるに従い、徐々に高コストとなっていくと結論づけられました。(*10)サーバーからのDNS応答にHTTPと同様の「クッキー」を加え、以降のDNS問い合わせ(セッション)においてそれを利用することにより、DNS応答の偽造を防止する提案です(draft-eastlake-dnsext-cookies)。89)は2014年3月2日から7日にかけ、英国のロンドンで開催される予定です。Limitinghttp://www.certa.ssi.gouv.fr/site/CERTA-2013-AVI-506/index.html(フランスCERTAの発表。JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。認証方法についてサイトシールについて設定マニュアル対応環境についてルート証明書・中間CA証明書について失効申請における失効理由コードの指定についてサーバー証明書発行サービスに関するリポジトリ/利用規約サーバー証明書情報等の外国組織への提供ご利用にあたっての注意事項サーバー証明書発行サービスについてのお知らせメンテナンス情報サーバー証明書の更新のご案内について株式会社日本レジストリサービス(JPRS)は、ドメイン名の登録管理と、ドメインネームシステム(DNS)の運用を通して、インターネットの基盤を24時間×365日支えています。