JPNIC Blog JPNIC

注意! 2019年2月から主要DNSサーバソフトウェアの挙動が変わります

tech_team　 JPNICからのお知らせ インターネットの技術

■ はじめに

DNSにはEDNSと呼ばれる拡張機能があります。このEDNSの実装が正しくないDNSサーバやネットワーク機器が、インターネット上に存在しています。これまで、いくつかのオープンソースのDNSサーバソフトウェアでは、EDNSの動作に不具合があるようなサーバ等に対しても名前解決ができるように、回避策が実装されていました。しかし「実装が複雑になりDNSの安定運用にも支障をきたすため、2019年2月1日以降のリリースから回避策の機能を削除することにした」というアナウンスがありました。

機能削除の予定日である2019年2月1日は “DNS flag day” と名付けられました。この記事では、その DNS flag day についてご紹介します。

■ EDNS (Extension Mechanisms for DNS)

DNSは古くから存在するシステムの一つです。元々の仕様としてDNSサーバ間の通信は、やりとりするDNSメッセージが512オクテット以下の場合はUDPを、それより大きなメッセージになる場合はTCPを用いることになっています。また、DNSメッセージ中の制御情報となるヘッダ領域は長さが固定になっており、情報を新しく追加することは無制限にはできません。

こうした元となる仕様は、設計当初のインターネットの状況を反映したものなのですが、当時はあまり問題とならず、仕様の許す範囲で徐々に機能が追加されていきました。しかし、近年になっても機能追加の要望は続き、やりとりするデータ量は増加傾向にありました。そのため、メッセージサイズの大きさ制限やヘッダ情報への追加の困難さなど、従来の制限は厳しいものとなってきていました。

そのため1999年、従来のDNSを機能拡張できるようにする目的で標準化されたものがEDNSです。そのEDNSで拡張される基本的な機能としては以下のものがあげられます。

  • DNSメッセージヘッダ: RCODEやフラグの拡張
  • DNSラベルタイプ: ラベル型の拡張
  • DNSメッセージのUDPペイロードサイズ: 最大512オクテットの制限を通信可能であれば65535オクテットまでに拡張

これらのEDNSの機能によって新たな情報が追加可能となったため、近年では “NSID” や “EDNS Client Subnet” などの、EDNSを用いた追加機能が標準化されています。

■ 実装の不備と回避処理

上記の通り、EDNSを利用することでさまざまな機能が、DNSに対して追加することができるようになりました。また、メッセージサイズの上限が増えたため、大きなメッセージでもTCPを使わずUDPだけで送信できることになり、負荷軽減や速度の向上が見込めるようにもなりました。

しかし、DNSサーバやファイアウォールをはじめとしたDNS機能を持つ各種ネットワーク機器において、正しくEDNSを処理できない機器がインターネット上に存在することが判明しています。そういった機器に対してDNSの通信を行ったとき、問い合わせや応答が不正になる場合があります。

そういった状況があったことから、各種オープンソース実装のDNSサーバソフトウェアはこれまで、通信途中で正しくないEDNSの機器を検知した場合、EDNSなしでの通信を再試行する、バッファサイズを512オクテットで再送する、TCPでの再送を行ったりするなど、名前解決ができるような回避策を実装し対応をしてきました。

■ DNS flag day

しかしながら、そのような特殊な対応は、DNSサーバの処理速度の低下を招いたり、プログラムコードのメンテナンスや新規機能の実装を困難にさせたりする要因になっています。

それを改善するため、各種オープンソース実装をしているいくつかの組織は、2019年2月1日以降にリリースされるDNSソフトウエアから、回避機能を取り除くと発表しました。その組織と主な実装は、以下の通りです。

  • Internet Systems Consortium (BIND)
  • CZ.NIC (Knot Resolver)
  • NLnet Labs (Unbound)
  • PowerDNS (PowerDNS Recursor)

これらの組織は、転機となる2019年2月1日を DNS flag day と名付け、DNSサーバ運用者やDNSソフトウェア開発者などに対して注意を呼びかけています。

■ 何が起きるか

回避策が取り除かれた後は、さまざまな現象が発生することが予想されます。その一つとして想定されるのが、正しくないEDNS実装のDNSサーバに対してEDNSを用いた通信ができなくなるため、そのDNSサーバが提供するドメイン名に対して名前解決できなくなるかもしれないということです。

つまり、自組織のDNSサーバのEDNS実装が正しくなければ、インターネット上からそのDNSサーバに対して名前解決ができなくなります。また、通信先のDNSサーバが正しくない実装であれば、自組織のサーバが正しく動作していても、相手先ドメイン名に対する名前解決ができなくなる可能性があるということです。

ただ、DNS flag day の2019年2月1日に、いきなり何かが起こるわけではありません。新しいバージョンのDNSサーバが普及していくにつれて、ある特定のドメイン名が名前解決ができないといった現象が、徐々に増えていくことになると思われます。

■ 何をすべきか

DNSサーバ管理者、DNSソフトウェア開発者、ドメイン登録者のそれぞれが、各自で確認することが推奨されます。確認サイトが公開されており、以下のURLから利用できます。

＜DNSサーバ管理者＞
管理しているDNSサーバが正しくEDNSを取り扱えるかどうか確認します。
上記の確認サイトにアクセスし、正常に動作するかどうかご確認ください。
もし不具合があった場合は、表示されるエラーメッセージを参考にご対応ください。

＜DNSソフトウエア開発者＞
ソフトウェアが正しくEDNSを取り扱えるかどうか確認します。
上記確認ツールが利用できますが、ツールのソースコードも併せて公開されていますので、ご利用をご検討ください。

＜ドメイン保持者＞
上記確認サイトにドメイン名を入力して確認してください。
ドメイン名は www.example.com 等ではなく example.com とします。

■ 最後に

DNS flag day は、2019年2月1日以降、正しくないEDNSの実装に対して特別扱いをしないような、サーバ実装のリリースが始まるというものです。この日にいきなり何かが発生するわけではありませんが、この日までにDNSサーバやネットワーク機器の動作確認をしておくことが推奨されます。

JPNICではこの問題について、明日から三重県の津市で開催される「JANOG42」ミーティングでも、ブースを出展して解説します。もしご不明点や不安な点がある方は、ぜひJPNICブースにもお立ち寄りください。

■ 参考

この記事を評価してください

この記事は役に立ちましたか？
記事の改善点等がございましたら自由にご記入ください。

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