web-dev-qa-db-ja.com

この余分な50ミリ秒の遅延は、バインドされていないDNS解決サーバー（Fedora）でどのようになりますか？

クエリのレイテンシに不一致があります。それは問題ではありません、それは私を心配するのに十分奇妙です。

  • クライアントマシン（Fedora 18）はunbound-1.4.19-1.fc18.x86_64を実行します。
  • サーバーマシン（Debian 7テスト）はバインドされていない1.4.17-2を実行します。

どちらも同じホームルーターに接続されています。ただし、サーバーはキャッシュされていないクエリをほぼ2倍の速度で解決できます。これは私が期待したものではありませんでした！サーバーは1Ghz ARM（sheevaplug））であり、クライアントマシンは2.1Ghz Intel CoreDuoです。

どちらのインスタンスもDNSSECを検証します。 www.dnssec-failed.orgに対してSERVFAILを返します。どちらも、ISPからの同じアップストリームDNSキャッシュを使用するように構成されています。

これまで考えられるのは、NATに関する問題だけです。ルーターはサーバーで「デフォルトDMZ」として構成されています。つまり、他の誰も要求していないパケットを取得します。これが、SSHやbittorrentなどの公共サービスを実行する方法です:)。または...マイナーバージョン-19は、何らかの方法でマイナーバージョン-17よりも厳密に検証されている可能性がありますか？

テスト方法：.deの存在しない10個のサブドメインの解決。 （ISPキャッシュミスを引き起こすはずです）。 .de。 TLDは、yahooにクエリを実行することでプリロードされます。

クライアント側から

$ for i in 1 2 3 4 5 6 7 8 9; do Sudo unbound-control reload; (Dig yahoo.de.; Dig Twitter$i.de.) | grep Query; done

Result - mean 120ms, stddev 60ms

サーバー側から

$ for i in 1 2 3 4 5 6 7 8 9; do Sudo unbound-control reload; (Dig yahoo.de.; Dig aldi$i.de. ) | grep Query; done

Result - mean 70ms, stddev 50ms

私は知っている、テストは見栄えが良くなく、私の統計は圧倒的な証拠ではないかもしれない。しかし、私はそれをさらに数回試しました、そしてそれは何の違いも見ていません。

domain-name-systemfedoralatencydnssecunbound
1
sourcejedi

ああ！ 2台のコンピューター間でunbound.confを比較しました。 Fedoraは以下のオプションをオンにしているようです。これをオフにすると、Fedoraマシンの追加のレイテンシーがなくなります。

    # Harden the referral path by performing additional queries for
    # infrastructure data.  Validates the replies (if possible).
    # Default off, because the lookups burden the server.  Experimental
    # implementation of draft-wijngaards-dnsext-resolver-side-mitigation.
    harden-referral-path: yes

これを調べて、使用するかどうかを決定する必要があります:)。

リンク： https://datatracker.ietf.org/doc/draft-wijngaards-dnsext-resolver-side-mitigation/

3
sourcejedi