質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
CentOS

CentOSは、主にRed Hat Enterprise Linux(RHEL)をベースにした、フリーのソフトウェアオペレーティングシステムです。

ドメイン

ドメインとは本来、領域や範囲の意味を持ち、インターネット上では特定の部分領域を指します。ネットワークやコンピュータの識別に利用され、所得することでホームページを公開したり、メールアドレスを作成できます。

DNS

DNSとは、Domain Name Systemのことで、インターネットなどのTCP/IPネットワーク上でドメイン名やホスト名と、IPアドレスとの対応づけを管理するシステムです。DNSのデータベースは、IPアドレスの4つの数字を通知するDNSサーバーで構築されており、IPアドレスをドメイン名から引き出す機能やドメイン名に関するメールサーバ情報を取り扱っています。

Linux

Linuxは、Unixをベースにして開発されたオペレーティングシステムです。日本では「リナックス」と呼ばれています。 主にWebサーバやDNSサーバ、イントラネットなどのサーバ用OSとして利用されています。 上位500のスーパーコンピュータの90%以上はLinuxを使用しています。 携帯端末用のプラットフォームAndroidは、Linuxカーネル上に構築されています。

Q&A

解決済

2回答

3734閲覧

CentOSによるBIND構築について

退会済みユーザー

退会済みユーザー

総合スコア0

CentOS

CentOSは、主にRed Hat Enterprise Linux(RHEL)をベースにした、フリーのソフトウェアオペレーティングシステムです。

ドメイン

ドメインとは本来、領域や範囲の意味を持ち、インターネット上では特定の部分領域を指します。ネットワークやコンピュータの識別に利用され、所得することでホームページを公開したり、メールアドレスを作成できます。

DNS

DNSとは、Domain Name Systemのことで、インターネットなどのTCP/IPネットワーク上でドメイン名やホスト名と、IPアドレスとの対応づけを管理するシステムです。DNSのデータベースは、IPアドレスの4つの数字を通知するDNSサーバーで構築されており、IPアドレスをドメイン名から引き出す機能やドメイン名に関するメールサーバ情報を取り扱っています。

Linux

Linuxは、Unixをベースにして開発されたオペレーティングシステムです。日本では「リナックス」と呼ばれています。 主にWebサーバやDNSサーバ、イントラネットなどのサーバ用OSとして利用されています。 上位500のスーパーコンピュータの90%以上はLinuxを使用しています。 携帯端末用のプラットフォームAndroidは、Linuxカーネル上に構築されています。

1グッド

1クリップ

投稿2018/05/25 11:38

編集2018/05/27 00:24

前提・実現したいこと

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キャッシュサーバがキャッシュを元にクライアントへ回答するか試しましたが、しませんでした。

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

set0gut1👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

coco_bauer

2018/05/25 12:12

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

退会済みユーザー

2018/05/25 12:31 編集

ご返信ありがとうございます。今回想定している環境は以下の通りです。 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

2018/05/25 14:42

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

退会済みユーザー

2018/05/25 14:47 編集

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

2018/05/25 15:40

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

2018/05/25 15:41

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

退会済みユーザー

2018/05/25 21:15

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

2018/05/26 04:23

キャッシュサーバーのルートゾーン “.” の設定はどうなっていますか?
退会済みユーザー

退会済みユーザー

2018/05/26 04:26

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

回答2

0

インターネットに接続せず、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";

投稿2018/05/25 16:03

編集2018/05/26 02:10
TaichiYanagiya

総合スコア12141

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2018/05/25 23:17

ご返信ありがとうございます。以下の通りお答えいたします。また、ホスト名による端末、サーバ表記とさせてください。 キャッシュサーバー(リゾルバー)ですから、ルートサーバー(または上位リゾルバー)に問い合わせを行ない、結果をキャッシュするので、インターネットへの接続が必要です。 →今回は、ルートサーバを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」、「イントラ」と呼んでいます。 以上、よろしくお願いします。
退会済みユーザー

退会済みユーザー

2018/05/26 00:26 編集

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

2018/05/26 02:07

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

退会済みユーザー

2018/05/26 04:24

失礼いたしました。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しましたが、ログ書き込みがありませんでした。よろしくお願いします。
退会済みユーザー

退会済みユーザー

2018/05/26 06:43

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

2018/05/26 14:46

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

退会済みユーザー

2018/05/26 15:13 編集

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

退会済みユーザー

2018/05/26 15:11 編集

[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

2018/05/27 04:26

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

退会済みユーザー

2018/05/27 12:03 編集

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

退会済みユーザー

2018/05/27 11:34 編集

参考までに、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
退会済みユーザー

退会済みユーザー

2018/05/27 12:01 編集

また、本日、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

2018/05/28 01:56

設定ファイルはコメント欄ではなく、質問を編集して、コードブロックで記述して欲しいです。 > ということは、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

2018/05/28 01:59

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

退会済みユーザー

2018/05/28 13:52

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

0

ベストアンサー

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

投稿2018/05/28 13:53

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問