DNSSECを設定しよう
「DNSSEC」という技術があります。
DNSサーバのセキュリティの一環で、ネームサーバのデータを詐称する攻撃があります。
攻撃手法：DNSキャッシュポイズニング
・カミンスキー型攻撃
・DNS水責め攻撃
・SAD DNS
世間的に知名度が低いサイトは、詐称の片棒を担がされる可能性が高いと思っています。
「低いから大丈夫」という安心感は捨てて、ネット民全員が安全な電脳世界を
維持しくように、各自ができる事を協力していければと思います。
DNSSECが無事に運営を開始しました(2023-10-02)
[[[ DNSSECとは ]]]
厳密かつ正確には自信が無いので、ザックリ書くと
【自分の繋がっているDNS上の上位に、自ドメインを証明してもらう】
という事と理解しています。
. (ドット。ルートです)
|
+-------+-------+-------+-------+-------+
.jp .com .net .kr .cu .nu
| |
+------+--------+--------+--------+ +--+------+
.co.jp .ne.jp .gr.jp .go.jp .ad.jp ??.nu usi.nu
|
+----+----+----+------
A社 B社 C社 D社
|
+----+----+----
dns www smtp
A社のwwwサーバの名前解決は、A社のDNSサーバによって情報が提供されます。
このA社のDNSの情報が本当に正しい事を「.co.jp」を管理しているサーバが証明します。
更に、この「.co.jp」は「.jp」が証明します。
更に、この「.jp」は「.(ルート)」が証明します。(ここはちょっとハテナですが)
【nuドメインを追記】
トップドメインの次に「usi.nu」が来ます。
これって結構、シンプルで応答が早い DNSSEC が構築できています。
[[[ DSとRRの関係 信頼は大事 ]]]
名前解決をしたときに最初に問い合わせたサーバから「DSレコード」をもらいます。
ここからの動きは私の印象として「わらしべ長者」のように進んでいきます。
流れをファンタジー風に書いてみます。
1:NU国に属する「usi領」へ手紙を出す。
各国々は領地の門に鍵がかかっています。
NU国のusi領には情報を流す「web」。郵便をやり取りする「mail」という別々の門があります。
今回は「mail」門にお手紙を配送します。
それでは、郵便屋さん視点でお話を進めていきましょう。
2:NU国のusi領に行くためにお役所（named)で手続きをしましょう。
郵便：「こんにちは。NU国のusi領に行くので手続きをお願いします。」
担当：「はいはい。パスポートを持っていますか？」
郵便：「はい持っていますよ。」
担当：「わかりました。DNSSEC対応でやりますね。えっとどこだったかな。小さくて頻度が少ないからなぁ。無いなぁ。奥からとってきます。少しお待ちください」
郵便：「え？usi領って本当にあるのかな？」
担当：「お待たせしました。一番上のトップドメインまで問い合わせたら出てきましたよ。こちらが入国審査書です。パスポートを出してください。これがDSレコードです（スタンプ ポン！）。
郵便：「よかった。詐欺領かと思いましたよ。ありがとうございました。」
担当：「そうですね。最近はいろんな方法で騙そうとしてくる迷惑なところ(URL)も増えて困っています。みんな入国審査書を使ってくれると助かるのですが。
この間も、パスポート無だったのでそこの黒板に書いてある場所を鵜呑みにして騙された人もいますからね。気を付けてほしいものです。」
郵便：「では、書類を書いてきますね。」
A:ksk公開鍵の確認
郵便：「最初は、これがusi領かどうかの確認ですね。押してもらった DSレコード で ksk公開鍵 を計算して比べると・・・あれ？ちがうぞ？
すみません。計算が合わないのですがここはusi領ですか？」
担当：「あら。間違えちゃいましたね。これはusi領ではなくuma領ですね。こうやって似せてきて、他領の情報を得ようとする輩が増えちゃって。」
郵便：「おいおい、危ないなぁ。」
担当：「もう一度とってきますね。」・・ wait ・・「お待たせしました。usi領の書類です。情報を更新したらちゃんと出てきましたよ」
パスポートも修正しますね。（スタンプ ポン！）
郵便：「ありがとうございます。では改めて、書類を書いてきますね。」
A:ksk公開鍵の確認
郵便:「入国審査書の ksk公開鍵 とパスポートの DSレコード で計算すると、、、あっ解けた。このksk公開鍵は本物だな。」
B:zsk公開鍵を確認
郵便:「確認した ksk公開鍵を使って 入国審査書に書いてある zsk公開鍵 の署名(RRSIG)を検証しよう。。おっ大丈夫。ちゃんと合っているぞ。」
C:IPアドレスの確認
郵便：「えっと、入国審査書に記載のメール門のMXと署名のRRSIGは・・・これだな。この値にさっきのzsk公開鍵で検証すると。。。
ぴったしカンカン！(^_^)v これでここに書いてある名前と番地（IPアドレス）は信用できる。これで配達に行けるな。」
3:配達に出発
郵便：「行先の名前と番地の確認ができました。これが確認した入国審査書です。」
担当：「えーっと、はい。了解です。この入国審査書の通り行ってください。要件は郵便配達ですから「smtp」の出国許可書を出します。
2番ルータ‥は今数字が高いな。では、3番ルータ5番ポートから出てください。3つルータを超えると国外です。エクスチェンジで間違えないように！」
郵便：「ありがとうございました。行ってきます。」
こうして、郵便配達員はusi領の入国審査書から正しい名前と番地を得て、インターネットの中を進んでいくのでした。
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
今回はメールでしたが、webやclockでも同じように名前とIPアドレスを解決して、【本物】かどうかを確認してから、通信が始まります。
正しい手順で鍵をかける必要があるので、しっかりやっていきましょう！！
[[[ 設定方法 ]]]
この記述に関しては総務省の事業で実施していた「DNSSEC体験コース及び意見交換会」で学んだ内容を思い出して書いています。
https://www.nic.ad.jp/ja/topics/2023/20230728-02.html
・操作ユーザーは「root」で行いました。
・ターミナル環境で行っています。
・今回は以下の環境で記録しています。
OS :Almalinux9.2
SOFT:BIND 9.16.23 ネームサーバ
Chrony 4.3 タイムサーバ
/// 環境確認 ///
# cat /etc/almalinux-release
AlmaLinux release 9.2 (Turquoise Kodkod)
# uname -r
5.14.0-284.25.1.el9_2.x86_64
# named -v
BIND 9.16.23-RH (Extended Support Version)
# chronyc -v
chronyc (chrony) version 4.3
/// タイムサーバの設定 ///
DNSSECは時間が正確であることが必須となっています。
証明に有効期限がありますので、時間があっていないとTTLの終わり方がバラバラになり
名前解決ができない時間外が発生すると、インターネット内に混乱が生じます。
証明の基礎にもなりますので、設定をしておきます。
クライアントを設定しますが、ファイヤーウォールを開けると提供もできます。
タイムサーバは初期設定で設定されています。
インストール
# dnf install chrony
起動 停止 再起動
# systemctl start chronyd # systemctl stop chronyd # systemctl restart chronyd
OS起動時に起動するようにする
# systemctl enable chronyd
動作確認 (例) Active項目が「active」になっていれば動いています。
# systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: enabled)
Active: active (running) since Mon 2023-08-14 17:24:01 JST; 2 weeks 3 days ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Main PID: 18193 (chronyd)
Tasks: 1 (limit: 11136)
Memory: 2.2M
CPU: 3.773s
CGroup: /system.slice/chronyd.service
mq18193 /usr/sbin/chronyd -F 2
Notice: journal has been rotated since unit was started, output may be incomplete.
時間同期状況
# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- ntp1.mfeed.ad.jp 2 10 377 528 -676us[ -674us] +/- 72ms
^- ntp2.mfeed.ad.jp 2 10 377 247 -770us[ -762us] +/- 56ms
^- ntp3.mfeed.ad.jp 2 10 377 840 -2249us[-2250us] +/- 90ms
^* ntp-b2.nict.go.jp 1 8 377 203 +27us[ +34us] +/- 3871us
★ 「*」マークがついているものに現在同期しています。
★ マークがつくまでに少し時間がかかります(約3～5分)。起動直後は同期していません。
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
●自分でサーバを設定する
初期設定のサーバは日本国内にはないと思われます。時間を合わせるサーバはできれば近い方が良いので
日本国内に設定するのも良いと思います。
# vi /etc/chrony.conf
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (https://www.pool.ntp.org/join.html).
pool 2.almalinux.pool.ntp.org iburst
「pool」の行をコメントアウトして国内のタイムサーバに変更します。
ちなみに、後ろに「iburst」を付けると、OS起動時に合わせに行くサーバを指定しています。
国内サーバ
情報通信研究機構(NICT) ntp.nict.jp
インターネットマルチ ntp1.jst.mfeed.ad.jp
フィード株式会社 ntp2.jst.mfeed.ad.jp
ntp3.jst.mfeed.ad.jp
usi.nu clock.usi.nu (いつ止まるかわかりませんが、良ければ)
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (https://www.pool.ntp.org/join.html).
#pool 2.almalinux.pool.ntp.org iburst
server ntp.nict.jp iburst
server ntp1.jst.mfeed.ad.jp
server ntp2.jst.mfeed.ad.jp
server ntp3.jst.mfeed.ad.jp
server clock.usi.nu
サーバを複数設定するのは、1台サーバが停止しても時間は合わせ続ける必要があるので、
予備と考えても良いと思います。
/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*
/// DNSSECの設定 ///
※注意※ すでにネームサーバの設定が完了している前提で「dnssec」の設定を進めます。
・ディレクトリの確認
named.conf -> /etc/named.conf
zoneファイル -> /var/named
・Keysディレクトリの作成
# cd /var/named
# mkdir keys
# chown named.named keys
# chmod 644 keys
・ZSK(ゾーン署名鍵)を作成
dnssec-keygenコマンドを使います。
スイッチについて
-a 暗号のアルゴリズム
RSASHA1(デフォルト)
NSEC3RSASHA1
RSASHA256
RSASHA512
ECDSAP256SHA256
ECDSAP384SHA384
ED25519
ED448
-f KSK KSKを指定します。
-P 鍵を公開する日時 年月日時分秒 (例)2023/9/1 7:30:00 -> 20230901073000
-A 鍵をアクティブする日時 年月日時分秒 (例)2023/9/1 7:30:00 -> 20230901073000
-D 鍵を削除する日時 年月日時分秒 (例)2023/12/1 7:30:00 -> 20231201073000
-n タイプ ZONE(デフォルト) / HOST / ENTITY / USER / OTHER
※ 日時については、現時点の場合は「now」。現在から経過日指定は「+〇d」で可能。
[[[ 例 ]]]
暗号 = ECDSAP256SHA256
公開、アクティブ = 2023/8/23 06:11:31
削除 = 2023/9/23 06:11:31
ドメイン = usi.nu
【構文】dnssec-keygen -a 暗号 -P 公開日 -A アクティブ日 -D 削除日 -n zone ドメイン
# cd /var/named/keys
# dnssec-keygen -a ECDSAP256SHA256 -P 20230823061131 -A 20230823061131 -D 20230923061131 -n zone usi.nu
Generating key pair.
Kusi.nu.+013+49334
内容を確認します。
# cat Kusi.nu.+013+49334.key
; This is a zone-signing key, keyid 49334, for usi.nu.
; Created: 20230823061131 (Wed Aug 23 15:11:31 2023)
; Publish: 20230823061131 (Wed Aug 23 15:11:31 2023)
; Activate: 20230823061131 (Wed Aug 23 15:11:31 2023)
; Delete: 20230923061131 (Sat Sep 23 15:11:31 2023)
usi.nu. IN DNSKEY 256 3 13 rmtMoYMAfj3wRwqAc720SAhLLNj8AAWUxTA+d8wLxpI9Zqvbw4PCCuBx +5GMOUtDkzAlkIyeIo1Q9AiDBtnmAw==
・KSK(鍵署名鍵)を作成
dnssec-keygenコマンドを使います。
スイッチは同じです。
[[[ 例 ]]]
ZSKと同一条件です。
【構文】dnssec-keygen -f KSK -a 暗号 -P 公開日 -A アクティブ日 -D 削除日 -n zone ドメイン
# dnssec-keygen -f KSK -a ECDSAP256SHA256 -P 20230823061131 -A 20230823061131 -D 20230923061131 -n zone usi.nu
Generating key pair.
Kusi.nu.+013+41415
内容を確認します。
# cat Kusi.nu.+013+41415.key
; This is a key-signing key, keyid 41415, for usi.nu.
; Created: 20230823061131 (Wed Aug 23 15:11:31 2023)
; Publish: 20230823061131 (Wed Aug 23 15:11:31 2023)
; Activate: 20230823061131 (Wed Aug 23 15:11:31 2023)
; Delete: 20230923061131 (Wed Sep 23 15:11:31 2023)
usi.nu. IN DNSKEY 257 3 13 rrXj+WqKTfgPzpjasMYowvaVV5bPwIY99xSr3bD8O4Y9UtBB1iCl8jiA RGIRhWYo5BPmtzfeeAWp8N4qVr/E8w==
・named.confにKSKとZSKを読み込みます。
SOAのシリアルを1つ上げます。2023082301 -> 2023082302
named.conf の一番最後の行に include でKSKとZSKを読み込みます。
zoneファイル名: usinu.zone
# vi /var/named/usinu.zone
$TTL 86400 ; 1day
@ IN SOA dns.usi.nu hogehoge.usi.nu {
2023082302 ; serial
≀
中略
≀
$include "/var/named/keys/Kusi.nu.+013+41415.key" ; KSK
$include "/var/named/keys/Kusi.nu.+013+49334.key" ; ZSK
・zoneの文法確認
# named-checkzone usi.nu /var/named/usinu.zone
zone usi.nu/IN: loaded serial 2023082301
OK
「OK」が表示されれば大丈夫です。
・署名ファイルを作成します。
dnssec-signzone を使います。
スイッチについて
-H NSEC3を作るときに指定回数を繰り返します。
-3 暗号を作るときに与えられた16進数を使って生成する。
-s アクティブ日 本来は「年月日時分秒」で設定できるはずだが、うまくいかず「now」を使ってる。
-d 削除日 アクティブ日と同じで「年月日時分秒」が使えないので「+〇d」を使っている。
-o ゾーンを指定
-k KSKを指定(key,privateを外す)を指定する
[[[ 例 ]]]
ゾーン usi.nu
KSKファイル Kusi.nu.+013+41415.key
ZSKファイル Kusi.nu.+013+49334.key
ゾーンファイル /var/named/usinu.zone
削除日 365日
【構文】dnssec-signzone -H 回数 -3 16進数 -s now -d +〇d -o ゾーン -k KSKファイル ゾーンファイル ZSKファイル
# cd /var/named/keys
# dnssec-signzone -H 3 -3 2345 -s now -d +365d -o usi.nu -k Kusi.nu.+013+41415 /var/named/usinu.zone Kusi.nu.+013+49334
# dnssec-signzone -H 0 -3 '' -s now -e +365d -o usi.nu -k Kusi.nu.+013+41415 /var/named/usinu.zone Kusi.nu.+013+49334 (2024/11/05 変更 ※1)
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoke
ファイルは /var/named に出来上がります。
※1 RFC 9267 Sec.3.1. で「ソルト値を空に。繰返しをゼロ」という規定になったようです。
・署名されたゾーンの確認
正しく署名がされているか確認をします。
# dnssec-verify -o usi.nu /var/named/usi.zone.signed
Loading zone 'usi.nu' from file '/var/named/usi.zone.signed'
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
エラーが出なければOKです。
・named.conf に書き込む
署名ファイルを named.conf に読み込みます
現在の zoneファイルと署名ファイルを入れ替えます。
# vi /etc/named.conf
option {
≀
中略
≀
zone "usinu.zone" {
type master;
// file "usinu.zone";
file "usinu.zone.signed";
≀
後略
・named.confのチェック
# named-checkconf
#
問題が無ければ何も表示しません。
・ネームサーバの再読込
# rndc reload
server reload successful
・動作確認
ネームサーバの再読込をして動作してるか確認します。
【構文】dig @自サーバ ドメイン SOA +dnssec +multi
@自サーバは IPアドレス/localhost/サーバフルドメインのどれでも良い。
# dig @localhost usi.nu SOA +dnssec +multi
; <<>> DiG 9.16.23-RH <<>> @localhost usi.nu soa +dnssec +multi
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7670
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: d300ad401ba398840100000064e5ba594b5d198fe2207c75 (good)
;; QUESTION SECTION:
;usi.nu. IN SOA
;; ANSWER SECTION:
usi.nu. 86400 IN SOA dns.usi.nu. sysop.dns.usi.nu. (
2023082302 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
usi.nu. 86400 IN RRSIG SOA 13 2 86400 (
20230922064016 20230823064016 23039 usi.nu.
VUFZmCHuJpaMPdJ9cdDalIk7E2FLe0PRlC2ocL3RHz8A
1DPlbPykTiJ6VrGNqoaqthT4QHIe9fxgdmOzV+07VQ== )
;; Query time: 4 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Aug 23 16:50:49 JST 2023
;; MSG SIZE rcvd: 211
※ flags に aa があり、ANSWER がゼロ以上ならOKです。
・申請用のDS(Delegation Signer)を作成
ドメイン申請(もしくは代行社)に送るリソースレコード(RR)を作成します。
dnssec-dsfromkeyを使います。
スイッチについて
-1 SHA-1のアルゴリズム 「-a SHA1」の省略形
-2 SHA-256のアルゴリズム 「-a SHA256」の省略形
-a DSレコードを変換するためのアルゴリズム SHA1/SHA256/SHA384から選択
【構文】dnssec-dsfromkey アルゴリズム KSKファイル > ds-KSKファイルのKEYIDまで
# cd /var/named/keys
# dnssec-dsfromkey -2 Kusi.nu.+013+41415.key > ds-Kusi.nu.+013+41415
# ls -l
-rw-r--r-- 1 root root 89 8月 23 16:54 ds-Kusi.nu.+013+41415
署名鍵の確認
# cat ds-Kusi.nu.+013+41415
usi.nu. IN DS 9060 13 2 69D75D74198D52C791CEDE665F73639F60EE265793B8040B91E4E918F0D5B05B
申請に必要な場所は、以下の赤字の部分です。
usi.nu. IN DS 9060 13 2 69D75D74198D52C791CEDE665F73639F60EE265793B8040B91E4E918F0D5B05B
・DSレコード登録前チェック
JPRSが提供しているdnscheckというサイトできちんとできてるか確認ができます。
https://dnscheck.jp
入力のポイント
ドメイン ドメインを入力します。 usi.nu
選択 「ネームサーバー設定の事前チェック」を選びます。
ホスト名 1 ネームサーバの名前 dns.usi.nu
IPアドレス 1 ネームサーバのIPアドレス 133.18.168.21
証明鍵 1 9060 13 2 69D75D74198D52C791CEDE665F73639F60EE265793B8040B91E4E918F0D5B05B
「検証」ボタンを押してください。
エラーが無く重要度に「OK」があれば大丈夫です。赤い字はエラー表示です。
エラーの詳細はページの下の方にある「こちら」と書いてあるところをクリックして下さい。
*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/
/// DSレコードを申請する ///
DSレコードを自分のドメイン登録業者(もしくは代行社)を依頼しているところへ申請します。
ドメイン登録業者によっては申請方法はいろいろあるようです。
WEBで申し込みを受けるところやメールで受けるところです。また、DNSSECに対応していない所もあるようです。
ご自身のドメイン登録業者に確認して下さい。
nuドメインはサポートセンターにメールで報告すればOKでした。(英語でしたが)
ただ、「署名ファイルが、KSKかZSKかどちらですか」と聞かれました。
申請は「ksk」を送って申請できました。
・申請が終わって登録されたら確認します。
# dig @localhost usi.nu ds +dnssec +multi
・署名のつながりを確認するサイトで確認します。
https://dnsviz.net/
*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-*+-
セットアップは以上です。
この後は、署名期限が切れる前に各ファイルを更新していくのですが、
それはまた後日別項目で記載したいと思います。
KSK/ZSKの期限が切れてしまわないように期限内に次の更新ファイルをメールで送る必要があります。
今回、phpとcronで実現できました。
※RFC 5910準拠していれば、DSレコードの自動更新(EPP)が標準の様ですが、その環境が無い為、
確認はできていません。ご利用のプロバイダに確認して、手軽な方で実現してください。
このサイトでは、【メールで伝える】方法をお伝えしています。
＜＜考え方＞＞
KSKとZSKでは有効期限は【 KSK > ZSK 】にすることが一般的と思います。
今回のphpでは KSKを90日。ZSKを60日。期限を30日をデフォルトとして入れてあります。
これは2か月目から効果を発揮する方法です。
運用は cron で月1回（28 or 30 or 31)の更新としています。
つまり、kskもzskも期限が来る前に更新するという手法を取っています。
・今回は以下の有効期間とします
★ KSK = 90日
★ ZSK = 60日
★ 期間= 30日
前回 Previous
2026-04-15 2026-05-15 2026-06-15 2026-07-15 2026-08-15
KSK *----------------*---------------*---------------*
ZSK *----------------*---------------*
今回 now
KSK *---------------*---------------*---------------*
ZSK *---------------*---------------*
コメント
4月15日に作成して、次に5月15日に作成します。
これにより、5月15日に作成して KSK/ZSK が刷新されていますが、まだ作成したての鍵は
まだ、ドメインにも伝わっていません。ドメインに伝わっても各DNSまでに届くまでも時間がかかります。
なので、その空白期間を前回の鍵で補っておきます。期間が切れても、前回の鍵に期間に余裕があるので
DNSが切れることが無くなるはずです。
ただし、1か月目はきちんと30日で更新してください。まだ前回の鍵が無いのです。
2か月目からは大丈夫です。
※私もまだ1月目でテストできていません。現在は理論上の話となります。(2026-05-19現在)
・zoneファイルに KSKとZSK を2つずつ設定します。
zoneファイルの最後のインクルードを書き込みます。
; ========================================================
; DNSSEC Keys (Automatically managed by dnssec_insert_04.php)
; ========================================================
; --- NOW (Active Keys) ---
$include "/var/named/keys/Kusi.nu.+013+57936.key" ; KSK
$include "/var/named/keys/Kusi.nu.+013+42866.key" ; ZSK
; --- PREVIOUS (Grace period keys) ---
$include "/var/named/keys/Kusi.nu.+013+88236.key" ; KSK
$include "/var/named/keys/Kusi.nu.+013+41266.key" ; ZSK
; ========================================================
・更新は月に1回とします。（設定は毎月15日12時に実行）
0 12 15 * * /usr/bin/php /root/tool/dnssec_insert_04.php
使われる場合はreadme.txtを読んで準備・設定を行ってください。
尚、内容や成果物に関しては、すべて自己責任でお願いします。
※このツールは named.conf に view を使うと構成が破損します。
view利用者は使わないでください。
dnssec_insert_04.zip Ver0.4 2026-05-19
★★ おまけ ★★
DNSSEC対応とDNSSEC非対応のネームサーバについて
DNSSEC対応のネームサーバは、DSレコードを使って正しいサーバかどうかを確認できます。
よって、問い合わせをしてもDNSSEC対応の値をもらえます。
しかし、DNSSEC非対応のサーバは、ハッシュ値計算をしませんのでRRSIGなどの値を
もらっても検証も何もできません。そこで、非対応のネームサーバにはこれまでと
同じ方法でデータをもらうようです。
つまり、対応と非対応では「検証できるかできないか」の差が出てくるので
「だまされる、だまされない」の差が出てきます。
通信はどちらもできますが、信頼度は大きく違うように思います。
----------------------------------
2023-09-01 初版
2023-09-11 ２版 DSとRRの関係を「わらしべ長者」風で追加
2023-10-02 ３版 DNSSEC運営開始を追記
2024-11-05 ４版 dnssec-signzone の変更
dnssec_insert_03.zipに更新
2025-07-04 ５版 dnssec-signzone の誤字修正(-d +365d -> -e +365d)
2026-05-19 ６版 DSとRRの関係を「郵便局員」風に変更
dnssec_insert_04.zipに更新
Let's PC の Topに戻る
ホームページのTopに戻る