web-dev-qa-db-ja.com

CentOSのDNSルックアップが非常に遅い

なんらかの理由で、私の2台のマシンが非常に遅いDNSルックアップに悩まされ始めました。

「ホスト」コマンドの時間指定出力のサンプル:

[root@ns507403 ~]# time Host www.google.com
www.google.com has address 172.217.5.4
www.google.com has IPv6 address 2607:f8b0:4006:80d::2004

real    0m3.050s
user    0m0.000s
sys     0m0.004s

ルックアップは、使用するアドレスやルックアップの回数に関係なく、少なくとも3秒かかるようです。私が見た最高のものは、www.Paypal.comを検索するのに9秒かかりました

同じデータセンターにある他の4つのサーバーで同じDNSリゾルバーを使用しているため、DNSサーバーの速度が低下する可能性を排除しました。 (1ms未満のルックアップ)

私が成功せずにすでに試したこと:

  • /etc/resolv.confにoptions single-requestを追加する
  • /etc/resolv.confにoptions single-request-reopenを追加する
  • sysctl -w net.ipv6.conf.all.disable_ipv6=1を使用してIPv6を無効にする
  • NetworkManagerを無効にする(サーバーにインストールされていません)

これは私の現在の/etc/resolv.confファイルです:

nameserver 127.0.0.1
nameserver 213.186.33.99
search ovh.net

Digコマンドは問題なく動作し、クエリ時間0msを示しています。

これを引き起こしている可能性のあるアイデアはありますか?両方のマシンでCentOS 6を使用しています。

3

結局のところ、それはファイアウォールの問題でした。OVHには、問題の原因となっていたバグの多いWebベースのファイアウォールがあります。 OVHのスタッフは、ファイアウォールが100%正常に設定されていると言っていました。そうしないと、_213.186.33.99_を使用して解決することができないためです。これは誤りでした。ファイアウォールは明らかにOVHネットワーク内でホストされているため、この特定のIPではバイパスされます。

0

127.0.0.1は、ローカルホストのループバックインターフェイスです。つまり、独自のサーバーにアクセスしています。さまざまな理由で、サーバーは最初にDNSを検索するためにそれを使用しており、サーバーはDNSクエリに応答する方法を知らないため、クエリがタイムアウトして2番目のネームサーバーに移動するまで待つ必要があります。

実際のDNSネームサーバーを唯一のエントリとして使用します。

nameserver 213.186.33.99

ネームサーバーとして127.0.0.1を使用しているのはなぜですか?

3
Mani Gandham

ネームサーバーの順序を逆にすると、速度が向上します。

nameserver 213.186.33.99
nameserver 127.0.0.1
1
user367133

ディストリビューションはキャッシングネームサービスデーモンを使用しているため、おそらく127.0.0.1(localhost)をポイントしています。自分のコンピューターで実行されるキャッシュDNSサーバーのようなものと考えてください。このようなデーモンの使用には、議論の余地のある効果があります。

これは、インターネットに送信されるDNS要求の数を削減することにより、特定のタイプのインターネット使用を高速化する上でいくつかの利点があります。しかし、私はそれらがクラッシュして自分で燃えて、「ネットワークが遅い」というエラーが発生するのを見てきました。

私が正しく覚えている場合、CentOSはnscd(ネームサービスキャッシングデーモン)を使用してこの機能を実行します。クイック Sudo service nscd restart修正する必要があります。

または、あなたがやったことをして、いわば仲介者を切り取ることができます。その場合、キャッシュデーモンを実行したくない場合は、次のコマンドで無効にする必要があります。

Sudo service nscd stop
Sudo chkconfig nscd off
1
Rowshi

最近、オフィス全体でOPとまったく同じような症状が発生し、ルーターアプライアンス(Fortigate)の問題であることがわかりました。

問題は、ルーター構成でのネームサーバーの選択であることが判明しました。私たちの古い設定は、4.2.2.14.2.2.2の強力なLevel3サーバーを指していた。不明な理由により、これらのサーバーのパフォーマンスは非常に悪かった。

1.1.1.1(CloudFlare)と8.8.8.8(Google)に切り替えて問題を即座に修正し、全体的なブラウジング速度が劇的に向上しました。

0
leiavoia

私の場合、ルーター(ゲートウェイ)の代わりにGoogleのDNSを使用しました

交換しました192.168.1.1と追加:

nameserver 8.8.8.8
nameserver 8.8.4.4
0
Tono Nam