☰

bind9: インターネット接続がダウンしていると、ローカルネームサーバーへの転送が機能しない

tag-icon • tag-icon domain-name-system bind dns-zone forwarding
bind9: インターネット接続がダウンしていると、ローカルネームサーバーへの転送が機能しない

次のような設定になっています:

ローカル ネットワーク上の名前を解決するための、非常に限られたハードウェア上の bind9 インスタンス (以下、L と表記)。これは、ゾーン home.mydomain.com の権威マスターです。このサーバーへのクエリは機能し、NS として homedns.home.mydomian.com が返され、その IP 192.168.1.77 が追加レコードとして返されます。

インターネット名とローカル名を解決するための bind9 インスタンス (以下、M と呼びます)。ここではグローバル転送オプションは使用されません。転送ゾーンが構成されています。

zone "home.mydomain.com" in {
        type forward;
        forward only;
        forwarders { 192.168.1.77; };
};

注1: ​​mydomain.com は既存の登録済みドメインですが、home.mydomain.com の記録はありません。

注2: Mのbind9バージョンは非常に古いです: 9.8.1-P1

この設定はインターネット接続が確立されている限り機能しますが、接続がダウンしている場合はローカル名クエリは応答されません。ログはsyslogです。

Aug 30 09:05:42 M named[1611]: error (no valid DS) resolving 'xxx.home.mydomain.com/A/IN': 192.168.1.77#53

接続が確立しているときに解決が成功したかどうかのネットワークをキャプチャすると、M が L からの応答を受け取った後にインターネット上で mydomain.com を照会していることがわかります。M からクライアントへの応答では、AUTHORITY SECTION が変更されています。

Lに掘る：

;; ANSWER SECTION:
syslog.home.mydomain.com. 3600  IN      A       192.168.1.99

;; AUTHORITY SECTION:
home.mydomain.com.        3600  IN      NS      homedns.home.mydomain.com.

;; ADDITIONAL SECTION:
homedns.home.mydomain.com. 3600 IN      A       192.168.1.77

Mに掘る：

;; ANSWER SECTION:
syslog.home.mydomain.com. 2134  IN      A       192.168.1.99

;; AUTHORITY SECTION:
net.                    171334  IN      NS      j.gtld-servers.net.
net.                    171334  IN      NS      m.gtld-servers.net.
net.                    171334  IN      NS      i.gtld-servers.net.
net.                    171334  IN      NS      k.gtld-servers.net.
net.                    171334  IN      NS      g.gtld-servers.net.
net.                    171334  IN      NS      e.gtld-servers.net.
net.                    171334  IN      NS      h.gtld-servers.net.
net.                    171334  IN      NS      a.gtld-servers.net.
net.                    171334  IN      NS      d.gtld-servers.net.
net.                    171334  IN      NS      f.gtld-servers.net.
net.                    171334  IN      NS      b.gtld-servers.net.
net.                    171334  IN      NS      c.gtld-servers.net.
net.                    171334  IN      NS      l.gtld-servers.net.

M が L からの応答をクライアントに返さない理由がわかりません。また、転送されたゾーンのインターネットへのクエリを回避するために何を試みればよいかについても、アイデアがありません。

答え1

質問で引用されているログ エントリは、インターネット接続がない場合に DNSSEC 検証が失敗したことにエラーが関連していることを示唆しています。

エラー メッセージの「有効な DS がありません」の部分に注意してください。

Aug 30 09:05:42 M named[1611]: error (no valid DS) resolving 'xxx.home.example.com/A/IN': 192.168.1.77#53

おそらく、この転送ゾーンにヒットするクエリに対する回答は、パブリックexample.comゾーンが署名されていないゾーンとして存在する (つまり、DS適切なゾーンの委任の一部として「いいえ」の証明があるexample.com) という理由だけで通常は受け入れられますが、インターネット接続がないためにこの証明を取得できなくなると、署名する必要があるかどうか、また署名方法を確認できなくなるため、回答は受け入れられなくなります。

1つの選択肢は、ゾーンに署名してhome.example.com静的な信頼のアンカー特にこのゾーン向けです。

もう一つは、検証を選択的に無効にすることです。現在のBINDにはvalidate-except次のように、検証を実行しないドメイン名のリストを指定できるオプション。

validate-except

これは、それらの名前またはその上位にトラスト アンカーが存在するかどうかに関係なく、DNSSEC 検証を実行しないドメイン名のリストを指定します。これは、たとえば、ローカル使用のみを目的としたトップレベル ドメインを構成するときに使用できます。これにより、ルート ゾーンにそのドメインの安全な委任がなくても検証が失敗することはありません。(これは、ネガティブ トラスト アンカーの設定に似ていますが、ネガティブ トラスト アンカーは期限切れになり、一定期間後に削除されるのに対し、ネガティブ トラスト アンカーは永続的な構成であるという点が異なります。)

また、検証を完全に無効にすることもできます。dnssec-validationオプションですが、この BIND インスタンスがこの特定の転送よりも広く使用される場合には、お勧めしません。

(注: 質問で使用されているドメイン名は に置き換えました。example.com質問が参照しているドメイン名やそれを所有する企業と何らかの関係がある可能性は低いためです。)

関連情報