1. DNS/EDNS
DNS/1/EDNS /dnsops2020 /heteml
/UDPsizeMinimal EDNS compliance requirements https://tools.ietf.org/id/draft-spacek-edns-camel-diet-01.html Expires: November 30, 2018
DNS responders must either follow RFC 6891 by fully implementing EDNS or at least respond to queries containing OPT record according to older specifications.
Non-compliant implementations which do not respond at all are not worth talking to.
1.1. DNS flag day
EDNS Compliance Tester 2020: https://ednscomp.isc.org/ednscomp/5c933251a4
本当に問題(名前解決不能)が発生するのか。 /JPRS速報 は伝聞/意訳にすぎず、間違いもある。
/dnsflagday.net を見直す
1.2. workaroundsがなにを指すのか
- EDNS opt付きのqueryをしても正しい返事が得られなかったときに、EDNSなしのqueryを送り直す動作を指す。
1.3. 正しい返答が得られない
EDNSに対応していなくて、返答をしないサーバーが存在するのだろうか。(そうは思えない。)
- そして、EDNSなしには対応していて、これなら正しい返事が返せるというのだろうか。(ありそうもないから、 DNS flag dayを宣言したのだろう。)
EDNSに対する返答が正しく伝わらない経路という状況はあるかもしれない。(KSK ロールオーバーキャンペーンと同根)
- それなら、ENDSなしqueryの返答が正しく返るとはいえない。おそらくはTC onの返答が返るのだろう。
なぜ、TCPでの問合せ直しをしないのか。(しているのかも)
「EDNSが正しく動作しているか、確認せよ」と言うだけ。素人を不安にさせるキャンペーンだ。
1.4. noedns
Knot Resolverはもともとnoednsで問合せ直し(work around)は実装していないようだ。(1.1.1.1 を試して)
ednsに返事をしないサーバをJP下で探してみた。見つからない。(どこかにはあるのかも) /netsjapan.jp /pman-hasaki.jp
+noedns には返事をする。 /joppari.co.jp /aaasystem.co.jp /cyberlab.jp /fujiiopt.jp
1.5. packet 長 (経路)
長いパケットがやりとりできない経路が存在するかもしれない。
- あっても不思議ではないが、DNSの問題なのだろうか。
root zone key ロールオーバー騒ぎで洗い出されたのではないか。
-- ToshinoriMaeno 2018-07-23 00:22:13
フラグメントすり替え攻撃(毒盛)の方が怖い。-- ToshinoriMaeno 2018-11-23 23:18:47
Let's Encrypt の対応をみよ。https://twitter.com/beyondDNS/status/1065418868049342464
https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945
As of November 15th, 2018 our DNS resolvers (both staging and production) advertise an EDNS reassembly buffer size of 512 bytes.
1.6. TCP 対応
JP登録されているサーバのうち、21000台あまりを調査したら、2000台ほどがTCPには返事をしなかった。
- うちUDPに返事をするものは1000台程度だ。これらがTCPに対応していないホストだということになる。