hikaku-server
ServersMan@VPS（CentOS7） DNSサーバの設定方法（BIND）
DTI ServersMan@VPS（CentOS7）のBINDの設定方法です。
yumでBINDをインストールするとバージョンは
bind-9.9.4-14.el7_0.1.x86_64.rpmでした。
BINDとは一番有名なDNSサーバのソフトウェアです。Berkeley Internet Name
Domainの略です。他のDNSサーバとしては、WindowsではWindowサーバのDNS
機能や、フリーソフトのBlackJumboDogなどが有ります。
LinuxではBINDの他にBINDと互換性のあるNSDなどが有ります。
NSDはキャッシュサーバ機能は有りません。
本ページの目次
BINDのインストール
■bind、bind-utils、bind-chrootのインストール
yum install bind bind-utils bind-chroot
chrootの使用
/usr/libexec/setup-named-chroot.sh /var/named/chroot on
設定ファイル（named.conf）の確認
■設定ファイルの確認
vi /var/named/chroot/etc/named.conf
インストール直後のnamed.conf
※コメントアウトしている箇所は掲載していません。
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
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 { localhost; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
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";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
また、コメントアウトしている箇所に以下の記載が有りました。
If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
If you are building a RECURSIVE (caching) DNS server, you need to enable recursion.
If your recursive DNS server has a public IP address, you MUST enable access control to limit queries to your legitimate users.
Failing to do so will cause your server to become part of large scale DNS amplification attacks.
Implementing BCP38 within your network would greatly reduce such attack surface.
訳
権威DNSサーバを構築する場合、recursionを有効にしないこと。
再帰的な（キャッシング）DNSサーバを構築する場合、
recursionを有効にする必要があります。
再帰的なDNSサーバがパブリックIPアドレスを持っている場合は、正当なユーザ
からのクエリ以外を制限するACL（アクセス制御）を有効にする必要があります。
そうしないと、そのDNSサーバが大規模なDNS amp攻撃（DNS増幅攻撃）の
一部になります。BCP38（イングレスフィルタリング、ingress filtering、RFC2827）を
実装すると大幅にそのような攻撃の危険性を減少させます。
設定の実施（権威DNSサーバの構築）
自分の外部用ゾーン情報のみを返答する権威DNSサーバを構築しました。
そのためviewも使用しませんでした。また自サーバが使用するDNSサーバ
（resolv.confに記載しているDNSサーバ）は外部の（＝このサーバではない）
DNSサーバです。
その他（権威DNSサーバ兼DNSキャッシュサーバ、DNSキャッシュサーバ）
の設定方法は以下のページに記載しました。
■named.confの編集
vi /var/named/chroot/etc/named.conf
変更する箇所
listen-on port 53 { 自分のIPアドレス; };
listen-on-v6 { none; }; // IPv6を使用しない
allow-query { any; }; //全ての送信元から問い合わせを受ける
allow-query-cache { none; }; // 全ての送信元に対してキャッシュを回答しない
recursion no; // 全ての送信元に対して再帰検索不可
// zone "." IN { ※ルートヒントの使用予定が無いためコメントアウト
// type hint;
// file "named.ca";
// };
zone "example.com" IN {
type master;
file "example.com"; //自分のゾーン情報を回答
allow-update { none; };
};
■IPv4専用設定について
稼働後、/var/log/messageに
「error (address not available) resolving 'pdns196.ultradns.org/A/IN': 2001:500:40::1#53」
と表示されました。man namedには以下のように記載されていまいた。
man named
OPTIONS
-4
Use IPv4 only even if the host machine is capable of IPv6. -4 and -6
are mutually exclusive.
-6
Use IPv6 only even if the host machine is capable of IPv4. -4 and -6
are mutually exclusive.
vi /etc/sysconfig/named
OPTIONS="-4"を追加しました。
# BIND named process options
# ~~~~~~~~~~~~~~~~~~~~~~~~~~
#
# OPTIONS="whatever" -- These additional options will be passed to named
# at startup. Don,t add -t here, enable proper
# -chroot.service unit file.
OPTIONS="-4"
named-chrootを再起動するとerrorが出なくなりました。
ゾーンファイルの作成
「named.localhost」をコピーして「example.com」ゾーンファイルを
作成することにしました。
cd /var/named/chroot/var/named
cp named.localhost example.com
vi /var/named/chroot/var/named/example.com
■コピー元のnamed.localhost
$TTL 1D
@ IN SOA @ rname.invalid. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS @
A 127.0.0.1
AAAA ::1
■コピー先のexample.com
※本来は各時間を適切に指定しましょう。
1行目の意味
1つのゾーンファイルに複数のゾーン情報を記載する場合は1行目は$ORIGIN
ディレクティブというものが入ります。$ORIGINディレクティブについては後に
少し触れます。
「$TTL 1D」とは、各レコードの余命、生存時間（Time To Liveの略）が
1日であることを示します。他のネームサーバ（キャッシュサーバ）がこの
ネームサーバのゾーン情報を取得した際、「その情報の有効期間」として参照される
値です。この有効期間内は、そのキャッシュサーバはパソコン（リゾルバ）等へ回答
する際にキャッシュされた情報を回答します。
パソコン（リゾルバ）でもipconfig /displaydnsと入力するとレコードのTime To Live
が見られます。DNS情報のクリアはipconfig /flushdnsです。また、パソコンでの
インターネット上の名前の解決において、DNSを使用しない場合はホスツファイルに
記載したりします。
またDNS回答時にレスポンス・コード 3 NXDomainであった場合は問い合わせ
された名前が見つからなかったことを表しますが、その場合はMinimumの時間を
キャッシュする時間の上限とします。このことをネガティブキャッシュ（RFC 2308）、
ネガティブキャッシュの上限値と言います。
DNSの浸透、伝播においてはこれらの値が関係しますね。
2行目～7行目の意味
2行目～7行目にはSOAレコードが記載されています。
SOAレコード（エスオーエーレコード）とは、Start Of Authorityの略です。
ゾーンファイルの大元のデータを保有しているネームサーバ名、
そのドメインの管理者のメールアドレス、ゾーンの情報に関する
時間（リフレッシュする時間等々）が記載されています。
以下の書式です。
@ IN SOA ゾーンの元データを持つDNSサーバ名(≒プライマリDNSサーバ名). 管理者メールアドレス. (ゾーンに関する各時間)
@の意味は、レコードの最後に「.」を付けない場合には「特定の文字列」が
付加（代入）されます。という意味です。「特定の文字列」とは、
「$ORIGINディレクティブに記載されている文字列」です。
$ORIGINディレクティブは1つのゾーンファイルに複数のゾーン情報を記載する
時に使われますね。
$ORIGINディレクティブの記載方法は、通常1行目に
$ORIGIN example.com.と記載します。$ORIGINディレクティブの記載が無い
場合は上記のnamed.confで書いたゾーン名が「特定の文字列」です。
「ゾーンの元データを持つDNSサーバ名(≒プライマリDNSサーバ名).」はMNAMEと
言われます。設定時、稀に末尾にドットを付けることを忘れそうになります。
「管理者メールアドレス.」はRNAMEと言います。こちらも末尾にドットが必要です。
また、ドメインでは用意しておくべきメールアドレスと言うものが何個かあります。
serialはゾーン情報のシリアル値です。スレーブサーバは、この値が増加していれば
ゾーン情報の更新が有ったと認識します。
refreshはスレーブサーバがゾーン情報の更新の有無をチェックする周期の目安値です。
強制的にチェックさせるには、スレーブサーバでrndc reloadを行います。
retryはポーリング失敗時の再試行間隔です。
expireはマスターサーバ障害時、スレーブサーバは、この値の時間まではマスターサーバ
から取得したゾーン情報を有効な情報としてサービスを継続します。
そのためこの時間以内にマスターサーバを復旧させなければDNSエラーとなります。
RFC1912で触れられています。私がDNSサーバを構築する時はだいたい1～2週間に
していました。遠方でリモートも許可していないDNSサーバは2週間に設定していました。
minimumは上述の通りで、DNS回答時にレスポンス・コード 3 NXDomainであった
場合は問い合わせされた名前が見つからなかったことを表しますが、その場合は、
ここの値がキャッシュする時間の上限とされます。このことをネガティブキャッシュ、
ネガティブキャッシュの上限値と言います。
■ゾーンファイルの所有者変更
chown named:named example.com
named-chrootの起動・ポート開放・ログ確認
named-chrootの起動
インストール直後は以下のようになっています。
[root@dti-vps-srv94 named]# systemctl status named-chroot
named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; disabled)
Active: inactive (dead)
[root@dti-vps-srv94 named]# systemctl status named
named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; disabled)
Active: inactive (dead)
[root@dti-vps-srv94 named]# systemctl is-enabled named-chroot
disabled
[root@dti-vps-srv94 named]# systemctl is-enabled named
disabled
■named-chrootを起動します。
systemctl start named-chroot
■named-chrootを自動起動と指定します。
systemctl enable named-chroot
※自動起動と指定されたかの確認は
systemctl is-enabled named-chroot
ポートの開放
■ファイアウォール（firewalldやiptables）でのポート53の開放
ファイアウォールでポート53を開けます。多く使われるのはudp/53で、
512byte以上の応答とゾーン転送はtcp/53を使用します。
・firewalldの場合
■ゾーンにサービスを追加する
firewall-cmd --zone=ゾーン名（publicやdmzなど） --add-service=dns --permanent
※最初から有るサービス「DNS」にはudp/53とtcp/53が含まれています。
cat /usr/lib/firewalld/services/dns.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
<short>DNS</short>
<description>The Domain Name System (DNS) is used to provide
and request host and domain names. Enable this option,
if you plan to provide a domain name service (e.g. with bind).</description>
<port protocol="tcp" port="53"/>
<port protocol="udp" port="53"/>
</service>
※またはゾーンにポートを追加する
firewall-cmd --zone=ゾーン名（publicやdmzなど） --add-port=53/udp --permanent
firewall-cmd --zone=ゾーン名（publicやdmzなど） --add-port=53/tcp --permanent
■動的に反映する
firewall-cmd --reload
■全ゾーンの設定値の確認
firewall-cmd --list-all-zones
・iptablesの場合
■iptablesの編集
vi /etc/sysconfig/iptables
-A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
■iptablesサービスを再起動します。
systemctl restart iptables
または
service iptables restart
ログの確認
ログは以下などです。
/var/log/messages
/var/named/chroot/var/named/data/named.run
※named.confでの初期設定時
journalctl -r
リアルタイムのパケットを見る時 ※相応の負荷がかかります。
tcpdump -X port 53
オープンリゾルバになっていないかのチェック
1つ目のリンク先のwgetでの確認方法を実施しました。
[root@dti-vps-srv94]# wget -qO - http://www.openresolver.jp/cli/check.html
Configured DNS server: [NOT open] 202.216.224.10(nsc0-06.dti.ad.jp)
Source IP address: [NOT open] 27.120.*.*(v-27-120-*-*.ub-freebit.net)
1行目はresolv.confでの（負荷分散後）DNSサーバ、
2行目は自サーバ（wgetを実行したサーバ）の結果です。
インターネット側からの名前解決確認
自宅からnslookupで確認しました。
example.comのAレコード、MXレコード、NSレコードを正しく回答出来ました。
また、再帰検索出来ないことも確認しました。
ネームサーバ変更
以下の2点が必要です。
・作成したDNSサーバのホスト名とIPアドレスを、レジストリに申請
・WHOIS情報内のネームサーバ項の変更
さくらインターネットの場合
自分で作成したDNSサーバをレジストリに申請したい旨を
さくらのサポートにメールします。
サポートから以下の書式での提出を依頼されるため、記載し返信します。
WHOIS情報のNameServer項の変更もこの申請のみで、さくらのサポート
が同時に行ってくれます。
会員ID ：
ご契約者名 ：
ネームサーバホスト名 ：
ネームサーバIPアドレス ：
ネームサーバ運営のためレジストリへの申請依頼
1日待つと以下のメールを受信しました。
ご依頼に基づき、ホスト「**.**.com」の登録が完了しました
ことをご報告いたします。
WHOIS上に反映されますまで、1日程度お待ちください。
その後、数日間待って結局WHOISのネームサーバ項を
以下のWHOIS情報画面から自分で変更しました。
ムームードメインの場合
ネームサーバを登録します。
ムームードメインの「コントロールパネル」→「ドメイン一覧から該当のドメインを選択」
→「ネームサーバ設定変更」→「取得したドメインでネームサーバを登録する場合は
こちらをご利用ください。」をクリックします。
ネームサーバのホスト名とIPアドレスを入力します。
「取得したドメインで使用する 上級者向け」項目で、ネームサーバ1を設定します。
※orgの場合はネームサーバ2の入力も必要です。
これがWHOIS情報のName Server項に載ります。
（補足）ラウンドロビンについて
正引き（Aレコード）のラウンドロビン
ゾーンファイルにAレコードを複数記載するとラウンドロビン（順繰り分散）できます。
実際のDNSの挙動では、ゾーン（各レコード）のTTLに依りますね。
試しにゾーンファイルの1行目に$TTL 1（レコードの生存時間は1秒）とし、パソコン
（リゾルバ）のコマンドプロンプトでipconfig /flushdnsでDNSキャッシュを
クリア後に「ping hikaku-server.com」を複数回実行すると、2つのIPアドレスへ
アクセスしに行きました。
nslookupで直接権威サーバへアクセスすると、ラウンドロビンされることが確認できました。
DNSキャッシュに1.1.1.1から載った場合。
※DNSサーバ内のゾーンファイルのTTLは1秒だと
キャッシュからすぐ消えるので35秒に変更しています。
DNSキャッシュに27.120.*.*から載った場合
逆引き（PTRレコード）のラウンドロビン
逆引きについては、インターネット上の各DNSサーバ管理者が設定してくれていると
システム運用者がログを見る時に楽ですね。
ファイアウォールやURLフィルタリングサーバで、クライアントからのアクセス先一覧とか
統計を見る時に、アクセス先ランキング1位「1.1.1.1」と表示されているよりも
「yahoo.co.jp」と表示されている方が良いですね。
逆引きを設定する主な理由は、システム管理のため（通信先のスパムメール対策
サーバでの逆引き可否チェック用など）になるかと思います。
また、逆引きの複数記載については、まず実施しているサーバを見たことがありません。
基本的にはIPアドレスに対して設定する逆引き（PTRレコード）は1つです。
※複数の設定自体は可能です。
試しに逆引き（PTRレコード）を複数記載してみました。
例ですので、上位DNSサーバとの連携や再帰検索で辿ることは出来ません。
こちらもTTLを1秒にしました。
普通にAレコードの時と同様の動作、ラウンドロビンされました。