BIND9 委譲NSレコードの名前解決について

質問

BIND9に "recursion yes:" の設定を行い、委譲しているレコードへの
名前解決(コマンド：dig @localhost 委譲NS ns )したところ、"SERVFAIL"が表示され
正常に名前解決ができませんでした。

/var/log/messageには以下のエラーが吐かれてました。
FORMERR resolving・・・

基本的な設定は以下となってます。(抜粋)

・named.conf
view "internal-net" {
match-clients { 127.0.0.1/32; };
recursion yes;
};

view "external" {
recursion no;

zone
XXX.zone
};

・ゾーンファイル( XXX.zone )(抜粋)

a.XXX. IN NS ijousaki.com.

以上、宜しくお願いします。

回答No.3

maesen

私の認識不足があり申し訳ありません。

＞自分自身が持ってるゾーンレコード（委譲NSレコード）の名前解決を再帰問合せ有効viewのセグメントから再帰問合せで実施すると、"SERVFAIL"が帰ることは正しい動作か？判断できず、ご質問させて頂きました。

正しく無いです。

＞＞→FORMERR resolvingについて
＞ご教授の通り、委譲先DNSサーバのIPアドレスが書いてありました。

委任先のDNSサーバが問題の応答を返したことは明らかですね。

＞ただ、再帰問合せを名前解決時、無効にして同様の
＞コマンドを実行したら、問題無く名前解決出来ました。
＞コマンド：dig @localhost 委譲NS ns +norecure

問題の応答を返すのは委任先のDNSサーバなので、再帰を無効にした場合委任先のDNSへクエリを出さないため応答はありませんから、当然と言えば当然の結果だと思います。

＞本来、委譲NSの設定をする場合、委譲先のDNSにもNSレコードを
＞追記する必要がある様ですが、委譲先DNSはNSレコードの追記を
＞サポートしておらず、切り分けが困難な状況です。

委任先の問題である可能性が極めて高いと思いますが、
このNSレコードが書けないことが原因なのかは、このような環境で検証したことは無いのでわからないです。
応答の中身を見ないとわからないかもしれませんね。

NSレコードが書けないDNSサーバになぜサブドメインの委任をしなければいけないのかというのがちょっと気になります。
親のDNSサーバ（現在設定しているご自身のDNSサーバ）でサブドメインも管理するという選択はありませんでしょうか。

補足

度々の返信、ありがとうございます。

委譲先に再度私から問合せたところ、NSレコードの追加は
オプションで対応してると言うことでした。

なので、本件は委譲先にNSレコードを追記することで
解決するかと思います。
（実際にNSレコードの委譲に対する名前解決を自社DNS側で動作確認出来てないので、recursion yes;設定との切り分けが出来ませんでしたが・・・・）

この度は丁寧なご回答を頂き、ありがとうございました。

回答No.2

maesen

隠れているものが見えた部分がありますが、質問がわかりにくかったようで一番確認したいものが回答が得られていませんでした。

質問と補足を見る限り、view "internal-net"にXXX.zoneが無いようです。

internal-netとexternalをviewで分けているのは一般的なことなのでわかるのですが、
XXX.zoneを管理しているDNSサーバを設定しているに、
なぜ、view "internal-net"にXXX.zoneを設定していないのかを確認したかったのです。

再帰問い合わせが可能なクライアント用のviewなのはわかりますが、自身が管理しているゾーンを引くときまでルートヒントから引かなくてもいいんじゃないかと。

dig @localhost XXX.XXX. ns はこんな問い合わせになると思いますが。。。
自DNSサーバ → ルートヒント → TLD DNS → SLD DNS ・・・・ → 自DNSサーバ → （委譲ドメインDNS）

問い合わせとして正しい姿ではないと思います。

＞→FORMERR resolving・・・のエラーは、DNSサーバの/var/log/messagesになります。

フォーマットエラーなので問い合わせに対する応答データが不正だった訳です。
誰が応答を返したかはFORMERR resolvingの後にIPアドレスがあるはずです。
それを踏まえて、誰がなぜエラーとなる応答を返したのかを調査していく必要があると思うのです。

ログについてはBINDのログを取得したら何か違うものが見えてくる可能性があるんじゃないかと。

logging {
（省略）
};

補足

ご返信頂き、まことに感謝してます。
おかげで、もう少しで解決出来そうです。
もう少しお付き合い下さい。

以下、インラインで記載させて頂きました。

>なぜ、view "internal-net"にXXX.zoneを設定していないのか
→internal-net側にXXX.zoneが有っても無くても
名前解決の結果が同じだったので記載してませんでした。

ただ、再帰問合せを名前解決時、無効にして同様の
コマンドを実行したら、問題無く名前解決出来ました。

コマンド：dig @localhost 委譲NS ns +norecure

そこで、確認させて頂きたいのですが、

view "internal-net"内のクライアントでXXX.zoneの委譲NSレコードを名前解決
する場合、非再帰問合せで問題無く名前解決できれば問題無いのでしょうか？

自分自身が持ってるゾーンレコード（委譲NSレコード）の名前解決を再帰問合せ有効viewのセグメントから再帰問合せで実施すると、"SERVFAIL"が帰ることは正しい動作か？判断できず、ご質問させて頂きました。

＞→FORMERR resolvingについて
ご教授の通り、委譲先DNSサーバのIPアドレスが書いてありました。
本来、委譲NSの設定をする場合、委譲先のDNSにもNSレコードを
追記する必要がある様ですが、委譲先DNSはNSレコードの追記を
サポートしておらず、切り分けが困難な状況です。

以上、宜しくお願いします。

回答No.1

maesen

回答まだ付いていないようなので書かせて頂きますが、ちょっと情報が少ないように思います。

＞名前解決(コマンド：dig @localhost 委譲NS ns )したところ、"SERVFAIL"が表示され

問題が出るのはここだけでしょうか？
自分が管理していないゾーンの各レコードや、

＞・ゾーンファイル( XXX.zone )(抜粋)

このゾーンの委譲するもの以外のレコードは問題無いのでしょうか？

設定ファイルが抜粋なので判断が出来ませんが、
view "internal-net"にマッチするクライアントの名前解決は、設定だけを見るとフォワーダも無くルートヒントの設定も無いのでBINDにデフォルトでコーディングされているルートヒントを使用することになりそうですが、
view "internal-net"の名前解決はどのように考えられて設定されていますでしょうか？
また、XXX.zoneこのゾーンは自DNSサーバが管理しているのにも関わらず、外部に問い合わせるようになりますが、何か理由があるのでしょうか？

＞FORMERR resolving・・・

誰がこのエラーとなる応答を返しているのかを特定しないと解決の糸口が見えないように思います。

digコマンドに+trace オプションを設定したり、ログを取得するなどして調査していったほうが良いかと思います。

疑問ばかりで申し訳ありませんが、参考になる部分があればあると良いです。

お礼

返信ありがとうございます。
先ほどの補足ですが、一点間違ってました。

>view "external"に、recursion yes;を設定しました。
→recursion no;でした。

補足

返信ありがとうございます。
インラインで状況をお伝えさせて頂きます。

＞名前解決(コマンド：dig @localhost 委譲NS ns )したところ、"SERVFAIL"が表示され
問題が出るのはここだけでしょうか？
自分が管理していないゾーンの各レコードや、
＞・ゾーンファイル( XXX.zone )(抜粋)
このゾーンの委譲するもの以外のレコードは問題無いのでしょうか？

→はい、委譲NS以外は問題無く名前解決出来ております。

設定ファイルが抜粋なので判断が出来ませんが、
view "internal-net"にマッチするクライアントの名前解決は、設定だけを見るとフォワーダも無くルートヒントの設定も無いのでBINDにデフォルトでコーディングされているルートヒントを使用することになりそうですが、
view "internal-net"の名前解決はどのように考えられて設定されていますでしょうか？
また、XXX.zoneこのゾーンは自DNSサーバが管理しているのにも関わらず、外部に問い合わせるようになりますが、何か理由があるのでしょうか？

→　view "internal-net"
view "internal-net"は、再帰問い合わせが可能なクライアント用のゾーンとして
localhostや、ルートのゾーン情報をview内に記述し、recursion yes;に設定しました。

→　XXX.zoneのゾーンを外部DNSゾーン(view external)に記述してる件
XXX.zoneはゾーン情報は、コンテンツサーバとして利用し、外部からの問い合わせ
が来た時、XXX.zoneに記述してある問い合わせのみ答えるため
view "external"に、recursion yes;を設定しました。

＞FORMERR resolving・・・
誰がこのエラーとなる応答を返しているのかを特定しないと解決の糸口が見えないように思います。
digコマンドに+trace オプションを設定したり、ログを取得するなどして調査していったほうが良いかと思います。

→FORMERR resolving・・・のエラーは、DNSサーバの/var/log/messagesになります。
※DNSサーバのローカルから、以下のコマンドを実行すると、出力されます。
dig @localhost XXX.XXX. ns

以上、長文になり申し訳ありません。宜しくお願いします。