権威サーバの DNSSEC 対応

balaeniceps-rex DNS
2025.04.16

ローカル環境に構築した権威サーバを DNSSEC に対応させます。

※ここでは実際に設定、動作したものを掲載していますが、内容について保証するものではありません。流用される場合は各自の責任でお願いします。

構築する環境の要件等については 「ローカル環境にDNS問い合わせの仕組みを構築」 をご参照ください。

全体の構築作業は以下のとおりですが、今回は「② 権威サーバの DNSSEC 対応」を実施します。

① 権威サーバとキャッシュサーバの構築
② 権威サーバの DNSSEC 対応
③ test.com ゾーンの追加とゾーン転送の設定
④ test.com ゾーン転送の TSIG 対応（作成中）
⑤ test.com ゾーン転送の DNSSEC 対応（作成中）

今回の構築範囲は下図のとおりです。

dns-structure-physical-2

DNSSEC についてはインターネットに詳しい情報があると思いますので、ここでは簡単な説明にとどめます。

  • DNSSEC はクエリ応答の RR（リソースレコード）が本物であるかを確認する仕組みです。
  • 権威サーバは管理するゾーンの RR（実際にはRRSet）を秘密鍵で署名しています。クエリ要求に対し RRSet を応答する際、合わせて署名(RRSIG)も応答します。
  • クライアント（リゾルバ）は別途受け取った権威サーバの公開鍵を使用し、権威サーバから応答のあった RRSet、署名が本物であることを検証します。
  • 下位ドメインの公開鍵は上位ドメインが保証します。保証の連鎖をルートドメインまで遡ることで各ドメインの公開鍵が保証されます。

これから行う DNSSEC 設定の大まかな流れは以下のとおりです。

  1. 下位ドメインで、自身のゾーンデータ（RRSet）を秘密鍵で署名します。秘密鍵と対となる公開鍵は上位ドメインに預けます。 (*1)
  2. 上位ドメインでは、下位ドメインから預かった鍵も含め自身のゾーンデータを秘密鍵で署名します。秘密鍵と対となる公開鍵はさらに上位のドメインに預けます。
  3. これをルートドメインまで繰り返します。

*1 正確には、RRSet を署名する鍵（ZSK:Zone Signing Key）をさらに署名する鍵（KSK:Key Signing Key）が存在し、上位ドメインには KSK の公開鍵をハッシュ化したもの（DS:Delegation Signer）を預けます。ちなみに、ZSK と KSK はゾーンごとに用意します。

権威サーバの設定

鍵の作成

鍵（ZSK、KSK）を作成するためのディレクトリ用意します。

[root@auth ~]# mkdir -p /var/named/keys
[root@auth ~]# chown root.named /var/named/keys
[root@auth ~]# cd /var/named/keys
[root@auth keys]#

dnssec-keygen でゾーン数分の ZSK（Zone Signing Key）と KSK（Key Signing Key）を作成します。

参考：dnssec-keygen コマンドについて 
dnssec-keygen
鍵を生成し、*.key（公開鍵）と *.private（秘密鍵）に出力する。
標準出力には、キーファイルの名前が出力される。（下記手順ではリダイレクトし、名前をファイルに保存している。）

形式：
dnssec-keygen [オプション] ゾーン名

オプション：
-a : 暗号アルゴリズム
-b : キーサイズ（ビット数）
-f : 指定できるのは ksk のみ。KSKを生成する場合に指定する。
[root@auth keys]# dnssec-keygen -a RSASHA256 -b 1024 . > zsk-root
Generating key pair.....+++++ ........................+++++
[root@auth keys]# dnssec-keygen -a RSASHA256 -b 2048 -f ksk . > ksk-root
Generating key pair.................+++++ ...................................................................+++++
[root@auth keys]# dnssec-keygen -a RSASHA256 -b 1024 jp > zsk-jp
Generating key pair.................................+++++ ...............+++++
[root@auth keys]# dnssec-keygen -a RSASHA256 -b 2048 -f ksk jp > ksk-jp
Generating key pair..........................................................+++++ .............................................................................+++++
[root@auth keys]# dnssec-keygen -a RSASHA256 -b 1024 com > zsk-com
Generating key pair............................+++++ .+++++
[root@auth keys]# dnssec-keygen -a RSASHA256 -b 2048 -f ksk com > ksk-com
Generating key pair.............................................+++++ ..............+++++
[root@auth keys]# dnssec-keygen -a RSASHA256 -b 1024 test.co.jp > zsk-test.co.jp
Generating key pair..........+++++ .+++++
[root@auth keys]# dnssec-keygen -a RSASHA256 -b 2048 -f ksk test.co.jp > ksk-test.co.jp
Generating key pair.......................................................................+++++ ...........+++++
[root@auth keys]# ls -l
total 96
-rw-r--r--. 1 root root  583 Sep 28 17:29 K.+008+55205.key
-rw-------. 1 root root 1776 Sep 28 17:29 K.+008+55205.private
-rw-r--r--. 1 root root  409 Sep 28 17:28 K.+008+56359.key
-rw-------. 1 root root 1012 Sep 28 17:28 K.+008+56359.private
-rw-r--r--. 1 root root  588 Sep 28 17:30 Kcom.+008+09944.key
-rw-------. 1 root root 1776 Sep 28 17:30 Kcom.+008+09944.private
-rw-r--r--. 1 root root  415 Sep 28 17:29 Kcom.+008+44484.key
-rw-------. 1 root root 1012 Sep 28 17:29 Kcom.+008+44484.private
-rw-r--r--. 1 root root  587 Sep 28 17:29 Kjp.+008+26761.key
-rw-------. 1 root root 1776 Sep 28 17:29 Kjp.+008+26761.private
-rw-r--r--. 1 root root  413 Sep 28 17:29 Kjp.+008+45370.key
-rw-------. 1 root root 1012 Sep 28 17:29 Kjp.+008+45370.private
-rw-r--r--. 1 root root  429 Sep 28 17:30 Ktest.co.jp.+008+34246.key
-rw-------. 1 root root 1012 Sep 28 17:30 Ktest.co.jp.+008+34246.private
-rw-r--r--. 1 root root  603 Sep 28 17:30 Ktest.co.jp.+008+41707.key
-rw-------. 1 root root 1776 Sep 28 17:30 Ktest.co.jp.+008+41707.private
-rw-r--r--. 1 root root   16 Sep 28 17:30 ksk-com
-rw-r--r--. 1 root root   15 Sep 28 17:29 ksk-jp
-rw-r--r--. 1 root root   13 Sep 28 17:29 ksk-root
-rw-r--r--. 1 root root   23 Sep 28 17:30 ksk-test.co.jp
-rw-r--r--. 1 root root   16 Sep 28 17:29 zsk-com
-rw-r--r--. 1 root root   15 Sep 28 17:29 zsk-jp
-rw-r--r--. 1 root root   13 Sep 28 17:28 zsk-root
-rw-r--r--. 1 root root   23 Sep 28 17:30 zsk-test.co.jp
[root@auth keys]#

キーファイル名は直感的ではないので、分かりやすい名前の環境変数にキーファイル名を設定しておきます。

[root@auth keys]# RootZskName=`cat zsk-root`; RootKskName=`cat ksk-root`; echo $RootZskName $RootKskName
K.+008+56359 K.+008+55205
[root@auth keys]# JpZskName=`cat zsk-jp`; JpKskName=`cat ksk-jp`; echo $JpZskName $JpKskName
Kjp.+008+45370 Kjp.+008+26761
[root@auth keys]# ComZskName=`cat zsk-com`; ComKskName=`cat ksk-com`; echo $ComZskName $ComKskName
Kcom.+008+44484 Kcom.+008+09944
[root@auth keys]# TestCoJpZskName=`cat zsk-test.co.jp`; TestCoJpKskName=`cat ksk-test.co.jp`; echo $TestCoJpZskName $TestCoJpKskName
Ktest.co.jp.+008+34246 Ktest.co.jp.+008+41707

ゾーンファイルの署名では、ZSK と KSK の公開鍵も RRSet として一緒に署名する必要があるため、署名に先立ち、ゾーンファイルから公開鍵（ZSK, KSK）ファイルへの参照（INCLUDE）を設定しておきます。下記は INCLUDE の前準備として、ZSK と KSK の公開鍵を１つのファイルにまとめています。（まとめずにそれぞれの公開鍵ファイルを個別に INCLUDE しても問題ありません）

[root@auth keys]# cat ${RootZskName}.key ${RootKskName}.key > root.keys
[root@auth keys]# cat ${JpZskName}.key ${JpKskName}.key > jp.keys
[root@auth keys]# cat ${ComZskName}.key ${ComKskName}.key > com.keys
[root@auth keys]# cat ${TestCoJpZskName}.key ${TestCoJpKskName}.key > test.co.jp.keys
[root@auth keys]# chown root.named *.keys
[root@auth keys]# chmod 640 *.keys
[root@auth keys]# ls -l *.keys
-rw-r-----. 1 root named 1003 Oct  2 17:39 com.keys
-rw-r-----. 1 root named 1000 Oct  2 17:39 jp.keys
-rw-r-----. 1 root named  992 Oct  2 17:39 root.keys
-rw-r-----. 1 root named 1032 Oct  2 17:39 test.co.jp.keys
[root@auth keys]#

まとめた公開鍵ファイルをゾーンファイルに INCLUDE します。

[root@auth keys]# vi /var/named/root.zone
[root@auth keys]# grep INCLUDE /var/named/root.zone
$INCLUDE /var/named/keys/root.keys
[root@auth keys]# named-checkzone . /var/named/root.zone
…
OK
[root@auth keys]# vi /var/named/jp.zone
[root@auth keys]# grep INCLUDE /var/named/jp.zone
$INCLUDE /var/named/keys/jp.keys
[root@auth keys]# named-checkzone jp /var/named/jp.zone
…
OK
[root@auth keys]# vi /var/named/com.zone
[root@auth keys]# grep INCLUDE /var/named/com.zone
$INCLUDE /var/named/keys/com.keys
[root@auth keys]# named-checkzone com /var/named/com.zone
…
OK
[root@auth keys]# vi /var/named/test.co.jp.zone
[root@auth keys]# grep INCLUDE /var/named/test.co.jp.zone
$INCLUDE /var/named/keys/test.co.jp.keys
[root@auth keys]# named-checkzone test.co.jp /var/named/test.co.jp.zone
…
OK

ゾーンファイルの署名

dnssec-signzone でゾーンファイルを署名します。

参考：dnssec-signzone コマンドについて 
dnssec-signzone
指定されたゾーンファイルを読み取り、DNSSECに必要なRRを含めた新しいゾーンファイルを生成する。同時にDSファイルも出力する。
新しいゾーンファイルの名前は、「<指定されたゾーンファイル名>.signed」。
新しいゾーンファイルには、RRSIG（署名）、DNSKEY（ZSK,KSKの公開鍵）、NSEC3などのRRが追加される。
DSファイルの名前は、「dsset-<ドメイン名>」。
DSファイルには、KSKの公開鍵のハッシュを定義したDSレコードが格納される。

形式：
dnssec-signzone [オプション] ゾーンファイル名 ZSK名

オプション：
-H : NSEC3計算の繰り返し回数
-3 : NSEC3方式の選択とソルトの指定
-N : SOAのシリアル値
-k : KSK名
-o : ゾーン名

※ 本設定では、SOAのシリアル値（-Nで指定）に unixtime（エポックタイム）を指定している。
   ただし、署名前のゾーンファイルに登録されているシリアル値が unixtime よりも大きい場合、
   シリアル値の書き換えは行われなかった。

test.co.jp ドメインのゾーンファイルを署名します。同時に出力されたDSファイル（下記では dsset-test.co.jp.）は上位ドメインのゾーンファイル（下記では jp.zone）に INCLUDE します。

[root@auth keys]# dnssec-signzone -H 3 -3 123ABC -N unixtime -k ${TestCoJpKskName} -o test.co.jp /var/named/test.co.jp.zone ${TestCoJpZskName}
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
/var/named/test.co.jp.zone.signed
[root@auth keys]# vi /var/named/jp.zone
[root@auth keys]# grep INCLUDE /var/named/jp.zone
$INCLUDE /var/named/keys/jp.keys
$INCLUDE /var/named/keys/dsset-test.co.jp.
[root@auth keys]# named-checkzone jp /var/named/jp.zone
…
OK

jp ドメインのゾーンファイルを署名します。

[root@auth keys]# dnssec-signzone -H 3 -3 123ABC -N unixtime -k ${JpKskName} -o jp /var/named/jp.zone ${JpZskName}
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
/var/named/jp.zone.signed

com ドメインのゾーンファイルを署名します。

[root@auth keys]# dnssec-signzone -H 3 -3 123ABC -N unixtime -k ${ComKskName} -o com /var/named/com.zone ${ComZskName}
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
/var/named/com.zone.signed

jp と com の署名の際に出力されたDSファイル（dsset-jp. と dsset-com.）をルートのゾーンファイル（下記では root.zone）に INCLUDE します。

[root@auth keys]# vi /var/named/root.zone
[root@auth keys]# grep INCLUDE /var/named/root.zone
$INCLUDE /var/named/keys/root.keys
$INCLUDE /var/named/keys/dsset-jp.
$INCLUDE /var/named/keys/dsset-com.
[root@auth keys]# named-checkzone . /var/named/root.zone
…
OK

ルート(.)ドメインのゾーンファイルを署名します。

[root@auth keys]# dnssec-signzone -H 3 -3 123ABC -N unixtime -k ${RootKskName} -o . /var/named/root.zone ${RootZskName}
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
/var/named/root.zone.signed
参考：dnssec-signzone 実行時のエラーについて 
当初ゾーンファイルに $ORIGIN を指定していませんでしたが、dnssec-signzone 実行時に下記メッセージが出力されました。
dnssec-signzone: fatal: key K.+008+07731 not at origin

メッセージに従い、$ORIGIN を指定しましたが、dnssec-signzone 実行時に下記メッセージが出力されました。
dnssec-signzone: error: dns_master_load: root.zone:13: .: not at top of zone

dnssec-signzone の -o オプションでゾーン名を指定したところエラーが解消されました。

署名後のゾーンファイル（*.signed）の所有者と権限を書き換えます。

[root@auth keys]# chown root.named /var/named/*.signed
[root@auth keys]# chmod 640 /var/named/*.signed
[root@auth keys]# ls -l /var/named/*.signed
-rw-r-----. 1 root named  3504 Sep 29 10:04 /var/named/com.zone.signed
-rw-r-----. 1 root named  9936 Sep 29 10:03 /var/named/jp.zone.signed
-rw-r-----. 1 root named 12637 Sep 29 10:08 /var/named/root.zone.signed
-rw-r-----. 1 root named  4138 Sep 29 09:59 /var/named/test.co.jp.zone.signed

署名前後のゾーンファイルについては以下をご参照ください。（署名後のゾーンファイルは環境（鍵等）によって値が変わるため、あくまで参考情報としてご参照ください）

ドメイン署名前のゾーンファイル署名後のゾーンファイル
ルート(.)root.zoneroot.zone.signed
jpjp.zonejp.zone.signed
comcom.zonecom.zone.signed
test.co.jptest.co.jp.zonetest.co.jp.zone.signed

named.conf が参照するゾーンファイルを新しいゾーンファイル（*.signed）に変更します。
あわせて、dnssec-enable と dnssec-validation を yes にします。
（編集後の内容については named.conf をご参照ください ）

[root@auth keys]# vi /etc/named.conf
[root@auth keys]# grep -E "dnssec| file " /etc/named.conf
  dnssec-enable     yes;
  dnssec-validation yes;
//    file "named.ca";
//    file "root.zone";
    file "root.zone.signed";
//    file "jp.zone";
    file "jp.zone.signed";
//    file "com.zone";
    file "com.zone.signed";
//    file "test.co.jp.zone";
    file "test.co.jp.zone.signed";
[root@auth keys]# named-checkconf
[root@auth keys]#

named サービスを再起動します。

[root@auth keys]# systemctl restart named
[root@auth keys]#

権威サーバの疎通確認

各ドメインに疎通確認を行います。（→ NOERROR / do ビットON(=dnssec ok) ならば問題なし）

[root@auth keys]# dig @172.18.1.4 . soa +dnssec +multi +norec | grep -E 'status|flags|RRSIG'
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42669
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 10
; EDNS: version: 0, flags: do; udp: 1232
.                       604800 IN RRSIG SOA 8 0 604800 (
.                       604800 IN RRSIG NS 8 0 604800 (
x.root-servers.net.     604800 IN RRSIG A 8 3 604800 (
x.root-servers.net.     604800 IN RRSIG AAAA 8 3 604800 (
y.root-servers.net.     604800 IN RRSIG A 8 3 604800 (
[root@auth keys]# dig @172.18.1.8 jp soa +dnssec +multi +norec | grep -E 'status|flags|RRSIG'
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46583
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 10
; EDNS: version: 0, flags: do; udp: 1232
jp.                     604800 IN RRSIG SOA 8 1 604800 (
jp.                     604800 IN RRSIG NS 8 1 604800 (
x.dns.jp.               604800 IN RRSIG A 8 3 604800 (
x.dns.jp.               604800 IN RRSIG AAAA 8 3 604800 (
y.dns.jp.               604800 IN RRSIG A 8 3 604800 (
[root@auth keys]# dig @172.18.1.12 com soa +dnssec +multi +norec | grep -E 'status|flags|RRSIG'
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54305
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 1232
com.                    604800 IN RRSIG SOA 8 1 604800 (
com.                    604800 IN RRSIG NS 8 1 604800 (
[root@auth keys]# dig @172.18.1.16 test.co.jp soa +dnssec +multi +norec | grep -E 'status|flags|RRSIG'
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19649
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 1232
test.co.jp.             604800 IN RRSIG SOA 8 3 604800 (
test.co.jp.             604800 IN RRSIG NS 8 3 604800 (
参考：DS（Delegation Signer）を作成する別の方法について 
dnssec-dsfromkey でも DS（Delegation Signer）の作成が可能です。

dnssec-dsfromkey -2 xxxx.key > dsfile

-1 SHA-1のアルゴリズム 「-a SHA1」の省略形
-2 SHA-256のアルゴリズム 「-a SHA256」の省略形
-a DSレコードを変換するためのアルゴリズム SHA1/SHA256/SHA384 から選択

（例）
[root@auth keys]# dnssec-dsfromkey -2 ${JpKskName}.key > ds-jp
[root@auth keys]#

キャッシュサーバの設定

ややこしい話ですが、ゾーンの RRSet は ZSK の秘密鍵で署名され、その署名の正当性は ZSK の公開鍵で検証されます。
次に、ZSK の公開鍵は KSK の秘密鍵で署名され、その署名の正当性は KSK の公開鍵で検証されます。
KSK の公開鍵をハッシュ化したものは DS と呼ばれ、この DS は上位のドメインに預けられます。
リゾルバがクエリ要求の結果として、RRSet とその署名を受け取った場合、DS で ZSK 公開鍵の検証 → ZSK 公開鍵 で RRSet の署名の検証、を行い、RRSet が正当なものであることを確認します。

DNSSEC ではルートドメインを頂点とした保証の連鎖で各ドメインが所有する公開鍵の正当性が検証されますが、ルートドメインの場合、上位のドメインが存在しないため DS を預けることができず、ZSK 公開鍵の検証ができないことになります。
そのため、通常、DNS製品には ZSK 公開鍵を検証するためのトラストアンカー（ルート KSK の公開鍵）が製品内（コンフィグ等）に登録済みとなっています。BIND ではデフォルトで /etc/named.root.key にトラストアンカーが登録されています。

本キャッシュサーバでは、/etc/named.root.key への参照を無効化し、別途、ローカルに構築したのルートドメイン用のトラストアンカーを登録します。

キャッシュサーバのDNSSEC対応

キャッシュサーバに登録するトラストアンカー（ルート KSK 公開鍵）を確認するため、ローカルに構築したルートドメインにクエリ要求を送ます。公開鍵は DNSKEY として登録されており、256 は ZSK、257 は KSK を示します。

[root@cache ~]# dig @172.18.1.4 . dnskey | grep -w 257
.                       604800  IN      DNSKEY  257 3 8 AwEAAa/BxfdLccr6Y+qY3J+IC9KVykO9n7AcgLoH1DsbCcfJEsGcVVIk +5Abi9ZLy6bNJ4X483exmntr2yrYIsqIUaOR629Hwmf2XDycssKQH4Lf /OyWl95WVydNruwyU9/g5powiynTImxKLEBnzXsBPtkFhupA7F8+pk6Z M46EwNm7VhTu5dBnuLXvfWC5e+NvZn/l2IHSfsz3f0I8B7vtZXracvjx 1Sri8Me3k94dXmjfXeWXC74emIOI8fCyWtEKZuFKQ2o0FH3VJnS+ig+M oYVCPrp1JxzoL2Galul3JgAeck41Oqx9SxOTzUfy3B2FR1s3SQ6OFZSz BzWNCoTc2zM=

named.conf を編集し、上記で確認したトラストアンカーを登録し、デフォルトで登録されているトラストアンカーを無効化 (*1) します。(*2)
あわせて、dnssec-enable と dnssec-validation を yes に変更します。
（編集後の内容については named.conf をご参照ください ）

*1 具体的には「include “/etc/named.root.key”;」の行をコメント化します。

*2 named.root.key ファイル内ではトラストアンカーの登録を managed-keys ステートメントで行っています。今回、ローカルルート用のトラストアンカーの登録は trusted-keys ステートメントで行っています。managed-keys ステートメントで登録すると、ルートドメイン側で KSK が更新された場合、キャッシュサーバのトラストアンカーが自動更新されますが、trusted-keys ステートメントで登録すると自動更新は行われません。本環境ではルートドメイン側での KSK の更新は想定していないため、trusted-keys で登録しています。

[root@cache ~]# vi /etc/named.conf
[root@cache ~]# grep -E "dnssec|trusted-keys|named.root.key" /etc/named.conf -A1
  dnssec-enable     yes;
  dnssec-validation yes;

--
trusted-keys {
  "." 257 3 8 "AwEAAa/BxfdLccr6Y+qY3J+IC9KVykO9n7AcgLoH1DsbCcfJEsGcVVIk +5Abi9ZLy6bNJ4X483exmntr2yrYIsqIUaOR629Hwmf2XDycssKQH4Lf /OyWl95WVydNruwyU9/g5powiynTImxKLEBnzXsBPtkFhupA7F8+pk6Z M46EwNm7VhTu5dBnuLXvfWC5e+NvZn/l2IHSfsz3f0I8B7vtZXracvjx 1Sri8Me3k94dXmjfXeWXC74emIOI8fCyWtEKZuFKQ2o0FH3VJnS+ig+M oYVCPrp1JxzoL2Galul3JgAeck41Oqx9SxOTzUfy3B2FR1s3SQ6OFZSz BzWNCoTc2zM=";
--
//include "/etc/named.root.key";
[root@cache ~]#
[root@cache ~]# named-checkconf
[root@cache ~]#

named サービスを再起動します。

[root@cache ~]# systemctl restart named
[root@cache ~]#

キャッシュサーバの疎通確認

疎通確認します。（→ ad ビットON (Authentic Data = 署名が検証できた正しいデータ)であれば問題なし）

[root@cache ~]# dig @127.1 . soa +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59969
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 1105ccbae22ff9fdedfa7a6266fe035e308620e4e3d9e855 (good)
[root@cache ~]# dig @127.1 jp soa +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60843
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 80983201384a0aec2ea1eac966fe03728ff635964bc7f75b (good)
[root@cache ~]# dig @127.1 com soa +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37318
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 2471f221b2758ced75e1fae466fe0381f7f162d38a0ebce1 (good)
[root@cache ~]# dig @127.1 test.co.jp soa +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48107
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 9f4a07678aeca259df6037da66fe038d29815f2964788ce0 (good)
[root@cache ~]# dig @127.1 www.test.co.jp a +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54484
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 593971094c2d6dd79f4f508a66fe03994ee597a501faaafb (good)

タイトルとURLをコピーしました