はじめに
このハウツー記事では、CentOS7への安全なBIND9権限のあるDNSサーバーのインストールについて説明します
BINDとは何ですか？
BINDは、インターネット用のドメインネームシステム（DNS）プロトコルを実装するオープンソースソフトウェアです。これはこれらのプロトコルのリファレンス実装ですが、大量かつ高信頼性のアプリケーションでの使用に適した製品グレードのソフトウェアでもあります。
– ISC（インターネットシステムコンソーシアム）
構成手順の概要
- 基本的なサーバーの準備。
- BINDソフトウェアパッケージのインストール。
- BINDソフトウェアパッケージの構成。
- テストゾーン（ドメイン）の追加
- DNSサーバーのテスト
前提条件
このハウツー記事を始める前に、まずこれらの前提条件が満たされていることを確認する必要があります。
– CentOS 7サーバー–使用可能なサーバーがない場合は、VPSホスティングサービスページからサーバーを起動できます。
–お好みのテキストエディターがインストールされています–このチュートリアルではnanoを使用します。
。
1 –基本的なサーバーの準備
まず、rootユーザーアカウントとしてログインしていることを確認してください。
sudo su -
次に、コアオペレーティングシステムが完全に更新されていることを確認します。
yum update -y
システムが完全に更新されたので、ファイアウォールを更新します（デフォルトで有効 ）DNS（TCPポート53 / UDPポート53）がサーバーにアクセスできるようにします。
firewall-cmd --permanent --zone public --add-port 53/tcp firewall-cmd --permanent --zone public --add-port 53/udp firewall-cmd --reload
2 –BINDDNSソフトウェアパッケージのインストール
これで、BINDソフトウェアパッケージをサーバーにインストールする準備が整いました。
yum install -y bind bind-utils bind-chroot
- バインド ：Berkeley Internet Name Domain（BIND）DNS（Domain Name System）サーバー
- bind-utils ：DNSネームサーバーをクエリするためのユーティリティ
- bind-chroot ：ISCBINDDNSサーバーのchrootランタイム環境
必要なBINDソフトウェアパッケージがインストールされたので、BINDサービスを開始し、サーバーの再起動時に自動的に開始するように設定する準備が整いました。
systemctl start named systemctl enable named
。
3 –BINDDNSサーバーの構成
BIND DNSサーバーを起動すると、chrootパッケージはすべての構成ファイルを/var/named/chrootに自動的にマウントします。 サーバーのディレクトリ。 chroot jailでBIND（またはその他のプロセス）を実行すると、プロセスはjailの外部にあるファイルシステムのどの部分も見ることができなくなります。
参考までに、BIND構成で作業するベースディレクトリは/var/named/chrootです。
まず、これらの手順の残りの部分でそのディレクトリに移動しましょう。
cd /var/named/chroot
それでは、新しいサーバーのディレクトリと構成設定ファイルをいくつか作成し、所有権を設定しましょう。これらのディレクトリは、DNSサーバーの順方向および逆方向のゾーンファイルを保存するために使用されます。
mkdir var/named/fwd-zones mkdir var/named/rev-zones chown -R named:named var/named/fwd-zones chown -R named:named var/named/rev-zones touch etc/zones.conf chown root:named etc/zones.conf
次に、etc/named.confを編集します 構成ファイル。各オプションがサーバーに対して何を行っているかを理解できるように、セットアップ全体を順を追って説明します。
nano etc/named.conf
初期インストール時のデフォルトの構成ファイルは次のとおりです（最終的なetc/named.confにジャンプする場合） 、以下で見つけることができます）：
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
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;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
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";
BINDで使用可能な構成設定とオプションは非常に広範囲です。この記事では、サーバーを信頼できるDNSサーバーとしてセットアップし、サーバーを再帰的なDNS増幅攻撃から保護するためのオプションについてのみ説明します。
これらすべてのオプションの詳細については、Zytrax.comの担当者をお勧めします。
リスニングオプション
変更する最初の構成オプションは、サーバーのリスニングオプションです。デフォルトでは、サーバーはローカルループバックアドレス（127.0.0.1）でのみリッスンするように設定されています。これを変更して、サーバー上のすべてのインターフェイスでリッスンするようにします。 options { }内の次の行を置き換えます 構成ファイルの句。
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
ACL（アクセス制御リスト）
次に、いくつかのACL（アクセス制御リスト）ルールを構成に追加します。これらのACLは、クエリルックアップオプションと再帰クエリオプションのセキュリティ設定を拡張するために使用されます。最初のルール（「許可されたクエリ」と呼びます）は、任意の送信元アドレスがDNSサーバーにクエリを実行できるようにするために使用されます。 2番目のルール（これを「allowed-recursion」と呼びます）は、再帰ルックアップをローカルホストアドレスのみに制限するために使用されます。
options { }のすぐ上に以下のACLポリシールールを追加します 条項。
// ACL - Allow queries from ANY source address
acl "allowed-queries" {
any;
};
// ACL - Allow recursion from LOCALHOST only.
acl "allowed-recursion" {
127.0.0.1;
::1;
};
options {
...
};
次に、allow-queryの構成値を変更します 作成したばかりの新しいACLを使用するステートメント変数。 allow-query ステートメントは、誰（つまり、ソースネットワーク）がDNSサーバーにクエリを実行できるかを定義します。 options { }内の次の行を置き換えます 構成ファイルの句。
allow-query { "allowed-queries"; }; 再帰の制限
次に、サーバーで再帰ルックアップ権限を保護する必要があります。再帰は、DNSサーバーが要求元のクライアントに代わって他のDNSサーバーにクエリを実行し、名前を完全に解決してから、応答をクライアントに送り返す手法です。攻撃者はこの手法を使用して、オープン再帰が有効になっているDNSサーバーが無意識のうちにDDoS（分散型サービス拒否）攻撃に参加するようにすることができます。したがって、ネットワーク内のDNSサーバーが再帰クエリを受信することを意図していない場合は、そのサーバーで再帰を無効にするか、許可されていないソースがこの手法を使用できないようにセキュリティで保護する必要があります。
recursion yes;
allow-recursion { "allowed-recursion"; };
次に、構成ファイルにincludeステートメントを追加します。このステートメントは、サーバーが応答するように構成される権限のあるゾーンデータ（ドメイン）を含めるために使用されます。 option { }の終わりの下に次の行を追加します 最後のincludeステートメントの直後の句。
include "/etc/zones.conf";
これで、etc/named.confの構成変更が完了しました。 構成ファイル。これで、変更を保存して終了できます。
。
新しいnamed.confファイル
レビューのために、etc/named.conf 構成ファイルは次のようになります。
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// ACL - Allow queries from ANY source address
acl "allowed-queries" {
any;
};
// ACL - Allow recursion from LOCALHOST only.
acl "allowed-recursion" {
127.0.0.1;
::1;
};
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
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 { "allowed-queries"; };
recursion yes;
allow-recursion { "allowed-recursion"; };
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
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";
include "/etc/zones.conf";
。
4 –最初のゾーン（ドメイン）の追加
次に、DNSサーバーが権限を持つ最初のゾーンを追加します。テストドメイン（ example.tld を使用します ）例としてこのステップの場合。
まず、ディレクトリvar/named/fwd-zonesに新しいファイルを作成します 以前に作成したものです。
touch var/named/fwd-zones/example.tld.zone; chown named:named var/named/fwd-zones/example.tld.zone;
次に、このドメインのゾーンレコードデータの例を追加します。作成したばかりの新しいファイルを編集し、ゾーンデータを構成ファイルに追加します。
nano var/named/fwd-zones/example.tld.zone
ゾーンデータ
; zone file for example.tld
$TTL 14400 ; 4 hours - default TTL for zone
$ORIGIN example.tld.
;; SOA Resource Record
@ IN SOA ns1.example.tld. hostmaster.example.tld. (
2015010100 ; se = serial number
12h ; ref = refresh
15m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
;; Name Servers
IN NS ns1.example.com.
ns1 IN A 192.0.2.3
;; Mail Exchange Resource Records
@ IN MX 10 mail.example.tld.
;; Web Server Resource Records
@ IN A 192.0.2.3
www IN CNAME @
;; FTP Server Resource Records
ftp IN A 192.0.2.3
必要な変更をすべて行ったら、保存して終了します。
次に、etc/zones.confを編集します。 作成したばかりの新しいドメインを含めるための構成ファイル。
nano etc/zones.conf
次に、以下のパラメーターを構成ファイルに追加します。
zone "example.tld" in {
type master;
file "fwd-zones/example.tld.zone";
allow-transfer { none; };
}; 完了したら、このファイルを保存して終了します。
これで、DNSサービスを再起動して、すべての新しい構成をロードする準備が整いました。
systemctl restart named
エラーなしですべてが正常に再起動した場合は、次の応答が返されます。
Stopping named: . [ OK ] Starting named: [ OK ]
。
5 –DNSサーバーのテスト
これで、新しいDNSサーバーの機能をテストする準備が整いました。まず、作成したばかりのゾーン（ドメイン）に対してDNSサーバーが応答していることを確認します。次のコマンドを実行します。
dig example.tld -t ANY @localhost
サーバーからの以下の同様の応答出力が表示されます。探すべき主要な応答値は;; ANSWER SECTION: 値。この出力により、サーバーが前の手順で入力したレコードデータを使用してリクエストに応答したことがわかります。
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2 <<>> example.tld -t ANY @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61421 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;example.tld. IN ANY ;; ANSWER SECTION: example.tld. 14400 IN SOA ns1.example.tld. hostmaster.example.tld. 2015010100 43200 900 1814400 10800 example.tld. 14400 IN NS ns1.example.tld. example.tld. 14400 IN MX 10 mail.example.tld. example.tld. 14400 IN A 192.0.2.3 ;; ADDITIONAL SECTION: ns1.example.tld. 14400 IN A 192.0.2.3 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: ;; MSG SIZE rcvd: 147
これから行う2番目のテストは、サーバーがローカルホストからの再帰的なルックアップに応答していることを確認することです。以下のコマンドを実行して、テストを開始します。
dig google.com -t ANY @localhost
サーバーが期待どおりにセットアップされている場合は、同様の再帰的な;; ANSWER SECTION: 応答。
;; ANSWER SECTION: google.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 4294967295 7200 1800 1209600 300 google.com. 600 IN MX 50 alt4.aspmx.l.google.com. google.com. 600 IN MX 40 alt3.aspmx.l.google.com. google.com. 600 IN MX 10 aspmx.l.google.com. google.com. 600 IN MX 20 alt1.aspmx.l.google.com. google.com. 600 IN MX 30 alt2.aspmx.l.google.com. google.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" google.com. 86400 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D google.com. 300 IN AAAA 2607:f8b0:4008:804::200e google.com. 300 IN A 216.58.219.78 google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. google.com. 172800 IN NS ns2.google.com. ;; AUTHORITY SECTION: google.com. 172800 IN NS ns4.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns2.google.com. ;; ADDITIONAL SECTION: ns2.google.com. 172800 IN A 216.239.34.10 ns1.google.com. 172800 IN A 216.239.32.10 ns4.google.com. 172800 IN A 216.239.38.10 ns3.google.com. 172800 IN A 216.239.36.10
これから行う最後のテストは、サーバーがないであることを検証することです。 DNS増幅攻撃にさらされています。 openresolver.comの人々は、digで使用できる簡単なテストを設定しました。 ：
dig +short test.openresolver.com TXT @1.2.3.4
(replace 1.2.3.4 with the IP address or domain name of the DNS server you are testing)
"open-resolver-detected"の応答 再帰が有効になっていることを示します。 この場合、応答がないのは良いことです 。
openresolver.comサイトには、この脆弱性のテストに使用できるブラウザベースのツールもあります。
パブリックIPアドレスでテストすると、次の同様の応答が返されます。
成功したオープン再帰DNSリゾルバーテスト
おめでとうございます！
これで、権限のあるDNSサーバーが構成されて実行されました。読んでくれてありがとう！以下の関連記事のいくつかをチェックして、Atlantic.Netで信頼できるVPSホスティングソリューションを試していただきありがとうございます。