CentOSによるBIND構築について

Question

前提・実現したいこと

CentOSでBINDによるDNSキャッシュサーバとDNSコンテンツサーバの連携について

インターネットに接続せず、DMZ環境にDNSキャッシュサーバ、イントラ環境にDNSコンテンツサーバを構築して検証をしたいと考えています。
サーバ自体は構築できましたが、DNSキャッシュサーバ経由での名前解決ができません。
以下のサイトを参考にしています。
https://qiita.com/nk9bb8/items/15f4cb9756a2043e4bba

ゾーンはイントラ用とDMZ用に定義し、
イントラドメインはtokyo.local、DMZ用はshibuya.tokyo.localとしています。
また、セグメントは、DMZ環境とイントラ環境で同一セグメント192.168.1.0/24としています。

（5/26追記）以下のホストのIPアドレスを変更しています。
DMZ側のクライアント ホスト名:dmzclient01.shibuya.tokyo.local IPアドレス:192.168.1.21
DMZ側のDNSキャッシュサーバ ホスト名:dmzcache01.shibuya.tokyo.local IPアドレス:192.168.1.22
イントラ側のクライアント ホスト名:intraclient01.tokyo.local IPアドレス:192.168.1.11
イントラ側のDNSコンテンツサーバ ホスト名:intracontents01.tokyo.local IPアドレス:192.168.1.12

イントラ環境のみ、DMZ用ドメイン環境が見られるようにしたいです。

各DNSサーバの設定ファイル（named.conf）は以下の通りです。

■DNSキャッシュサーバ
options {
listen-on port 53 { 192.168.1.0/24; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { 192.168.1.0/24; };
allow-recursion { 192.168.1.0/24; };
allow-query-cache { 192.168.1.0/24; };
recursion yes;

    //dnssec-enable yes;
    //dnssec-validation yes;
    dnssec-enable no;

    bindkeys-file "/etc/named.iscdlv.key";

    managed-keys-directory "/var/named/dynamic";

    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";

};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "shibuya.tokyo.local" IN {
type stub;
masters { 192.168.1.21; 192.168.1.22; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

■DNSコンテンツサーバ
options {
listen-on port 53 { 192.168.1.0/24; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { 192.168.1.0/24; };
allow-transfer { none; };
recursion no;

//dnssec-enable yes;
//dnssec-validation yes;
dnssec-enable no;

bindkeys-file "/etc/named.iscdlv.key";

managed-keys-directory "/var/named/dynamic";

pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";

};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "tokyo.local" IN {
type master;
file "tokyo.local";
allow-query { 192.168.1.11; 192.168.1.12; };
allow-transfer { none; };
};

zone "shibuya.tokyo.local" IN {
type master;
file "shibuya.tokyo.local";
allow-query { any; };
allow-transfer { none; };
};

zone "1.168.192.in-addr.arpa" IN {
type master;
file "1.168.192.in-addr.arpa";
allow-query { 192.168.1.11; 192.168.1.12; };
allow-transfer { none; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

※tokyo.localの正引きゾーンファイル
$TTL 86400
@ IN SOA intracontents01.tokyo.local. root.tokyo.local. (
20180524
3600
1800
604800
7200 )

                 IN      NS      intracontents01.tokyo.local.

intraclient01 IN A 192.168.1.11
intracontents01 IN A 192.168.1.12

※shibuya.tokyo.localの正引きゾーンファイル
$TTL 86400
@ IN SOA dmzcache01.shibuya.tokyo.local. root.shibuya.tokyo.local. (
20180524
3600
1800
604800
7200 )
IN NS dmzcache01.shibuya.tokyo.local.
dmzclient01 IN A 192.168.1.21
dmzcache01 IN A 192.168.1.22
;

逆引きファイルのついての作成方法がわからず、現在出せる情報は上記の通りです。

5/27 9:20更新
御協力いただけたことで環境を作ることはできましたが、DNSコンテンツサーバを起動しないでおいて、DNSキャッシュサーバがキャッシュを元にクライアントへ回答するか試しましたが、しませんでした。

ご教授の程宜しくお願い致します。

Comments

[coco_bauer]

PCおよびネットワークの構成は、どうなっているのですか？　DMZ環境とイントラ環境で同一セグメントということは、192.168.1.1のマシンがDMZとイントラにそれぞれ1台ずつという状況が可能になると思いますが、同一IP間の通信はどうするのですか？

[退会済みユーザー]

ご返信ありがとうございます。今回想定している環境は以下の通りです。

DMZ側のクライアント
ホスト名:dmzclient01.shibuya.tokyo.local
IPアドレス:192.168.1.1

DMZ側のDNSキャッシュサーバ
ホスト名:dmzcache01.shibuya.tokyo.local
IPアドレス:192.168.1.2

イントラ側のクライアント
ホスト名:intraclient01.tokyo.local
IPアドレス:192.168.1.11

イントラ側のDNSコンテンツサーバ
ホスト名:intracontents01.tokyo.local
IPアドレス:192.168.1.12

そのため、同一IPアドレス間の通信は想定していません。
また、セグメントは同じだが、その中で2つのドメインネットワークを構成しています。
変な環境で申し訳ございません。
宜しくお願いいたします。

[mkgrei]

master/slaveではないことに特別な意味があるのでしょうか？また問い合わせが発生した際のDNSキャッシュサーバのログはどうなっていますでしょうか？

[退会済みユーザー]

ご返信ありがとうございます。今回は機能を満たすことが確認できれば良いとの判断でスレーブは用意していません。また、DNSサーバのログですが、pingやnslookupをしましたが、名前またはサービスが不明です と出てきています。他のログは出てきておらず、キャッシュサーバとコンテンツサーバとで通信が無いようです。
宜しくお願いいたします。

[mkgrei]

systemctl status namedにはエラーは出ていますか？

[mkgrei]

slaveの利点はキャッシュされなくても、masterとの通信状況を確認できることにあると思います。

[退会済みユーザー]

ご返信ありがとうございます。エラーは出ておらず、またスレーブは要求されていないため、今回の環境においては無視いただいて構いません。

[CHERRY]

キャッシュサーバーのルートゾーン “.” の設定はどうなっていますか？

[退会済みユーザー]

ご返信ありがとうございます。キャッシュサーバ、コンテンツサーバともにインターネットに接続しないため、named.confにはルートゾーンの設定は入れていません。よろしくお願いします。

Answer 1

インターネットに接続せず、DMZ環境にDNSキャッシュサーバ

キャッシュサーバー(リゾルバー)ですから、ルートサーバー(または上位リゾルバー)に問い合わせを行ない、結果をキャッシュするので、インターネットへの接続が必要です。

ゾーンはイントラ用とDMZ用に定義し、

キャッシュサーバー兼、zone "shibuya.tokyo.local" のコンテンツサーバーということでしょうか？

イントラ環境のみ、DMZ用ドメイン環境が見られるようにしたいです。

何をしようとして、どこまでできて、どこができないのかを教えてください。

1. DMZ側クライアント(192.168.1.1)→DMZ側 DNSサーバー(192.168.1.2)
  1-1. ping による疎通はできますか？
  1-2. "shibuya.tokyo.local" ゾーンへの問い合わせ＆応答は？
  1-3. 外部のドメイン(www.google.com など)への問い合わせ＆応答は？ (不要？)

2. イントラ側 DNSサーバー(192.168.1.12)→DMZ側 DNSサーバー(192.168.1.2)
  2-1. ping による疎通はできますか？
  2-2. "shibuya.tokyo.local" ゾーンへの問い合わせ＆応答は？
       (dig @192.168.1.2 HOSTNAME.shibuya.tokyo.local)
  2-3. 外部のドメイン(www.google.com など)への問い合わせ＆応答は？ (不要？)
       (dig @192.168.1.2 www.google.com)

3. イントラ側クライアント(192.168.1.11)→イントラ側 DNSサーバー(192.168.1.12)
  3-1. ping による疎通はできますか？
  3-2. "tokyo.local" ゾーンへの問い合わせ＆応答は？
  3-3. "shibuya.tokyo.local" ゾーンへの問い合わせ＆応答は？
  3-4. 外部のドメイン(www.google.com など)への問い合わせ＆応答は？ (不要？)

また、CentOS, bind のバージョン、設定ファイル(named.conf だけでも)、ログ(今回はまだ不要)の情報も。(質問を編集して追記ください)

セグメントは、DMZ環境とイントラ環境で同一セグメント192.168.1.0/24としています。

別セグメントにして、間にルーター／ファイアーウォールを置いて通信を制限するのが一般的だと思いますが、192.168.1.0/29 など、/24 内で小さく分けているということでしょうか？
単に、別ドメインとして、「DMZ」「イントラ」と呼んでいるということでしょうか？

###(2018/05/26 11:10) 追記
コメントにも書きましたが、「DMZ」「イントラ」という用語から、勝手に「イントラ」→「DMZ」→インターネットという経路と思い込みました。

クライアント→DNSキャッシュ→DNSコンテンツ(tokyo.local, shibuya.tokyo.local)

で、ゾーンごとにアクセス元IPアドレスで制限したいということですね。

1. イントラ側クライアント(192.168.1.11)→イントラ側 DNSサーバー(192.168.1.12)

3-2. "tokyo.local" ゾーンへの問い合わせ＆応答は？→届きません。

ここはできるはずです。
ログファイル(/var/named/data/named.run または /var/named/chroot/var/named/data/named.run)を確認ください。

DNSコンテンツサーバーの named.conf

zone "shibuya.tokyo.local" の allow-query の IPアドレスが違うようです。
(192.168.178.21 → 192.168.1.21)

DNSキャッシュサーバーの named.conf

DNSコンテンツサーバーに DNSSEC の設定はしていないようですので、DNSSEC の検証を無効にする必要があります。

(DNSキャッシュサーバーの named.conf)
options {
        (略)
    //dnssec-enable yes;
    //dnssec-validation yes;
    dnssec-enable no
        (略)
}

        (略)
//include "/etc/named.root.key"; 

Comments

[退会済みユーザー]

ご返信ありがとうございます。以下の通りお答えいたします。また、ホスト名による端末、サーバ表記とさせてください。

キャッシュサーバー(リゾルバー)ですから、ルートサーバー(または上位リゾルバー)に問い合わせを行ない、結果をキャッシュするので、インターネットへの接続が必要です。

→今回は、ルートサーバをcontents01(DNSコンテンツサーバ)としています。また、インターネットにつなげない、ローカルの環境のため、インターネットの接続は想定していないです。この場合でもDNSキャッシュサーバは機能は機能すると認識しています。インターネット接続が必須という、参考文献等はございますでしょうか。

キャッシュサーバー兼、zone "shibuya.tokyo.local" のコンテンツサーバーということでしょうか？
→そうです。shibuya.tokyo.loccalにはDNSキャッシュサーバ、tolyo.localには上位リゾルバーであるDNSコンテンツサーバの構成にしています。

イントラ環境のみ、DMZ用ドメイン環境が見られるようにしたいです。
→1. DMZ側クライアント(192.168.1.1)→DMZ側 DNSサーバー(192.168.1.2)
1-1. ping による疎通はできますか？→IPアドレスでのpingはできますが、ドメイン名でのpingはできません。
1-2. "shibuya.tokyo.local" ゾーンへの問い合わせ＆応答は？→届きません。
1-3. 外部のドメイン(www.google.com など)への問い合わせ＆応答は？ (不要？)→→不要です。

2. イントラ側 DNSサーバー(192.168.1.12)→DMZ側 DNSサーバー(192.168.1.2)
2-1. ping による疎通はできますか？→ping による疎通はできますか？→IPアドレスでのpingはできますが、ドメイン名でのpingはできません。
2-2. "shibuya.tokyo.local" ゾーンへの問い合わせ＆応答は？→届きません。
(dig @192.168.1.2 HOSTNAME.shibuya.tokyo.local)
2-3. 外部のドメイン(www.google.com など)への問い合わせ＆応答は？ (不要？)→不要です。
(dig @192.168.1.2 www.google.com)

3. イントラ側クライアント(192.168.1.11)→イントラ側 DNSサーバー(192.168.1.12)
3-1. ping による疎通はできますか？→→IPアドレスでのpingはできますが、ドメイン名でのpingはできません。
3-2. "tokyo.local" ゾーンへの問い合わせ＆応答は？→届きません。
3-3. "shibuya.tokyo.local" ゾーンへの問い合わせ＆応答は？→届きません。
3-4. 外部のドメイン(www.google.com など)への問い合わせ＆応答は？ (不要？)→不要です。

また、CentOS, bind のバージョン、設定ファイル(named.conf だけでも)、ログ(今回はまだ不要)の情報も。(質問を編集して追記ください)
→CentS 7.4 、bind9.9.4 、設定ファイルとゾーン定義ファイルは質問の欄へ追記します。

別セグメントにして、間にルーター／ファイアーウォールを置いて通信を制限するのが一般的だと思いますが、192.168.1.0/29 など、/24 内で小さく分けているということでしょうか？
単に、別ドメインとして、「DMZ」「イントラ」と呼んでいるということでしょうか？
→同一セグメント内で単にドメインとして「DMZ」、「イントラ」と呼んでいます。

以上、よろしくお願いします。

[退会済みユーザー]

また、こちらの都合で恐縮ですが、IPアドレスを本日、以下のように変更しています。
・DMZ側 クライアント(192.168.1.21)
・DMZ側 DNSサーバー(192.168.1.22)
以上、よろしくお願いします。

[TaichiYanagiya]

すみません。
まず、「DMZ」「イントラ」という用語から、勝手に「イントラ」→「DMZ」→インターネットという経路と思い込みました。
キャッシュサーバー＝フルサービスリゾルバーであることが多いため、ルートサーバーへの接続＝インターネット接続が必須と回答しましたが、フルサービスリゾルバーでないならば、その限りではありません。

[退会済みユーザー]

失礼いたしました。named.confにつきましては、質問部分で訂正いたしました。
で、ゾーンごとにアクセス元IPアドレスで制限したいということですね。
3. イントラ側クライアント(192.168.1.11)→イントラ側 DNSサーバー(192.168.1.12)
3-2. "tokyo.local" ゾーンへの問い合わせ＆応答は？→届きません。
ここはできるはずです。
ログファイル(/var/named/data/named.run または /var/named/chroot/var/named/data/named.run)を確認ください。
→イントラ環境のDNSコンテンツサーバ側で上記ファイルとtail -f /var/log/messagesコマンドで確認をしつつ、並行してイントラ環境のクライアントからping intracontents01.tokyo.localしましたが、ログ書き込みがありませんでした。よろしくお願いします。

[退会済みユーザー]

こちらで全てのクライアントとサーバのファイアウォールを停止し、
systemctl enable named-chrootコマンドを利用し、かつイントラ用のゾーンの範囲をanyにしてサービス再起動したところ、イントラ側のクライアントからDMZ側の名前解決及びpingができるようになりました。
ただし、DMZ側からはまだ名前解決ができません。

[TaichiYanagiya]

DNSキャッシュサーバーのシェル(コマンドライン)から DNSコンテンツサーバーへの問い合わせ・応答を確認ください。(dig @192.168.1.12 HOSTNAME.shibuya.tokyo.local)
これが OK で、DMZ側のクライアントから DNSキャッシュサーバーへの問い合わせが NG の場合、DNSキャッシュサーバーのログファイル(/var/named/chroot/var/named/data/named.run)を確認ください。

[退会済みユーザー]

お世話になります。こちらでもご連絡になりますが、コンテンツサーバにルートヒント用のゾーン定義をしたところ、すべての名前解決ができるようになりました。ただし、コンテンツサーバをシャットダウンさせると、名前解決ができなくなります。

[退会済みユーザー]

[root@dmzcache01 ~]# dig @192.168.1.12 dmzcache01.shibuya.tokyo.local.

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @192.168.1.12 dmzcache01.shibuya.tokyo.local.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13009
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dmzcache01.shibuya.tokyo.local. IN A

;; ANSWER SECTION:
dmzcache01.shibuya.tokyo.local. 86400 IN A 192.168.1.22

;; AUTHORITY SECTION:
shibuya.tokyo.local. 86400 IN NS intracontents01.tokyo.local.

;; Query time: 0 msec
;; SERVER: 192.168.1.12#53(192.168.1.12)
;; WHEN: 日 5月 27 00:10:58 JST 2018
;; MSG SIZE rcvd: 105

[TaichiYanagiya]

> コンテンツサーバをシャットダウンさせると、名前解決ができなくなります。

コンテンツサーバーが停止しても "shibuya.tokyo.local" の名前解決を行ないたいのであれば、キャッシュサーバーを利用するのは適切ではありません。
DMZ DNSサーバーを slave にする、もしくは、zone "shibuya.tokyo.local" のマスターを DMZ DNSサーバーにして、相互に type forward するといいと思います。

[退会済みユーザー]

お世話になります。ということは、CentOSの場合は、応答を早めると言う意味でのキャッシュということでしょうか。
また、もう1点確認したいのですが、DMZのクライアントからDMZのDNSキャッシュサーバへのdigコマンドを実行したところ、Answerが来ないことがわかりました。DMZクライアントのresolv.confは、DMZのDNZキャッシュサーバのIPアドレスを選び、DMZキャッシュサーバのresolv.confは、ループバックアドレスとイントラのDNSコンテンツサーバを選べばよいという認識ですが、合っていますでしょうか。
よろしくお願いいたします。

[退会済みユーザー]

参考までに、DMZキャッシュサーバの定義ファイルは以下の通りです。
options {
listen-on port 53 { 127.0.0.1; 192.168.1.0/24; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { 192.168.1.0/24; };
allow-recursion { 192.168.1.0/24; };
allow-query-cache { 192.168.1.0/24; };
recursion yes;
//dnssec-enable yes;
//dnssec-validation yes;
dnssec-enable no;
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

zone "." IN {
type hint;
file "named.ca";
};

zone "shibuya.tokyo.local" IN {
type stub;
masters { 192.168.1.12; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

resolv.confは以下のとおりです。
# Generated by NetworkManager
search shibuya.tokyo.local
nameserver 192.168.1.12

[退会済みユーザー]

また、本日、DNSコンテンツサーバについて、viewを導入し、イントラ用とDMZ用で分けました。
options {
listen-on port 53 { 127.0.0.1; 192.168.1.0/24; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { 192.168.1.0/24; };
allow-transfer { none; };
recursion no;

//dnssec-enable yes;
//dnssec-validation yes;
dnssec-enable no;

bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

view "internal" {
match-clients { 192.168.1.11; 192.168.1.12; };

zone "." {
type hint;
file "named.ca";
};

zone "tokyo.local" IN {
type master;
file "tokyo.local";
allow-query { 192.168.1.11; 192.168.1.12; };
allow-transfer { none; };
};

zone "1.168.192.in-addr.arpa" IN {
type master;
file "1.168.192.in-addr.arpa";
allow-query { 192.168.1.11; 192.168.1.12; };
allow-transfer { none; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

};

view "external" {
match-clients { 192.168.1.21; 192.168.1.22; };

zone "." IN {
type hint;
file "named.ca";
};

zone "shibuya.tokyo.local" IN {
type master;
file "shibuya.tokyo.local";
allow-query { 192.168.1.21; 192.168.1.22; };
allow-transfer { none; };
};

zone "1.168.192.in-addr.arpa" IN {
type master;
file "1.168.192.in-addr.arpa.dmz";
allow-query { 192.168.1.21; 192.168.1.22; };
allow-transfer { none; };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

};

また、各ゾーンファイルは以下の通りです。

イントラ用正引きゾーンファイル
$TTL 86400
@ IN SOA intracontents01.tokyo.local. root.tokyo.local. (
20180524
3600
1800
604800
7200 )
shibuya.tokyo.local. IN NS intracontents01.tokyo.local.
dmzcache01 IN A 192.168.1.22
dmzclient01 IN A 192.168.1.21
；

DMZ用正引きゾーンファイル
$TTL 86400
@ IN SOA intracontents01.tokyo.local. root.tokyo.local. (
20180524
3600
1800
604800
7200 )
shibuya.tokyo.local. IN NS intracontents01.tokyo.local.
dmzcache01 IN A 192.168.1.22
dmzclient01 IN A 192.168.1.21
;

イントラ用逆引きゾーンファイル
$TTL 86400
@ IN SOA intracontents01.tokyo.local. root.tokyo.local. (
20180524
3600
1800
604800
7200 )

IN NS intracontents01.tokyo.local.
12 IN PTR intracontents01.tokyo.local.
11 IN PTR intraclient01.tokyo.local.
22 IN PTR dmzcache01.shibuya.tokyo.local.
21 IN PTR dmzclient01.shibuya.tokyo.local.
;

DMZ用逆引きゾーンファイル
$TTL 86400
@ IN SOA intracontents01.tokyo.local. root.tokyo.local. (
20180524
3600
1800
604800
7200 )

IN NS intracontents01.tokyo.local.
22 IN PTR dmzcache01.shibuya.
21 IN PTR dmzclient01.shibuya.
;

以上となります。長文で申し訳ございません。よろしくお願いします。

[TaichiYanagiya]

設定ファイルはコメント欄ではなく、質問を編集して、コードブロックで記述して欲しいです。

> ということは、CentOSの場合は、応答を早めると言う意味でのキャッシュということでしょうか。

有効期間(TTL)まではキャッシュに保持した値を応答しますが、TTL を過ぎてしまったり、キャッシュを持っていない(事前に問い合わせがなかった)場合は、参照先(forwarders)が必要になります。

> DMZのクライアントからDMZのDNSキャッシュサーバへのdigコマンドを実行したところ、Answerが来ないことがわかりました。

DNSキャッシュサーバーのログファイルを確認ください。

> DMZクライアントのresolv.confは、DMZのDNZキャッシュサーバのIPアドレスを選び、

はい。

> DMZキャッシュサーバのresolv.confは、ループバックアドレスとイントラのDNSコンテンツサーバを選べばよいという認識ですが、合っていますでしょうか。

こちらは named とは無関係です。
OS が参照する DNSサーバー(リゾルバー)は /etc/resolv.conf に設定します。
named が参照する DNSサーバーは named.conf の forwarders に設定します。

[TaichiYanagiya]

view を拝見しました。
それぞれ、ゾーンと参照元クライアントが分かれていて、相互に参照することがないのであれば、素直に 2台の独立した DNSコンテンツサーバーにした方がいいのではないでしょうか？

[退会済みユーザー]

大変失礼いたしました。また、本日、resolv.confを修正し、すべての通信に異常がないことを確認いたしました。
お手数をおかけ申し訳ございません。また、ご確認いただきありがとうございました。

Answer 2

resolv.confにキャッシュサーバ自身を設定したところ、問題なく設定が完了しました。