権限のあるBINDDNSサーバーでDNSSECを設定する方法
DNSSECについて
DNSがドメイン名をIPアドレスに解決するプロトコルであることは誰もが知っていますが、返されたIPアドレスの信頼性をどのようにして知ることができますか? 攻撃者がDNS応答を改ざんしたり、 DNSキャッシュをポイズニングしたりして、アドレスバーに正当なドメイン名が表示されている悪意のあるサイトにユーザーを誘導する可能性があります。 DNS Security Extensions(DNSSEC)は、DNS応答のデータ整合性を維持することを目的とした仕様です。 DNSSECは、PKI(公開鍵インフラストラクチャ)を使用して、ゾーンのすべてのDNSリソースレコード(A、MX、CNAMEなど)に署名します。 DNSSEC対応のDNSリゾルバー(GoogleパブリックDNSなど)は、パブリックDNSKEYレコードを使用してDNS応答(IPアドレスを含む)の信頼性を検証できるようになりました。
DNSSECリソースレコード
リソースレコード(RR)には、ドメインに関する特定の情報が含まれています。 一般的なものには、ドメインのIPアドレスを含むAレコード、IPv6情報を保持するAAAAレコード、およびドメインのメールサーバーを含むMXレコードがあります。 DNS RRの完全なリストは、ここにあります。
同様に、DNSSECにもいくつかのRRが必要です。
- DNSKEYリゾルバーが検証に使用する公開鍵を保持します。
- RRSIG RRごとに存在し、レコードのデジタル署名が含まれています。
- DS -委任署名者–このレコードはTLDのネームサーバーに存在します。 したがって、 example.com がドメイン名の場合、TLDは「com」であり、そのネームサーバーは
a.gtld-servers.net.
、b.gtld-servers.net.
からm.gtld-servers.net.
までです。 このレコードの目的は、DNSKEY自体の信頼性を検証することです。
セットアップ環境
ドメイン名: example.com
これを行うために実際の.COMドメインを使用しましたが、この記事ではexample.comに置き換えました。
マスターネームサーバー: IPアドレス: 1.1.1.1 ホスト名: master.example.com OS: Debian 7
スレーブネームサーバー: IPアドレス: 2.2.2.2 ホスト名: slave.example.com OS: CentOS
ファイルの場所と名前
BINDの構成ファイルとゾーンファイルの名前と場所は、使用するLinuxディストリビューションによって異なります。
Debian / Ubuntu
サービス名: bind9 メイン構成ファイル:/etc/bind/named.conf.options
ゾーン名ファイル:/etc/bind/named.conf.local
デフォルトのゾーンファイルの場所:/var/cache/bind/
CentOS / Fedora
サービス名:名前付きメイン構成およびゾーン名ファイル:/etc/named.conf
デフォルトのゾーンファイルの場所:/var/named/
bind-chroot
を使用している場合、これらは変更される可能性があります。 このチュートリアルでは、マスターNSにはDebianを使用し、スレーブNSにはCentOSを使用したので、ディストリビューションに応じて変更してください。
DNSSECマスター構成
options{ }
内に次の構成ディレクティブを追加して、DNSSECを有効にします
nano /etc/bind/named.conf.options
dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto;
これらは、一部のディストリビューションですでに追加されている可能性があります。 ゾーンファイルの場所に移動します。
cd /var/cache/bind
次のコマンドを使用して、ゾーン署名キー(ZSK)を作成します。
dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com
haveged をインストールした場合、このキーが生成されるまでに数秒しかかかりません。 そうしないと、非常に長い時間がかかります。 サンプル出力。
root@master:/var/cache/bind# dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com Generating key pair..................+++ .............+++ Kexample.com.+007+40400
次のコマンドを使用して、キー署名キー(KSK)を作成します。
dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.com
サンプル出力。
root@master:/var/cache/bind# dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.com Generating key pair......................++ .............................................................................................................................................................................................................++ Kexample.com.+007+62910
これで、ディレクトリには4つのキー(ZSKとKSKのプライベート/パブリックペア)が含まれるようになります。 DNSKEYレコードを含む公開キーをゾーンファイルに追加する必要があります。 次のfor
ループはこれを行います。
for key in `ls Kexample.com*.key` do echo "\$INCLUDE $key">> example.com.zone done
dnssec-signzone
コマンドでゾーンに署名します。
dnssec-signzone -3 <salt> -A -N INCREMENT -o <zonename> -t <zonefilename>
塩をランダムなものに置き換えます。 これが出力の例です。
root@master:/var/cache/bind# dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N INCREMENT -o example.com -t example.com.zone Verifying the zone using the following algorithms: NSEC3RSASHA1. Zone signing complete: Algorithm: NSEC3RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked example.com.zone.signed Signatures generated: 14 Signatures retained: 0 Signatures dropped: 0 Signatures successfully verified: 0 Signatures unsuccessfully verified: 0 Signing time in seconds: 0.046 Signatures per second: 298.310 Runtime in seconds: 0.056
「ソルト」として16文字の文字列を入力する必要があります。 次のコマンド
head -c 1000 /dev/random | sha1sum | cut -b 1-16
ソルトとして使用される16文字のランダムな文字列を出力します。
これにより、各DNSレコードのRRSIGレコードを含むexample.com.zone.signed
という名前の新しいファイルが作成されます。 この「署名された」ゾーンをロードするようにBINDに指示する必要があります。
nano /etc/bind/named.conf.local
zone { }
セクション内のfile
オプションを変更します。
zone "example.com" IN { type master; file "example.com.zone.signed"; allow-transfer { 2.2.2.2; }; allow-update { none; }; };
このファイルを保存してバインドをリロードします
service bind9 reload
同じサーバーでdig
を使用してDNSKEYレコードを確認してください。
dig DNSKEY example.com. @localhost +multiline
サンプル出力
root@master:/var/cache/bind# dig DNSKEY example.com. @localhost +multiline ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> DNSKEY example.com. @localhost +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43986 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;example.com. IN DNSKEY ;; ANSWER SECTION: example.com. 86400 IN DNSKEY 256 3 7 ( AwEAActPMYurNEyhUgHjPctbLCI1VuSj3xcjI8QFTpdM 8k3cYrfwB/WlNKjnnjt98nPmHv6frnuvs2LKIvvGzz++ kVwVc8uMLVyLOxVeKhygDurFQpLNNdPumuc2MMRvV9me fPrdKWtEEtOxq6Pce3DW2qRLjyE1n1oEq44gixn6hjgo sG2FzV4fTQdxdYCzlYjsaZwy0Kww4HpIaozGNjoDQVI/ f3JtLpE1MYEb9DiUVMjkwVR5yH2UhJwZH6VVvDOZg6u6 YPOSUDVvyofCGcICLqUOG+qITYVucyIWgZtHZUb49dpG aJTAdVKlOTbYV9sbmHNuMuGt+1/rc+StsjTPTHU= ) ; key id = 40400 example.com. 86400 IN DNSKEY 257 3 7 ( AwEAAa2BE0dAvMs0pe2f+D6HaCyiFSHw47BA82YGs7Sj qSqH3MprNra9/4S0aV6SSqHM3iYZt5NRQNTNTRzkE18e 3j9AGV8JA+xbEow74n0eu33phoxq7rOpd/N1GpCrxUsG kK4PDkm+R0hhfufe1ZOSoiZUV7y8OVGFB+cmaVb7sYqB RxeWPi1Z6Fj1/5oKwB6Zqbs7s7pmxl/GcjTvdQkMFtOQ AFGqaaSxVrisjq7H3nUj4hJIJ+SStZ59qfW3rO7+Eqgo 1aDYaz+jFHZ+nTc/os4Z51eMWsZPYRnPRJG2EjJmkBrJ huZ9x0qnjEjUPAcUgMVqTo3hkRv0D24I10LAVQLETuw/ QOuWMG1VjybzLbXi5YScwcBDAgtEpsQA9o7u6VC00DGh +2+4RmgrQ7mQ5A9MwhglVPaNXKuI6sEGlWripgTwm425 JFv2tGHROS55Hxx06A416MtxBpSEaPMYUs6jSIyf9cjB BMV24OjkCxdz29zi+OyUyHwirW51BFSaOQuzaRiOsovM NSEgKWLwzwsQ5cVJBEMw89c2V0sHa4yuI5rr79msRgZT KCD7wa1Hyp7s/r+ylHhjpqrZwViOPU7tAGZ3IkkJ2SMI e/h+FGiwXXhr769EHbVE/PqvdbpcsgsDqFu0K2oqY70u SxnsLB8uVKYlzjG+UIoQzefBluQl ) ; key id = 62910 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Nov 27 18:18:30 2013 ;; MSG SIZE rcvd: 839
RRSIGレコードの存在を確認してください。
dig A example.com. @localhost +noadditional +dnssec +multiline ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> A example.com. @localhost +noadditional +dnssec +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32902 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86400 IN A 93.184.216.119 example.com. 86400 IN RRSIG A 7 2 86400 20131227171405 ( 20131127171405 40400 example.com. JCoL8L7As1a8CXnx1W62O94eQl6zvVQ3prtNK7BWIW9O lir/4V+a6c+0tbt4z4lhgmb0sb+qdvqRnlI7CydaSZDb hlrJA93fHqFqNXw084YD1gWC+M8m3ewbobiZgBUh5W66 1hsVjWZGvvQL+HmobuSvsF8WBMAFgJgYLg0YzBAvwHIk 886be6vbNeAltvPl9I+tjllXkMK5dReMH40ulgKo+Cwb xNQ+RfHhCQIwKgyvL1JGuHB125rdEQEVnMy26bDcC9R+ qJNYj751CEUZxEEGI9cZkD44oHwDvPgF16hpNZGUdo8P GtuH4JwP3hDIpNtGTsQrFWYWL5pUuuQRwA== ) ;; AUTHORITY SECTION: example.com. 86400 IN NS master.example.com. example.com. 86400 IN NS slave.example.com. example.com. 86400 IN RRSIG NS 7 2 86400 20131227171405 ( 20131127171405 40400 example.com. hEGzNvKnc3sXkiQKo9/+ylU5WSFWudbUc3PAZvFMjyRA j7dzcVwM5oArK5eXJ8/77CxL3rfwGvi4LJzPQjw2xvDI oVKei2GJNYekU38XUwzSMrA9hnkremX/KoT4Wd0K1NPy giaBgyyGR+PT3jIP95Ud6J0YS3+zg60Zmr9iQPBifH3p QrvvY3OjXWYL1FKBK9+rJcwzlsSslbmj8ndL1OBKPEX3 psSwneMAE4PqSgbcWtGlzySdmJLKqbI1oB+d3I3bVWRJ 4F6CpIRRCb53pqLvxWQw/NXyVefNTX8CwOb/uanCCMH8 wTYkCS3APl/hu20Y4R5f6xyt8JZx3zkZEQ== ) ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Nov 28 00:01:06 2013 ;; MSG SIZE rcvd: 1335
マスターサーバーの構成が完了しました。
DNSSECスレーブ構成
スレーブサーバーでは、DNSSECを有効にし、ゾーンファイルの場所を変更するだけで済みます。 BINDのメイン設定ファイルを編集します。
nano /etc/named.conf
これらの行が存在しない場合は、options { }
セクション内に配置します。
dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto;
zone { }
セクション内のfile
オプションを編集します。
zone "example.com" IN { type slave; file "example.com.zone.signed"; masters { 1.1.1.1; }; allow-notify { 1.1.1.1; }; };
BINDサービスをリロードします。
service named reload
新しい.signed
ゾーンファイルがあるかどうかを確認します。
[root@slave ~]# ls -l /var/named/slaves/ total 16 -rw-r--r-- 1 named named 472 Nov 27 17:25 example.com.zone -rw-r--r-- 1 named named 9180 Nov 27 18:29 example.com.zone.signed
出来上がり! それでおしまい。 正常に動作していることを確認するために、前のセクションで説明したように、dig
を使用してDNSKEYにクエリを実行します。
レジストラを使用してDSレコードを構成する
.signed
ゾーンファイルとは別にdnssec-signzone
コマンドを実行すると、dsset-example.com
という名前のファイルも作成されました。これにはDSレコードが含まれています。
root@master:/var/cache/bind# cat dsset-example.com. example.com. IN DS 62910 7 1 1D6AC75083F3CEC31861993E325E0EEC7E97D1DD example.com. IN DS 62910 7 2 198303E265A856DE8FE6330EDB5AA76F3537C10783151AEF3577859F FFC3F59D
これらは、ドメインレジストラのコントロールパネルに入力する必要があります。 以下のスクリーンショットは、GoDaddyの手順を示しています。
ドメインレジストラのコントロールパネルにログインし、ドメインを選択して、DSレコードを管理するオプションを選択します。 GoDaddyのコントロールパネルは次のようになります。
dsset-example.com.
ファイルのデータの内訳は次のとおりです。
DSレコード1:
キータグ: 62910 アルゴリズム: 7 ダイジェストタイプ: 1 ダイジェスト: 1D6AC75083F3CEC31861993E325E0EEC7E97D1DD
DSレコード2:
キータグ: 62910 アルゴリズム: 7 ダイジェストタイプ: 2 ダイジェスト: 198303E265A856DE8FE6330EDB5AA76F3537C10783151AEF3577859FFFC3F59D
dsset-example.com.
ファイルの2番目のDSレコードにはダイジェストにスペースがありましたが、フォームに入力するときは省略してください。 次へをクリックし、完了をクリックしてレコードを保存します。
これらの変更が保存されるまでに数分かかります。 DSレコードが作成されているかどうかを確認するには、TLDのネームサーバーに問い合わせます。 TLDのネームサーバーを見つける代わりに、はるかに簡単なdig +trace
を実行できます。
root@master:~# dig +trace +noadditional DS example.com. @8.8.8.8 | grep DS ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> +trace +noadditional DS example.com. @8.8.8.8 example.com. 86400 IN DS 62910 7 2 198303E265A856DE8FE6330EDB5AA76F3537C10783151AEF3577859F FFC3F59D example.com. 86400 IN DS 62910 7 1 1D6AC75083F3CEC31861993E325E0EEC7E97D1DD
これが確認されると、次のオンラインサービスのいずれかを使用して、DNSSECが正常に機能しているかどうかを確認できます。
最初のツールは単純なツールですが、2番目のツールは物事を視覚的に表現します。 これが最初のツールのスクリーンショットです。
私がマークした線に注意してください。 最初のものはDSレコードのキータグ値(62910)に言及し、2番目のものはZSK(ゾーン署名キー)を保持するDNSKEYレコードのキーID (40400)に言及します。
ゾーンレコードの変更
レコードを追加または削除してゾーンを編集するたびに、ゾーンを機能させるために署名する必要があります。 そのため、毎回長いコマンドを入力する必要がないように、このためのスクリプトを作成します。
root@master# nano /usr/sbin/zonesigner.sh #!/bin/sh PDIR=`pwd` ZONEDIR="/var/cache/bind" #location of your zone files ZONE=$1 ZONEFILE=$2 DNSSERVICE="bind9" #On CentOS/Fedora replace this with "named" cd $ZONEDIR SERIAL=`/usr/sbin/named-checkzone $ZONE $ZONEFILE | egrep -ho '[0-9]{10}'` sed -i 's/'$SERIAL'/'$(($SERIAL+1))'/' $ZONEFILE /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N increment -o $1 -t $2 service $DNSSERVICE reload cd $PDIR
ファイルを保存して実行可能にします。
root@master# chmod +x /usr/sbin/zonesigner.sh
レコードを追加または削除する場合は、.signedファイルではなくexample.com.zone
およびを編集してください。 このファイルはシリアル値のインクリメントも処理するため、ファイルを編集するたびにインクリメントする必要はありません。 編集後、ドメイン名とゾーンファイル名をパラメータとして渡してスクリプトを実行します。
root@master# zonesigner.sh example.com example.com.zone
増分シリアルは転送および更新された場合にゾーンを保証するため、スレーブネームサーバーで何もする必要はありません。
ゾーンウォーキングからDNSSECセットアップを保護する
ゾーンウォーキングは、 NSEC (Next-Secure)レコードを照会することにより、ゾーンのすべてのリソースレコードを検索するために使用される手法です。 NSEC3 がリリースされ、ソルトを使用してこの情報を「ハッシュ」しました。 -3
オプションを指定したdnssec-signzone
コマンドに続いて、ランダムな文字列を生成するための別の複雑なコマンドを思い出してください。 これは、次のdig
クエリを使用して見つけることができるソルトです。
# dig NSEC3PARAM example.com. @master.example.com. +short 1 0 10 7CBAA916230368F2
これらすべてがゾーンウォーキングを困難にしますが、不可能ではありません。 レインボーテーブルを使用していると決心したハッカーは、長い時間がかかりますが、ハッシュを壊す可能性があります。 これを防ぐために、このソルトを定期的に再計算できます。これにより、ハッカーは古いソルトのハッシュを見つける前に新しいソルトがあるため、ハッカーの試みは無駄になります。 以前に作成したzonesigner.shスクリプトを使用して、これを行うcronジョブを作成します。 cronジョブをroot
として実行する場合、ファイルの所有権について心配する必要はありません。 または、cronを配置するユーザーが、ゾーンディレクトリに対する書き込み権限と秘密鍵( Kexample.com )に対する読み取り権限を持っていることを確認してください。 。*。プライベート)。
root@master:~# crontab -e 0 0 */3 * * /usr/sbin/zonesigner.sh example.com example.com.zone
これにより、3日ごとにゾーンに署名され、その結果、新しいソルトが生成されます。 dnssec-signzone
コマンドの出力を含む電子メールも受信します。