権限のあるBINDDNSサーバーでDNSSECを設定する方法

投稿日: 2022-04-20 2022-10-17
タグ: dns, Security

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マスター構成

内部に次の構成ディレクティブを追加してDNSSECを有効にします options{ }

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文字のランダムな文字列を出力します。

これにより、という名前の新しいファイルが作成されます example.com.zone.signed これには、各DNSレコードのRRSIGレコードが含まれています。この「署名された」ゾーンをロードするようにBINDに指示する必要があります。

nano /etc/bind/named.conf.local

変更 file 内のオプション zone { } セクション。

zone "example.com" IN {
    type master;
    file "example.com.zone.signed";
    allow-transfer { 2.2.2.2; };
    allow-update { none; };
};

このファイルを保存してバインドをリロードします

service bind9 reload

を使用してDNSKEYレコードを確認します dig 同じサーバー上。

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;

編集します file 内のオプション zone { } セクション。

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

出来上がり！それでおしまい。正常に動作していることを確認するために、を使用してDNSKEYにクエリを実行します。 dig 前のセクションで述べたように。

レジストラを使用してDSレコードを構成する

私たちが実行したとき dnssec-signzone 以外のコマンド .signed ゾーンファイル、という名前のファイル 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

の2番目のDSレコード dsset-example.com. ファイルにはダイジェストにスペースがありますが、フォームに入力するときは省略してください。次へをクリックし、完了をクリックしてレコードを保存します。

これらの変更が保存されるまでに数分かかります。 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

レコードを追加または削除するときはいつでも、 example.com.zone および.signedファイルではありません。このファイルはシリアル値のインクリメントも処理するため、ファイルを編集するたびにインクリメントする必要はありません。編集後、ドメイン名とゾーンファイル名をパラメータとして渡してスクリプトを実行します。

root@master# zonesigner.sh example.com example.com.zone

増分シリアルは転送および更新された場合にゾーンを保証するため、スレーブネームサーバーで何もする必要はありません。

ゾーンウォーキングからDNSSECセットアップを保護する

ゾーンウォーキングは、 NSEC （Next-Secure）レコードを照会することにより、ゾーンのすべてのリソースレコードを検索するために使用される手法です。 NSEC3 がリリースされ、ソルトを使用してこの情報を「ハッシュ」しました。思い出してください dnssec-signzone 指定したコマンド -3 オプションの後に、ランダムな文字列を生成するための別の複雑なコマンドが続きます。これは、以下を使用して見つけることができる塩です dig クエリ。

# dig NSEC3PARAM example.com. @master.example.com. +short
1 0 10 7CBAA916230368F2

これらすべてがゾーンウォーキングを困難にしますが、不可能ではありません。レインボーテーブルを使用していると決心したハッカーは、長い時間がかかりますが、ハッシュを壊す可能性があります。これを防ぐために、このソルトを定期的に再計算できます。これにより、ハッカーは古いソルトのハッシュを見つける前に新しいソルトがあるため、ハッカーの試みは無駄になります。以前に作成したzonesigner.shスクリプトを使用して、これを行うためのcronジョブを作成します。 cronjobを次のように実行する場合 root ファイルの所有権について心配する必要はありません。または、cronを配置するユーザーが、ゾーンディレクトリに対する書き込み権限と秘密鍵（ Kexample.com ）に対する読み取り権限を持っていることを確認してください。。*。プライベート）。

root@master:~# crontab -e

0       0       */3     *       *       /usr/sbin/zonesigner.sh example.com example.com.zone

これにより、3日ごとにゾーンに署名され、その結果、新しいソルトが生成されます。また、の出力を含む電子メールを受信します dnssec-signzone 指図。

提出者：http： //jesin.tk/ ”>ジェシンA

getdocs

13036