web-dev-qa-db-ja.com

間違ったローカルDNSの結果がどこから来ているのかをどのように把握できますか？

私はミントメイト17.2を実行しています。

Digを使用すると、特定のドメイン名に対して、解決されたIP「answer」が間違っており、応答サーバーは127.0.0.1。

ローカルコンピューターからssh、Webブラウザーなどを介してこのドメインにアクセスしようとすると、間違ったIPに解決されます。

オンラインツールまたは他のコンピューターを使用したDNSルックアップは正しく機能します。

ローカルマシン上の何かがリクエストをインターセプトし、間違ったキャッシュ結果を返しています。さまざまなキャッシュプログラムを見てきましたが、インストールまたは構成されていないと思います。

返されるIPアドレスは古いIPであり、マスターDNSレコードは1年以上前に変更されました。

どのプログラムがローカルでDNSを傍受しているかを判断し、それを無効にして、コンピューターでこのドメインを正しく解決できるようにするにはどうすればよいですか？

/ etc/resolv.conf：

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
debiannetworkingdnsdig
4
Nick

Resolvconfは、ローカルマシンのポート53で実行されているローカルソフトウェアを指し示しています。

どれを見つけるには：

Sudo netstat -anlp | grep :53

私たちが知っているように、それはavahiデーモンです。

DNS解決を追跡するには、次のコマンドも役立ちます。

Dig +trace www.cnn.com

DNS設定を自分で制御したい場合、特にサーバーの場合（Mintと言ったことに気づきました）、resolvconfを廃止することをお勧めします

次の方法でアンインストールできます。

dpkg --purge resolvconf

次に、DHCP経由でIPを取得した場合は、そのままにしておきます。それ以外の場合は、/ etc /resolv.confにDNSサーバーを入力します。

MDNS解決や企業ネットワークにも興味がない場合は、avahiをアンインストールすることをお勧めします。

デスクトップ設定では、すべてのサービスを再起動または再起動することをお勧めします。少なくともservice networking restartでネットワークを再開します。

Avahi mDNS/DNS-SDデーモンは、AppleのZeroconfアーキテクチャ（「Rendezvous」または「Bonjour」とも呼ばれます）を実装しています。デーモンは、mDNS/DNS-SDを使用してローカルIPアドレスと静的サービスを登録し、avahi-daemonが維持するmDNSレコードキャッシュを利用するためにローカルプログラムに2つのIPC APIを提供します。

作業環境では、mDNSレコードをアナウンスしているネットワークレベルのサーバー/ワークステーションで、それらが厳密に必要かどうかをフォローアップすることも興味深いかもしれません。失われたホストファイルまたは古いサーバー設定がmDNSを介して古いIPアドレスを伝播しているに違いありません。

ローカルネットワークのmDNSパケットを次のようにリッスンすることもできます。

Sudo tcpdump -n udp port 5353

から mDNS

マルチキャストドメインネームシステム（mDNS）は、ホスト名をローカルネームサーバーを含まない小規模ネットワーク内のIPアドレスに解決します。これはゼロ構成サービスであり、ユニキャストドメインネームシステム（DNS）と本質的に同じプログラミングインターフェイス、パケット形式、および操作セマンティクスを使用します。 Stuart CheshireはmDNSをスタンドアロン対応として設計しましたが、ユニキャストDNSサーバーと連携して動作できます。

4
Rui F Ribeiro