web-dev-qa-db-ja.com

解決可能な名前のSSHクライアントの名前解決が失敗する

いくつかの別個のDMZ内のサーバーにアクセスするために使用されるLinuxボックス（jumperと呼ばれます）があります。各DMZには独自のサブドメイン名があります（例：idmz.example.org、jdmz.example.org）、そして各サブドメインには独自の権威ネームサーバーがあります。

古いSolarisジャンパーを新しいLinuxボックスに交換しているところです。ほとんどのことはうまくいきましたが、サブドメイン内のサーバーへの接続に問題がありますidmz.example.com SSHを使用します。 pingは正常に機能します。 Digを使用して名前を解決できますが、SSHは「解決できませんでした」と言います。

名前解決はサーバー側でうまく機能し、IPアドレスを使用して接続するときに遅延やタイムアウトは発生しません。しかし、クライアント側のSSHはサーバーを解決できないと主張しています。

Pingおよび失敗したSSH接続：

jenny@jumper$  ping server.idmz.example.com
PING server.idmz.example.com (192.168.1.3) 56(84) bytes of data.

jenny@jumper$  ssh -v server.idmz.example.com
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
ssh: Could not resolve hostname server.idmz.example.com: Name or service not known

ホスト名の代わりにIPを使用したSSH接続の成功：

jenny@jumper$  ssh 192.168.1.3
[email protected]'s password:

クライアント側から見ることができる1つの違いは、idmzのネームサーバーから信頼できる回答を得ることはできませんが、他のすべてからは得ますDMZ =ドメイン。

linuxdomain-name-systemssh
11
Jenny D

DNSサーバーのシステム管理者に連絡し、idmzの設定を確認するよう依頼しました。彼らのネームサーバーはIPV6を処理すると主張していることが判明しましたが、IPV6クエリに対して正しい答えを提供しませんでした。

Solarisサーバーでは、デフォルトでIPV4が使用されていました。新しいLinuxサーバーでは、SSHは最初にIPV6を試しました。この場合、IPV6を使用してサーバー名を解決できなかったため、解決できないと判断しました。他のdmzドメインでは、IPV6を使用している場合でもネームサーバーが正しい応答を返しました。

SSHの構成を変更して、

AddressFamily inet

そして問題は消えました。

17
Jenny D