OSSの主要DNSサーバソフトウェア、2019年2月よりEDNS実装不備環境への回避処理を削除へ 26
ストーリー by hylom
長い猶予期間 部門より
長い猶予期間 部門より
ネットワーク機器の一部では、DNSの拡張規格であるExtension mechanisms for DNS（EDNS）に対応していないものがあるそうだ。そのためDNSサーバーはEDNSに対応していない機器を検知した場合、さまざまな回避措置を行うような実装が行われているという。しかし、メンテナンスコストの増大や処理速度の低下に繋がることから、こういった実装を削除しようという動きがあるそうだ（JPNICブログ）。
具体的には、BINDやKnot Resolver、Unbound、PowerDNS Recursorといったオープンソースの主要DNSサーバーにおいて2019年2月1日よりこういった回避機能が無効化されるという。
この影響で、今後EDNSに対応していない機器では適切な名前解決が行えなくなる可能性があるとのこと。
誤解を招く (スコア:0)
>今後EDNSに対応していない機器では適切な名前解決が行えなくなる可能性があるとのこと
「対応していない機器」ではなく、「正しい応答を返さない機器」
対応済みでも中途半端な対応だとダメだし、
未対応でも、未対応という応答を正しく返していれば問題ない。
# つまり djbdns が flag day の影響は受けることはない（経路上におかしな機器があれば話は別だが）
Re:誤解を招く (スコア:2)
対応済みでも中途半端な対応だとダメだし、
それを「対応済み」と表現するのは、控えめに言って、ちょっと変わった表現だと思いますよ。
「対応していない機器」ではなく、「正しい応答を返さない機器」
そこまで細かく言うのであれば、「正しい応答を返さない機器」も正しくないだろう。
なぜなら、キミも書いた通り、djbdnsを搭載した機器が「正しい応答を返」したとしても、経路上におかしな機器があればダメなんだから。
この場合の経路上のおかしな機器は、「応答を返」す機器ではない。
Re: (スコア:0)
> なぜなら、キミも書いた通り、djbdnsを搭載した機器が「正しい応答を返」したとしても、経路上におかしな機器があればダメなんだから。
DNS は end to end なプロトコルなんだから、
「経路上」なんて言い方はおかしいですよ。
SMTPみたいなバケツリレー型のアプリケーションプロトコルとか、
IP層みたいにネットワーク層の話をしているのならともかく、
そうじゃないんだから。
Re: (スコア:0)
ネットワーク機器で、DNSを終端せず、DNSパケットを通過させるだけなのだけど、
DNSをL7レベルで認識する機器というのは割とあります。
FirewallのALG、DNSのロードバランシング、DoS緩和機器等々。(他にもあるんじゃ無いかな)
Firewallではセッション管理に、ロードバランサではレコードタイプ毎の振り分けに、
DoS緩和では、攻撃かどうかの判定の為等に、パケットをL7レベルで認識する必要があります。
その辺で、ファームが古かったり、もう新しいファームの出ないような古い機器を
使い続けてる組織なんかでは、これに引っかかるかなと思います。
Re: (スコア:0)
> FirewallのALG、DNSのロードバランシング、DoS緩和機器等々。(他にもあるんじゃ無いかな)
こういう機器はサイト内に存在するか、あるいはせいぜい直接接続している ISP にあるかぐらいじゃないでしょうか。
だとすると経路上って言い方はやはりちょっと違うんじゃ？
Re:誤解を招く (スコア:1)
だとすると経路上って言い方はやはりちょっと違うんじゃ？
私はそういう場合も「経路上」って言いますよ。
経路上にあるL7機器とか、割とよく見る表現だと思います。
少なくとも、中途半端な対応しかしないのに、「対応済み」 [srad.jp]と表現するよりは、一般的だと思います。
Re: (スコア:0)
D J B !
D J B !
# 最近どうしてるのかな
Re:誤解を招く (スコア:1)
ChaCha20-Poly1305もx25519もed25519もdjbやで
具体例が欲しい (スコア:0)
いったいどういう機種がそうなのか、わからないんだけど、
どれくらいの機種が該当しそうなんだろうか？
Re: (スコア:0)
Windows Server 2016（及びそれ以前）のDNSは警告が出ますね。
テストツール (スコア:0)
EDNS Compliance Tester
https://ednscomp.isc.org/ednscomp [isc.org]
Microsoftとかニコニコ動画のDNSってEDNSに対応してないみたいだね。
Re: (スコア:0)
> Microsoftとかニコニコ動画のDNSってEDNSに対応してないみたいだね。
#3444227 にあるけど、対応してないなら OK では？
対応してるフリしてバグってるとまずいけど。
Re:テストツール (スコア:1)
Windowsは対応してるフリっぽいですね。
RFC6891には、レスポンダは理解できないオプションを無視しないといけない、とありますが、
WindowsのDNSは未知のオプションも付けて返答してしまいます。
「AとBに対応したデータを送れ」と命じられた時に
「Aに対応したデータを返すよ！（Bはボク知らないから無視）」はOKだけど、
「AとBに対応したデータを返すよ！（実は中身はAしか対応してない）」はNGってことかな。
無知は可だが知ったかぶりは不可、
期待外れは許容できるが嘘付きは許さん、
って設計思想、とも言える？
Re: (スコア:0)
google(comとco.jp)を試してみたらなんか色々出ました
※最初に試した自分の契約プロバイダはAll OKだった
Re: (スコア:0)
機器は対応していてもファイアウォールが通さない
（大きなパケットを通さない）なんてのは大丈夫なのかしら。
結構前にAAAAレコードで問題があったような・・・もう過去の話？
え。。。と。。。 (スコア:0)
自分ところがどんだけ頑張っても
経路内で非対応引いたらアウトだよね
すっげー責任の所在がめんどくせーのですが
思い直していただけないもんですかねぇ
# IPv6 ほら僕らみたいにネット上の全部が対応完了すればいいのですよ
Re: (スコア:0)
> 経路内で非対応引いたらアウトだよね
DNSでこの書き方はおかしい。
おそらくDNSの名前問い合わせの仕組みを誤解しているのでは？
Re: (スコア:0)
自前のフルリソルバならともかく、間にプロパイダのDNSサーバーやら、ルータのDNS Proxyやら、ADサーバーが間に挟まることは良くあります。
独自ドメインでDNSサーバーを外部に委託してるとかでもちゃんとしているか確認しないと。
Re: (スコア:0)
> 自前のフルリソルバならともかく、間にプロパイダのDNSサーバーやら、ルータのDNS Proxyやら、ADサーバーが間に挟まることは良くあります。
1段 forwarder が挟まることはまああると思うけど、2段以上って、そんなにあるものだろうか。
多めに見積もって2段か3段くらい調べればいいんだから「責任の所在がめんどくせー」ってほどかしら？
だいたい同一組織か、せいぜい直接契約している ISP まででしょう？
Re: (スコア:0)
で、契約しているISPが非対応だったら、どうすればよいのでしょうかね…。
Re: (スコア:0)
契約しているISPのキャッシュサーバーの対応が不正だったら、現時点ですでに(EDNS0に対応したクライアントで)問題が生じているはず。そもそもキャッシュサーバーが不正な実装の権威サーバーへの回避処理をやめるという話なのでそういう質問が出てくる時点で理解が非常に怪しい。
# JPNICのブログが権威サーバーとキャッシュサーバーを区別していない時点で非常にアレだが
Re: (スコア:0)
ありがちとしては、プロパイダDNS->ルータDNS(FW)->IPS/ウィルスチェックGW(透過)->各種クライアント。
トラブルシュートの切り分け工数が増えるなぁ……と。
自己管理下ならともかく、出先から繋がらないとか、客がホームページ見れないとか、自己責任範囲外の機器のトラブル対応が面倒。
# 直接関係ないけど、YAMAHA RTX1200のRev.10.01.40ファームにEDNS0関連の地雷有りとかそういう。
Re: (スコア:0)
これのことかな？
知らずにアップデートしてたわ・・・
http://www.yamaha.com/products/zh/network/ja/support/download/relnote/... [yamaha.com]
DNSリカーシブサーバー機能で、EDNS0に対応したクライアントからの問い合わせにエラーを返さないバグを修正した。
Rev.10.01.40のみで発生する。
対象機種: RTX1200、RTX800
Re: (スコア:0)
ISPが二層になっててルータが挟まって組織内のが挟まってで合計4層、位はあるんじゃないかな。
組織内でDNS運用するならフルリゾルバ自前で置けよせめてルータのにぶら下げるなよって話にはなりそうだが。
Re: (スコア:0)
一年で対応できないようなら、いろいろな意味であきらめていいんじゃないかな。
ルートゾーンKSKロールオーバー (スコア:0)
きっと、ルートゾーンKSKロールオーバーと同様に頓挫する。
https://blog.nic.ad.jp/blog/ksk-roll-update-2018-05/ [nic.ad.jp]