Tips

2015.03.31

Linux BIND 第1回

BINDについて

検証

クライアントからメールを送った際に近くのMTAに届くが、そのMTAがDNSも兼用していた場合を検証する。
そのMTA兼DNSの /etc/resolve.conf が 127.0.0.1 になっていた場合で、
自分の中(そのBINDの中)に無い社内の独自外部ドメインを解決できるのかどうか?

 MTA兼DNSサーバにメーラーでログインする → クライアントからメールを送る(別の社内の外部ドメイン宛)
 → MTA兼DNSサーバがメールを受け取る → MTA兼DNSサーバの /etc/resolv.conf が nameserver 127.0.0.1 になっている場合どうなるか?

考えられるBIND内部の動作パターンは以下の2つ

1.クライアントからのクエリをダイレクトにMTA兼DNSの中のBINDが処理する
2.クライアントからのクエリをMTAが一度受け取って /etc/resolv.conf のなかを見てDNSに渡して処理する。

結論

結論から言うと解決できなかったのでメールが社内の独自外部ドメインに届かなかった。
以下のような送れなかったというメッセージがでた。
Oct 23 18:59:38 server01 postfix/smtp[8128]: F1BCF4693: to=, relay=none, delay=0.06, delays=0.02/0.03/0/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=tokyo.ac.jp type=AAAA: Host not found)

どうやらクライアントからメールが飛んで来た際のBINDの動きは下記のようになっているようだ。
 クライアントからメール送る → MTA兼DNSサーバに届く → MTA兼DNSサーバの中のBINDが自身の /etc/resolv.conf を参照する
 → /etc/resolv.conf が自身を参照するようになっているなら /etc/named.conf のなかにマッチする記述があるか確認する
 → 無い場合
   ルートDNSサーバなどにクエリを転送して名前解決をはかる
  ある場合
   そのドメイン名からゾーンファイルを参照して、そのドメインを管理している NSレコードに記述されているDNSサーバにクエリを転送して名前解決をはかる。

この動きを確かめる為に、以下のことをやった。
1.MTA兼DNSサーバの自身の /etc/resolv.conf のなかに以下のようにして社内の独自外部ドメイン名を解決できる別のDNSサーバのIPアドレスを記述した。

# vi /etc/resolv.conf
#以下のように記述
namaserver 192.168.10.173     //社内の独自外部ドメインを解決できるサーバのIP

クライアントからメールを送ると社内の独自外部ドメインのメールアカウントにメールが届いた。
これはMTA兼DNSになっているサーバが /etc/resolv.conf を見て MXレコードを解決するためにその記述されたDNSサーバに転送したことを意味する。

2.MTA兼DNSになっているサーバ上の /etc/named.conf に直に社内の外部独自ドメインのMXレコードを解決できるように登録をしてみる
  以下のような感じで記述した(ちなみに1で変更した /etc/resolv.conf のなかは nameserver 127.0.0.1 に戻す)

# vi /etc/named.conf
zone "tokyo.ac.jp" {
        type master;
        file "tokyo.ac.jp";
};
# vi /var/named/tokyo.ac.jp

$TTL    3600
@       IN      SOA     ns01    root(
                2013102301
                60
                60
                3600
                3600 )
        IN      NS      ns01
        IN      MX      10 mail
ns01    IN      A       192.168.10.181
mail    IN      A       192.168.10.182

するとやっぱりクライアントからメールを送ると社内の独自外部ドメインのメールアカウントにメールが届いた。
これはMTA兼DNSになっているサーバが /etc/resolv.conf を見て自分自身の /etc/named.conf を見て
自分自身のゾーンファイルを参照して MXレコードを解決していることを意味する。

DNSSECについて

DNSSECはDNSのセッションを暗号化するための機能。
BINDでこれが動作していると、うまく委任などが動かないことがあるので注意。
/etc/named.conf の中の以下の設定を yes から no に変更すれば委任が出来たりする。

        dnssec-enable no;
        dnssec-validation no;

BINDがインストールされたサーバ上のホスト名の解決について

BINDがインストールされたサーバ自身は、自分自身の中で nslookup コマンドやプログラムから名前解決する場合は
/etc/resolve.confを参照してからそこに記述されているDNSサーバにクエリを転送している(BINDがインストールされているなら 127.0.0.1にすればよい)

だがそのBINDがインストールされたサーバを参照しているDNSクライアントからのクエリが届いた場合、
そのクエリは /etc/resolve.conf は参照せずにDNSサーバの中のプログラムが直に受け取る形になっている。

なのでクライアントからするとDNSサーバ上の /etc/resolv.conf がどうなっていても大丈夫ということになる。

Linux認定資格 LPICを取るなら・・

Linux資格 「LPIC Lv1」徹底解説 連載目次

Recent News

Recent Tips

Tag Search