105)がカナダのモントリオールで開催されました。JPRS編集局が注目した以下の話題をお伝えします。104以降に発行された、DNS関連のRFCの内容は以下の通りです。6944を置き換えます[*1]。MUST(必須)としています。装しない正当な理由があれば実装しなくても構わないものです)。デフォルトアルゴリズムになることが予想されるとしています。議報告をご参照ください。デジタル署名に使われる、代表的なハッシュ関数の一つ。RSA暗号に比べ、より短い鍵長で同等の安全性を提供可能な暗号方式。設計されたデジタル署名方式。Operationsに由来しており、DNSサーバーや登録情報の管理など、DNSの運用全般に関するガイドラインの作成を目的としています。用上の課題に着目したDNSプロトコルの拡張・メンテナンスも活動項目としています。(draft-fujiwara-dnsop-avoid-fragmentation)JPRSの藤原和典が著者として作成している提案で、DNSにおけるIPフラグメンテーション(断片化)[*5]を回避するものです。IPフラグメンテーションの詳細は、JPRS用語辞典をご参照ください。https://jprs.jp/glossary/index.php?ID=0180現在、DNSではUDPで大きなサイズの応答を返信できるようEDNS0を使用しており、大きなサイズを扱うがゆえにIPフラグメンテーションが起きやすくなっています。撃手法が提示されています。提案では、DNSでのIPフラグメンテーションを回避する対策として、フルリゾルバー(キャッシュDNSサーバー)のEDNS0リクエスターのUDPペイロードサイズを1220に、権威DNSサーバーのEDNS0レスポンダーの最大ペイロードサイズを1220に指定することとしています。認されるTCPによって再試行することになります。TCビットの詳細は、JPRS用語辞典をご参照ください。論されていく予定です。(draft-ietf-dnsop-multi-provider-dnssec)複数のDNSプロバイダーのサービスを用いる環境で、DNSSECを展開する際に生じる課題に対して、適切な展開モデルを紹介する提案です。止してしまう可能性があります。そのため、多くの企業が複数のDNSプロバイダーのサービスを採用しています。複数のDNSプロバイダーを用いる際は、標準ゾーン転送をサポートしない、互換性がなく標準化されていないDNS機能が使用されるといったような課題がある状況です。提案では、標準ゾーン転送をサポートしない複数のDNSプロバイダーを使用する際のDNSSEC鍵管理方法として、DNSプロバイダーがサポートすべき管理APIの要件を、二つの署名方法のモデルと共に定義しています。能な、DNSクッキー[*7]の作成方法を定義するための提案です。ドメイン名関連会議報告をご参照ください。7873のAppendixで定義されている、クライアント/サーバークッキーアルゴリズムの例が変更されました。Sub-Fieldの利用方法が明確化されました。Secretのアップデート方法に言及されています。提案にはBINDやNSDの実装者が参加しており、標準化が進むことが見込まれています。8499[*8]に、用語を追加する提案です。DNS」と定義しています。RRが提案されました。RR[*9]が不要となる可能性がある一方、HTTPSSVCが非常に大きなRRになる可能性や、ブラウザーでの実装が進みにくいなどの課題認識が共有されました。Exchangeに由来しており、DNSトランザクションにおける機密性(confidentiality)の提供を目的としています。1として完了しています。2として、フルリゾルバーと権威DNSサーバー間の通信の暗号化を検討しており、そのための要求条件と実装案の議論が行われています。(draft-hzpa-dprive-xfr-over-tls)DoTは、本来スタブリゾルバーとフルリゾルバー間の通信におけるプライバシー確保のためのプロトコルです。本提案は、ゾーン転送もTLS上とすることで、権威DNSサーバー間の通信におけるプライバシーを確保するものです。1.9.2には、既にTCPの代わりにAXFR-over-TLSを実行するオプションが含まれるなど、小さな拡張であるため検討と実装が進むことが期待されます。従来のTCPによるゾーン転送がTCPセッションは一つのゾーン転送にのみ使用する必要があることと同様に、TCP/TLS接続でも一つのゾーンのみという制約によるパフォーマンスの課題があります。そのため、ゾーン同期機構そのものを改善した提案もありました(draft-zatda-dprive-xfr-using-dso)。8484として標準化されましたが、その運用・利用についてはまだ議論が不十分な状態であり、さまざまな懸念が指摘されています。Meeting[*10]で行われた議論を継続するものです。過去のドメイン名関連会議報告をご参照ください。BoFが開催されました。DNS)のアプリケーションでの使いわけや設定などの議論が行われました。ポリシーにかかわる問題でありさまざまな意見が出されましたが、個人のプライバシーを守る立場は共通していました。DoHはアプリケーションごとに設定が異なる問題点や、適切なサーバー情報を得る方法など議論することが多いため、WGの設置を求める声が多く挙がりました。WGで扱うべきであるなど意見が多数出て結局集約されるには至らず、エリアディレクター(AD)間で方向性を議論することになりました。Group)は、IETF会合に先立って開催される会合で、インターネットの運用に関連するさまざまなテーマを取り扱っています。discoveryへの攻撃が複数のOSで可能であることを紹介しました。keyを用いるTSIG方式の提案がありました。Transparency)[*11]と同様の仕組みの提案がありました。サーバー証明書におけるCTの詳細は、JPRS用語辞典をご参照ください。https://jprs.jp/glossary/index.php?ID=0235DNSのデータ更新をする際に監視システムにもデータを送り、そこを監視することで、意図せぬデータの変更が入ることを見つけ出す提案です[*12]。時は、アラートやセキュリティプロバイダーへの報告により対策が取られることが想定されています。同じ提案が行われています。https://65.schedule.icann.org/meetings/1058207ドメイン名のレジストリが監視システムへ情報を送る必要がある点は、サーバー証明書におけるCTと同様であり、一元的に対応が可能となるもののレジストリがサポートすることが必要となります。106)は2019年11月16日から22日にかけ、シンガポールで開催されます。■会議報告:https://jprs.jp/related-info/event/■配信先メールアドレスなどの変更:https://jprs.jp/mail/henkou.html■バックナンバー:https://jprs.jp/mail/backnumber/■ご意見・ご要望:from@jprs.jp当メールマガジンは、Windowsをお使いの方はMSゴシック、macOSをお使いの方はOsaka等幅などの「等幅フォント」で最適にご覧いただけます。当メールマガジンの全文または一部の文章をWebサイト、メーリングリスト、ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。当メールマガジンには第三者のサイトへのリンクが含まれていますが、リンク先のサイトの内容などについては、JPRSの責任の範囲外であることにご注意ください。その他、ご利用に当たっての注意事項は読者登録規約にてご確認ください。認証方法についてサイトシールについて設定マニュアル対応環境についてルート証明書・中間CA証明書についてサーバー証明書発行サービスに関するリポジトリ/利用規約サーバー証明書発行サービスについてのお知らせ株式会社日本レジストリサービス(JPRS)は、ドメイン名の登録管理と、ドメインネームシステム(DNS)の運用を通して、インターネットの基盤を24時間×365日支えています。