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

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

ただいまの
回答率

90.75%

  • Linux

    3468questions

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

  • CentOS

    2559questions

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

  • DNS

    261questions

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

  • ドメイン

    25questions

CentOSによるBIND構築について

解決済

回答 2

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 236

nakamurahhhh

score 2

 前提・実現したいこと

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

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

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • nakamurahhhh

    2018/05/26 06:15

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

    キャンセル

  • CHERRY

    2018/05/26 13:23

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

    キャンセル

  • nakamurahhhh

    2018/05/26 13:26

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

    キャンセル

回答 2

+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アドレスで制限したいということですね。

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コンテンツサーバーの 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/26 08: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 09:25 編集

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

    キャンセル

  • 2018/05/26 11:07

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

    キャンセル

  • 2018/05/26 13: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 15:43

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

    キャンセル

  • 2018/05/26 23: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/27 00:05 編集

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

    キャンセル

  • 2018/05/27 00:07 編集

    [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

    キャンセル

  • 2018/05/27 13:26

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

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

    キャンセル

  • 2018/05/27 19:46 編集

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

    キャンセル

  • 2018/05/27 20:24 編集

    参考までに、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 20:32 編集

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


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

    キャンセル

  • 2018/05/28 10: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 に設定します。

    キャンセル

  • 2018/05/28 10:59

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

    キャンセル

  • 2018/05/28 22:52

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

    キャンセル

check解決した方法

0

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

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

  • ただいまの回答率 90.75%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る

  • Linux

    3468questions

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

  • CentOS

    2559questions

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

  • DNS

    261questions

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

  • ドメイン

    25questions