= DNS/返答/timed_out = <> == 想像 == 返事をしないゾーンサーバーへ問い合わせた場合を除くと、以下の場合があることが分かっている。 　djbdns(tinydns)は保持しているゾーン以外には返答しない。 　any queryに返答をしないサーバー(設定)がある。 == 発端 == root zone DNSKEYの問い合せに返事が返ってこない。(timed out) 　リゾルバーの管理者は検証に失敗していることは簡単に分かるが、(最大の関心事だろうし） 　「送り出した返答が受信者に届いているか」までは気にしていないように見える。 　一方、問い合わせた側からみると、返事が返ってこない。(timed out) 　サーバー側に問題があるのか、途中の経路に問題があるのか、判断する必要もある。 (1)リゾルバー側で、問い合わせの返事を準備するのに時間がかかりすぎて、timed outになることもある。 ISC BINDだとSERVFAILを返すらしいので、timed outは別の理由かもしれない。 　つまり、一度のtimed outで判断すると誤判定もありえます。 (2)長い返答を返せないというケースは残りそうです。 (3)そもそもが問い合わせる相手が動いていないとか、問い合わせる相手を間違えているとかの可能性もあります。 == リゾルバーの動作 == https://kb.isc.org/article/AA-01219 == オープンリゾルバーなのか == これらの返事のないリゾルバーは意図して公開しているようには思えない。 1. 多くはforwarding resolver である。 2. DNSSEC検証していない。 3. 大きな返事が外部に届かなくてもこまらない。 　 == 検証に失敗するとなにが起きるか == DNSSEC検証しているがroot zone DNSKEYのような大きな返答は受け取れないリゾルバーはどう動作するか。 dnssec-failed.orgのDNSSEC検証には成功しているらしい。 DNSSECに対応していないのであれば、返事は異なるのではないか。 DNSSEC非対応のドメインのデータは返答する。(qmail.jp A など） == root zone 新zskへの更新に失敗している可能性 == 　いずれ(2日後?)はDNSSEC検証できなくなるはず。 検証できるのであれば、なにか別の情報を利用しているのか。 「信頼の連鎖」を重視するなら、すべてで検証不良になっておかしくない。 　　JP下のDNSSEC情報が引けたりする。 == 別の可能性 == リゾルバー自身はKSK/ZSKの更新はできていて、検証可能になっているが、 返答を送り出したあとの経路のどこかでフラグメントが棄てられているという可能性を考えました。 これなら、長い返答はもらえないでtimed outになるが、短い(検証つき）返答はもらえる。 JPRSなどの言っているテストでは不十分ということにもなる。 こういう状況があるとしたら、DNSSEC検証の有効無効に関係なく発生していてもおかしくないので、 長大な返答を返すような問い合わせを見つけて、問い合わせてみることにします。 返答のサイズはroot zoneだと1414, jp だと893　octetなので、timed out するサーバは同じかも。 　測定に適当なサイズをいくつか選ぶと、判定に使えそうです。 == 返答の大きさの影響 == [[/返答の大きさ]] -- ToshinoriMaeno <>