买了新光猫 XG-040G-TF , 所以写了一个 SuPassword 解密工具, 以备不时之需 .
2025年8月6日星期三
2025年8月1日星期五
Nginx Support for QUIC and HTTP/3
首先确保:
1 nginx 升级到 1.28.0 或者更新 .
2 防火墙放行 udp 443.
配置文件修改:
第一个 server 增加:
listen 443 quic reuseport;
listen [::]:443 quic reuseport;
ssl_protocols TLSv1.2 TLSv1.3;
http2 on;
http3 on;
add_header Alt-Svc 'h3=":443"; ma=86400';完整示例:
server {
listen 443 ssl ;
listen [::]:443 ssl ;
listen 443 quic reuseport;
listen [::]:443 quic reuseport;
server_name example.com;
ssl_certificate /path/fullchain.pem;
ssl_certificate_key /path/key.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
http2 on;
http3 on;
add_header Alt-Svc 'h3=":443"; ma=86400';
root /var/www/html;
index index.html index.htm index.php;
...
}如果有多个 server 的话不允许再次
listen 443 quic reuseport;否则会端口冲突。所以其余的 server 使用:
listen 443 quic;例如:
第二个 server 增加:
listen 443 quic;
listen [::]:443 quic;
ssl_protocols TLSv1.2 TLSv1.3;
http2 on;
http3 on;
add_header Alt-Svc 'h3=":443"; ma=86400';更多的 server 同上。
2025年7月19日星期六
BIND 9 CVE-2025-40777 漏洞分析与修复建议
最近关注到 BIND 9 中的一个较严重漏洞，编号为 CVE-2025-40777。
通过查阅文档，这个漏洞主要在递归服务器中出现，在特定配置下，遇到某些 CNAME 解析请求时，named 进程因断言失败崩溃，造成 DNS 服务不可用。
漏洞背景
漏洞出现在 BIND 的 serve-stale 功能上。serve-stale 作用是当上游服务器响应失败时，
允许使用过期缓存应答，从而保证解析的连续性和稳定性。
然而当配置文件中设置了 stale-answer-client-timeout 为 0，同时启用了 serve-stale，
遇到某些特殊的 CNAME 链解析请求时，named 进程会触发断言失败崩溃。
影响范围
- BIND 9.20.0 到 9.20.10
- BIND 9.21.0 到 9.21.9
- BIND 9.20.9-S1 到 BIND 9.20.10-S1
- 9.18.0之前和9.18.11-S1之前的版本官方没有测试
默认情况下，serve-stale 是关闭的，且 stale-answer-client-timeout 也不是 0，
因此如果没有手动设置，一般不会受到影响。
如果没有开启递归，纯权威服务器不会受此漏洞的影响。
漏洞等级与风险
- CVSS v3.1 基础分数：7.5（高危）
- 攻击者无需认证即可远程触发 DoS 攻击
- 攻击结果为 DNS 服务进程崩溃，导致解析中断
- 影响依赖该服务的系统和应用，可能造成网站访问失败、邮件中断、微服务不可用
漏洞原理简述
在处理递归查询时，serve-stale 允许返回过期的缓存答案以提高容错性。
但当 stale-answer-client-timeout 设置为 0，表示客户端不等待任何上游响应，
这与内部对 CNAME 链的处理逻辑发生冲突，最终导致断言失败。
临时解决办法
如果暂时无法升级，建议修改配置关闭此功能，避免崩溃：
options {
stale-answer-client-timeout off;
// 或者直接关闭 serve-stale
stale-answer-enable no;
};
改完后请重启 named 服务生效。
推荐修复方案
官方已经发布了 BIND 9.20.11 BIND 9.21.10 BIND 9.20.11-S1 修复了此漏洞，升级后该漏洞断言失败问题将被彻底解决。
如果自行编译源码，官方源码包地址：
https://downloads.isc.org/isc/bind9/9.20.11/bind-9.20.11.tar.xz
升级完成后用 named -v 命令确认版本信息。
漏洞来源
该漏洞最初由 ISC 官方披露，相关安全咨询也已提交至 GitHub Advisory 数据库，
详情见：https://github.com/advisories/GHSA-4x4c-8qp9-8ggh
2025年7月17日星期四
F7015TV3光猫固化Telnet
临时得到 Telnet 权限后，执行下面的命令来固化。
sendcmd 1 DB p TelnetCfg
sendcmd 1 DB set TelnetCfg 0 Lan_Enable 1
sendcmd 1 DB set TelnetCfg 0 TS_UName root
sendcmd 1 DB set TelnetCfg 0 TSLan_UName root
sendcmd 1 DB set TelnetCfg 0 TS_UPwd Zte521
sendcmd 1 DB set TelnetCfg 0 TSLan_UPwd Zte521
sendcmd 1 DB set TelnetCfg 0 Max_Con_Num 99
sendcmd 1 DB set TelnetCfg 0 ExitTime 999999
sendcmd 1 DB set TelnetCfg 0 InitSecLvl 3
sendcmd 1 DB set TelnetCfg 0 CloseServerTime 9999999
sendcmd 1 DB set TelnetCfg 0 Lan_EnableAfterOlt 1
sendcmd 1 DB save
2025年7月14日星期一
手动修改 dynamic zone
# 冻结 zone（变为静态 zone，允许手动修改文件）
rndc freeze example.com
# 手动修改
vim /etc/bind/zones/example.com.zone
# 重新加载
rndc reload example.com
# 解冻（恢复 DDNS）
rndc thaw example.com
2025年7月13日星期日
Replace OpenWrt DHCP and DNS Servers with Kea DHCP4 and BIND9
This guide explains how to replace the default OpenWrt DHCP and DNS servers with Kea DHCP4 and BIND9.
1. Install BIND and Kea DHCP4
opkg update
opkg install bind-server bind-check bind-dnssec bind-tools kea-dhcp42. Remove OpenWrt's default dnsmasq and odhcpd-ipv6only
opkg remove dnsmasq odhcpd-ipv6only
uci -q delete dhcp.@dnsmasq[0]
uci commit dhcp3. Install and Configure Kea DHCP4
Copy init script and configuration file:
cp ./kea-dhcp4/etc/init/kea-dhcp4 /etc/init/
cp ./kea-dhcp4/etc/kea/kea-dhcp4.conf /etc/kea/Edit the DHCP server configuration:
vim /etc/kea/kea-dhcp4.confStart and enable Kea DHCP4 service:
/etc/init.d/kea-dhcp4 start
/etc/init.d/kea-dhcp4 enable4. Configure BIND9 DNS Server
Edit the main configuration:
cp ./bind/etc/bind/named.conf /etc/bind/
vim /etc/bind/named.conf(Optional) Edit zone files:
vim /etc/bind/db.liuyu.dns
vim /etc/bind/db.192.168.15. Configure OpenWrt to use local BIND DNS Server
Set WAN DNS to localhost:
uci set network.wan.dns='127.0.0.1'
uci commit network6. Start and enable BIND service
/etc/init.d/named start
/etc/init.d/named enable7. Other useful commands
Restart services if needed:
service kea-dhcp4 restart
service named restartThis setup replaces the default dnsmasq with a more flexible and robust Kea DHCP4 and BIND9 combination.
GitHub Repository: https://github.com/liuyuf78fk/isc-openwrt
2025年7月6日星期日
2025年6月22日星期日
验证递归DNS 是否支持DNSSEC
UDP:
dig +dnssec +multi nic.cz A
dig +dnssec dnssec-failed.org A
------------------------------------------------------------------------------------
DoH:
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=nic.cz&type=A' --insecure
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=nic.cz&type=RRSIG' --insecure
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=dnssec-failed.org&type=A' --insecure
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=dnssec-failed.org&type=RRSIG' --insecure
上面示例中测试的是 cloudflare的 dns 是否支持dnssec，所以测试自己的服务器需要替换成自己的DoH地址。
--------------------------------------------------------------------------------------
如果本地的DNS解析器支持DNSSEC的话，会返回下面的预期数据。
nic.cz 会返回 :
AD:true 代表已验证数据
type:46 代表返回了RRSIG
type:1 代表返回了正确的 IP 地址。
dnssec-failed.org 会返回 :
AD:false 代表没有通过DNSSEC验证，因为是伪造的签名
Status:2 代表 SERVFAIL
Answer:缺失 没有返回 IP 地址的结果是预期的。
--------------------------------------------------------------------------------------
不是以上的预期数据的话,比如 dig +dnssec dnssec-failed.org A 结果依然返回了 IP 地址,没有返回SERVFAIL, 那就认为 DNSSEC 验证链路不完整。Ubuntu 24.04 导入自签证书到受信任的根证书颁发机构
1：
cp my.crt /usr/local/share/ca-certificates/
2:
sudo update-ca-certificates
3:
openssl s_client -connect ipaddr -servername your-domain
如果输出中显示:
Verify return code: 0 (ok)
就说明系统已经完全信任这个证书了。
2025年6月21日星期六
BIND 9.20.9 配置 DDNS 实现动态更新记录
主权威DNS：
vim /etc/bind/zones/example.com.zone# 增加下面 2 行
序列号记得加 1
# 使此 zone 增加的记录生效
$TTL 600 ; 10 minutes
home.example.com. A 1.2.3.4序列号记得加 1
# 使此 zone 增加的记录生效
rndc reload example.com# 生成 SHA512 keytsig-keygen -a HMAC-SHA512 ddnskey > /etc/bind/keys/ddnskey.key# 配置文件里载入 keyvim /etc/bind/named.conf.local # 包含刚刚的 key 文件
include "/etc/bind/keys/ddnskey.key";# 修改 zone 策略, 允许使用 key 动态更新zone "example.com" {
type master;
file "/etc/bind/zones/example.com.zone";
allow-transfer {
x.x.x.x;
};
also-notify {
x.x.x.x;
};
allow-update { key ddnskey; }; // 增加这一句,表示允许使用 ddnskey.key 动态更新
};# 使配置生效
rndc reconfig然后把 /etc/bind/keys/ddnskey .key 文件拷贝到没有固定IP的主机动态IP的主机：
# 测试更新 A记录 是否能成功
nsupdate -k ./ddnskey .key <<EOF
server ns1.f78fk.net
zone example.com
update delete home.example.com. A
update add home.example.com. 600 A 6.6.6.6
send
EOF# 验证dig home.example.com A 记录看到已经变成 6.6.6.6 了
全自动化:
git clone https://github.com/liuyuf78fk/F78FK-DDNS.gitcd F78FK-DDNS根据 README 去做 。
# 修改 auto_ddns_update.sh
# 修改 auto_ddns_update.sh
ZONE="zone 名,在本例中此值为 example.com"
FQDN="需要更新的完整域名 ( 本例中此值为 home.example.com. )"
KEY="ddnskey.key 的绝对路径"
TYPE="A 记录或者 AAAA 记录"
TTL="TTL 值，DDNS 一般设置为 600 也就是10分钟"
DDNS_SCRIPT="f78fk.ddns_update.sh 的路径"
GET_IP_SCRIPT="getip.sh 的路径"
LOG=true 或 false 调试期间设置为 true，测试稳定后设置为 false# 添加定时任务（每 15 分钟执行一次）
crontab -e添加以下内容（ 路径根据实际修改 ）：
*/15 * * * * /home/<your_username>/F78FK-DDNS/auto_ddns_update.sh之后系统会每隔15分钟检查IP如果有变化的话会自动更新 A记录 到 DNS 服务器。2025年6月19日星期四
BIND 9.20.9 配置 TSIG
主权威DNS
tsig-keygen sync-key# 加载新密钥
vim named.conf
key "sync-key" {
algorithm hmac-sha256;
secret "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=";
};# 指示服务器使用密钥
vim named.conf.local
# 指示从 DNS1 更新zone需要共享密钥
server x.x.x.1 {
keys { sync-key ;};
}; # 指示从 DNS2 更新zone需要共享密钥
server x.x.x.2 {
keys { sync-key ;};
}; zone "f78fk.net" {
type master; file "/etc/bind/zones/f78fk.net.zone";
allow-transfer {
x.x.x.1; //允许从 DNS1 更新zone
x.x.x.2; //允许从 DNS2 更新zone
};
also-notify {
x.x.x.1; //rndc reload后主动通知一次 DNS1 更新zone
x.x.x.2; //rndc reload后主动通知一次 DNS2 更新zone
};
};从权威DNS 1
# 加载新密钥
vim named.conf
vim named.conf
key "sync-key" {
algorithm hmac-sha256;
secret "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=";
};# 指示服务器使用密钥
vim named.conf.local
# 指定向主 DNS 更新 zone 时使用的共享密钥
server x.x.x.m {
keys { sync-key ;};
};zone "f78fk.net" {
type slave; masters {
x.x.x.m; // 主 DNS 的 IP 地址
};
file "/etc/bind/zones/f78fk.net.zone";
};从权威DNS 2
# 加载新密钥
vim named.conf
vim named.conf
key "sync-key" {
algorithm hmac-sha256;
secret "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY=";
};# 指示服务器使用密钥
vim named.conf.local
# 指定向主 DNS 更新 zone 时使用的共享密钥
server x.x.x.m {
keys { sync-key ;};
}; zone "f78fk.net" {
type slave; masters {
x.x.x.m; // 主 DNS 的 IP 地址
};
file "/etc/bind/zones/f78fk.net.zone";
};官网文档:
https://downloads.isc.org/isc/bind9/9.20.10/doc/arm/html/chapter7.html#generating-a-shared-key2025年6月12日星期四
2025年6月11日星期三
权威 DNS 启用 DNSSEC
BIND9 启用 DNSSEC
主DNS服务器上操作
# 创建key 目录
mkdir /etc/bind/keysvim named.conf
# 追加下面配置
# 定义了一个名为 default-policy 的 DNSSEC 策略：
# - 使用 ECDSA P-256 算法。
# - KSK 不轮换，便于长期固定部署。
# - ZSK 每 90 天轮换一次，提高安全性。
# 该策略可用于区域的自动密钥管理与签名。
keys {};
ksk lifetime unlimited algorithm ECDSAP256SHA256;
zsk lifetime 90d algorithm ECDSAP256SHA256;
};
# 指定 keys 路径
# 启用 DNSSEC 验证，并使用 DNS 根区域的默认信任锚
vim named.conf.options
options {
# 启动自动签名和自动生成密钥
vim named.conf.local
zone "f78fkdns.top" {
type master;
...
inline-signing yes; // 启用实时签名，避免维护单独的.signed文件
dnssec-policy "default-policy"; // 使用内置的默认DNSSEC策略（自动密钥生成/轮换/签名）
};
这样设置了就意味着BIND 将自动为该 zone 生成和维护 DNSSEC 签名记录（如 RRSIG/NSEC），并依据配置的 default-policy 策略自动管理密钥生命周期，包括 KSK/ZSK 的生成、激活、轮换和失效。
# 检查语法错误
named-checkconf
# 重新载入配置
rndc reconfig
# 检查密钥生成情况
ls etc/bind/keys -l
看到BIND成功生成了2对密钥。
继续确认下有没有自动生成签名版的 zone
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 23d176608b92e04d010000006848621828b663b0febe93a0 (good)
;; QUESTION SECTION:
;f78fkdns.top. IN SOA
;; ANSWER SECTION:
f78fkdns.top. 3600 IN SOA ns1.f78fkdns.top. admin.f78fk.com. 2025061006 3600 600 604800 3600
f78fkdns.top. 3600 IN RRSIG SOA 13 2 3600 20250624163155 20250610153155 64284 f78fkdns.top. 0hSIHd9Sa57evZn8AWUr4t4iRf5ikvKAbEg1+kt7lWGnE7V+JmiiIsiB 4vRm3AyMbMEXdMnu0YSKrgfZpYkzEg==
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Jun 11 01:49:28 JST 2025
;; MSG SIZE rcvd: 232
-----------------------------------------------------------------------------------------------
看到 RRSIG 记录和数字签名，说明 DNSSEC 已成功启用并开始对区域数据进行签名保护。
# 再看下当前zone的状态
-----------------------------------------------------------------------------------------------
name: f78fkdns.top
type: primary
files: /etc/bind/zones/f78fkdns.top.zone
serial: 2025061166
signed serial: 2025061166
nodes: 4
last loaded: Tue, 10 Jun 2025 16:46:15 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Tue, 10 Jun 2025 18:36:48 GMT
next resign node: f78fkdns.top/NS
next resign time: Thu, 19 Jun 2025 09:32:19 GMT
dynamic: no
reconfigurable via modzone: no
-----------------------------------------------------------------------------------------------
我们是使用 KSK 来计算生成 DS 记录：
/opt/bind-9.20.9/bin/dnssec/dnssec-dsfromkey ./Kf78fkdns.top.+013+42980.key
# 成功生成
f78fkdns.top. IN DS 42980 13 2 16DBE0D3003C2AFE68CF48E9BD301EE6001615D498BA8536008E538101D66A36
# 解释
42980 13 2 以及 一长串16进制
42980 代表 keyid
13 代表加密算法 (Algorithm) 是 ECDSAP256SHA256
2 代表 摘要类型(Digest Type) 是 SHA256
一长串16进制代表 摘要(Digest) ，其实就是DNSKEY公钥 做了SHA-256 得到的哈希。
我的域名注册在阿里云，登录控制台，添加DNSSEC设置，点击添加DS记录。
密钥标签(Key Tag) 填 (keyid） 42980
加密算法(Algorithm) 选 （13） ECDSA Curve P- 256 with SHA - 256
摘要类型(Digest Type) 选 （2） SHA-256
摘要(Digest) 填 (Digest) 16DBE0D300 ...
dig @ns1.f78fkdns.top f78fkdns.top DNSKEY
-----------------------------------------------------------------------------------------------
f78fkdns.top. 3600 IN DNSKEY 256 3 13 gHFpWZIpgjxyBZCv1h0iI000UriMOVhFLLiqn7V/ciqXfcPPMpx6nAX6 ZSG1ZUO7N85VqQyw7lH7q04F8A5Lfw==
f78fkdns.top. 3600 IN DNSKEY 257 3 13 zERhvxYmjqGElHUv40EDJ6dChvMqwm40A9BrM1df8Icx9trohkxiAwtX f4l+HUYksBHMuHUlvaUKQIZ6mz9S5Q==
-----------------------------------------------------------------------------------------------
能看到DNSKEY，无问题。
dig @ns2.f78fkdns.top f78fkdns.top DNSKEY
ssh 登录ns2和ns3，执行
继续验证：
首先使用 verisignlabs 验证 。
输入域名,f78fkdns.top 回车
返回了：
换 dnsviz.net 继续验证 ：
可以看到，从根域（.）到顶级域（.top），再到我的域名（f78fkdns.top），整条 DNSSEC 信任链已成功验证。DS、DNSKEY 以及各类 RRSIG 记录均匹配正确，三台权威服务器（ns1、ns2、ns3）返回一致的签名结果，NSEC 记录也已正确签名，未匹配记录的应答同样具备加密签名，从而确保“记录不存在”这一信息的真实性，说明 DNSSEC 配置已完整生效。
昨天买了新域名 538053.xyz 委任到了我的自建权威DNS上，同样方法开启了DNSKEY测试一下。
首先 verisignlabs 先来 ：
# 重启服务
systemctl restart named
# 查看日志
journalctl -u named -xe | tail -n 30
# 重新载入配置文件，识别新 zone
rndc reconfig
# 热加载所有 zone
rndc reload
# 热加载指定 zone
rndc reload f78fkdns.top
# 立即从主DNS同步
vim named.conf.options
options {
...
key-directory "/etc/bind/keys";
dnssec-validation auto;
...};
# 启动自动签名和自动生成密钥
vim named.conf.local
zone "f78fkdns.top" {
type master;
...
inline-signing yes; // 启用实时签名，避免维护单独的.signed文件
dnssec-policy "default-policy"; // 使用内置的默认DNSSEC策略（自动密钥生成/轮换/签名）
};
这样设置了就意味着BIND 将自动为该 zone 生成和维护 DNSSEC 签名记录（如 RRSIG/NSEC），并依据配置的 default-policy 策略自动管理密钥生命周期，包括 KSK/ZSK 的生成、激活、轮换和失效。
# 检查语法错误
named-checkconf
# 重新载入配置
rndc reconfig
# 检查密钥生成情况
ls etc/bind/keys -l
看到BIND成功生成了2对密钥。
继续确认下有没有自动生成签名版的 zone
ls /etc/bind/zones -l
f78fkdns.top.zone.signed
看到签名版的 zone 已经成功生成了。
dig @127.0.0.1 f78fkdns.top SOA +dnssec
-----------------------------------------------------------------------------------------------
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25100
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
f78fkdns.top.zone.signed
看到签名版的 zone 已经成功生成了。
签名验证
-----------------------------------------------------------------------------------------------
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25100
;; 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: 23d176608b92e04d010000006848621828b663b0febe93a0 (good)
;; QUESTION SECTION:
;f78fkdns.top. IN SOA
;; ANSWER SECTION:
f78fkdns.top. 3600 IN SOA ns1.f78fkdns.top. admin.f78fk.com. 2025061006 3600 600 604800 3600
f78fkdns.top. 3600 IN RRSIG SOA 13 2 3600 20250624163155 20250610153155 64284 f78fkdns.top. 0hSIHd9Sa57evZn8AWUr4t4iRf5ikvKAbEg1+kt7lWGnE7V+JmiiIsiB 4vRm3AyMbMEXdMnu0YSKrgfZpYkzEg==
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Jun 11 01:49:28 JST 2025
;; MSG SIZE rcvd: 232
-----------------------------------------------------------------------------------------------
看到 RRSIG 记录和数字签名，说明 DNSSEC 已成功启用并开始对区域数据进行签名保护。
# 再看下当前zone的状态
rndc zonestatus f78fkdns.top
-----------------------------------------------------------------------------------------------
name: f78fkdns.top
type: primary
files: /etc/bind/zones/f78fkdns.top.zone
serial: 2025061166
signed serial: 2025061166
nodes: 4
last loaded: Tue, 10 Jun 2025 16:46:15 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Tue, 10 Jun 2025 18:36:48 GMT
next resign node: f78fkdns.top/NS
next resign time: Thu, 19 Jun 2025 09:32:19 GMT
dynamic: no
reconfigurable via modzone: no
-----------------------------------------------------------------------------------------------
# 详解
secure: yes：DNSSEC 已经启用。
inline signing: yes：BIND 正在自动签名此 zone 。
key maintenance: automatic：使能了 dnssec-policy，BIND 会自动生成、滚动密钥。
先找到KSK（Key Signing Key）和 ZSK（Zone Signing Key）
cat Kf78fkdns.top.+013+42980.key
f78fkdns.top. 3600 IN DNSKEY 257 3 13
DNSKEY后面的 257 表示这个是 KSK
cat Kf78fkdns.top.+013+64284.key
f78fkdns.top. 3600 IN DNSKEY 256 3 13
DNSKEY后面的 256 表示是ZSK
secure: yes：DNSSEC 已经启用。
inline signing: yes：BIND 正在自动签名此 zone 。
key maintenance: automatic：使能了 dnssec-policy，BIND 会自动生成、滚动密钥。
生成 DS 记录
cat Kf78fkdns.top.+013+42980.key
f78fkdns.top. 3600 IN DNSKEY 257 3 13
DNSKEY后面的 257 表示这个是 KSK
cat Kf78fkdns.top.+013+64284.key
f78fkdns.top. 3600 IN DNSKEY 256 3 13
DNSKEY后面的 256 表示是ZSK
我们是使用 KSK 来计算生成 DS 记录：
/opt/bind-9.20.9/bin/dnssec/dnssec-dsfromkey ./Kf78fkdns.top.+013+42980.key
# 成功生成
f78fkdns.top. IN DS 42980 13 2 16DBE0D3003C2AFE68CF48E9BD301EE6001615D498BA8536008E538101D66A36
# 解释
42980 13 2 以及 一长串16进制
42980 代表 keyid
13 代表加密算法 (Algorithm) 是 ECDSAP256SHA256
2 代表 摘要类型(Digest Type) 是 SHA256
一长串16进制代表 摘要(Digest) ，其实就是DNSKEY公钥 做了SHA-256 得到的哈希。
DS 记录上传到域名注册商
密钥标签(Key Tag) 填 (keyid） 42980
加密算法(Algorithm) 选 （13） ECDSA Curve P- 256 with SHA - 256
摘要类型(Digest Type) 选 （2） SHA-256
摘要(Digest) 填 (Digest) 16DBE0D300 ...
全面验证
-----------------------------------------------------------------------------------------------
f78fkdns.top. 3600 IN DNSKEY 256 3 13 gHFpWZIpgjxyBZCv1h0iI000UriMOVhFLLiqn7V/ciqXfcPPMpx6nAX6 ZSG1ZUO7N85VqQyw7lH7q04F8A5Lfw==
f78fkdns.top. 3600 IN DNSKEY 257 3 13 zERhvxYmjqGElHUv40EDJ6dChvMqwm40A9BrM1df8Icx9trohkxiAwtX f4l+HUYksBHMuHUlvaUKQIZ6mz9S5Q==
-----------------------------------------------------------------------------------------------
能看到DNSKEY，无问题。
dig @ns2.f78fkdns.top f78fkdns.top DNSKEY
-----------------------------------------------------------------------------------------------
;; AUTHORITY SECTION:
f78fkdns.top. 3600 IN SOA ns1.f78fkdns.top. admin.f78fk.com. 2025061100 3600 600 604800 3600
;; AUTHORITY SECTION:
f78fkdns.top. 3600 IN SOA ns1.f78fkdns.top. admin.f78fk.com. 2025061100 3600 600 604800 3600
-----------------------------------------------------------------------------------------------
没有DNSKEY，ns3同样缺少DNSKEY，看来是备用DNS服务器还没有同步到，先不等了，手动拉吧。
没有DNSKEY，ns3同样缺少DNSKEY，看来是备用DNS服务器还没有同步到，先不等了，手动拉吧。
ssh 登录ns2和ns3，执行
rndc retransfer f78fkdns.top
主动同步一次，再次查询。
-----------------------------------------------------------------------------------------------
;; ANSWER SECTION:
f78fkdns.top. 3600 IN DNSKEY 256 3 13 gHFpWZIpgjxyBZCv1h0iI000UriMOVhFLLiqn7V/ciqXfcPPMpx6nAX6 ZSG1ZUO7N85VqQyw7lH7q04F8A5Lfw==
f78fkdns.top. 3600 IN DNSKEY 257 3 13 zERhvxYmjqGElHUv40EDJ6dChvMqwm40A9BrM1df8Icx9trohkxiAwtX f4l+HUYksBHMuHUlvaUKQIZ6mz9S5Q==
-----------------------------------------------------------------------------------------------
成功返回了 DNSKEY 记录，ZSK 与 KSK 的公钥都有，说明权威服务器配置正常，公钥部分也已经向全世界公开了。
-----------------------------------------------------------------------------------------------
;; ANSWER SECTION:
f78fkdns.top. 3600 IN DNSKEY 256 3 13 gHFpWZIpgjxyBZCv1h0iI000UriMOVhFLLiqn7V/ciqXfcPPMpx6nAX6 ZSG1ZUO7N85VqQyw7lH7q04F8A5Lfw==
f78fkdns.top. 3600 IN DNSKEY 257 3 13 zERhvxYmjqGElHUv40EDJ6dChvMqwm40A9BrM1df8Icx9trohkxiAwtX f4l+HUYksBHMuHUlvaUKQIZ6mz9S5Q==
-----------------------------------------------------------------------------------------------
成功返回了 DNSKEY 记录，ZSK 与 KSK 的公钥都有，说明权威服务器配置正常，公钥部分也已经向全世界公开了。
继续验证：
首先使用 verisignlabs 验证 。
输入域名,f78fkdns.top 回车
返回了：
Analyzing DNSSEC problems for f78fkdns.top
| . |
| ||||||||||||||||||||||||||||
| top |
| ||||||||||||||||||||||||||||
| f78fkdns.top |
| ||||||||||||||||||||||||||||
| f78fkdns.top |
| ||||||||||||||||||||||||||||
| f78fkdns.top |
|
可能有人不明白，配置这个有什么用呢，举个通俗的例子，google.com 开启了 DNSSEC ，如果客户端访问了 google.com ，结果被攻击者挟持或污染了，返回了错误的 IP 如: 1.2.3.4 ，由于客户端能够通过 DNSSEC 验证发现签名不匹配，就明确知道了这个结果是伪造的，即使被攻击者返回了 NXDOMAIN (域名不存在)，客户端仍然能知道这个结果是被伪造过的。如果未启用 DNSSEC ，客户端就无法得知结果是权威DNS服务器提供的真实IP？ 是被伪造的吗？ 域名真的不存在？这结果到底有没有被改过？反正也不知道，所以只能把结果原封不动的给用户了。
在用户那里体现也是意义很重大的，开启了 DNSSEC ，当DNS被劫持或污染，用户浏览器或者其他前端可以提示给用户，“ 警告：您访问的地址的 DNS 信息被伪造或篡改 ”，而不是直接打不开网页，或者打开了一个被攻击者重定向后的伪造网站。
下面是验证的流程：
从流程图可以看到，从根（.）到 .top，再到 f78fkdns.top，每一级 DNS 响应都带有签名，并且都能通过上一层的公钥验证，确保整个过程中的每一环都没有被篡改，来源是可信的。
-----------------------------------------------------------------------------------------------
我的f78fk.com域名，Cloudflare买的，买了后才知道不支持指定NS和Glue Record，转到NameSilo的话，需要等待60天，之后把 f78fk.com 委任到 (ns1/ns2/ns3).f78fkdns.top 上，并且同样开启DNSSEC的话就是这样的流程了。
等60天后再次部署验证吧。
2025年06年12日更新 :
昨天买了新域名 538053.xyz 委任到了我的自建权威DNS上，同样方法开启了DNSKEY测试一下。
首先 verisignlabs 先来 ：
Analyzing DNSSEC problems for 538053.xyz
| . |
| ||||||||||||||||||||||||
| xyz |
| ||||||||||||||||||||||||
| 538053.xyz |
| ||||||||||||||||||||||||
| 538053.xyz |
| ||||||||||||||||||||||||
| 538053.xyz |
|
看起来整个链条的验证都是完美的。
接下来换 dnsviz.net 测 ：
同样可以看到，从根 . 到 xyz 域，再到我的 538053.xyz 域，整个链条验证也是完整的，所有签名校验均成功通过。但是多了一个警告信息， xyz/DNSKEY（算法 8，ID 3599） 不存在 。
这个通常是因为 .xyz 的 TLD 在更换 DNSSEC Key 时，向根域提交了新的（有效的）DS，但旧的（无效的）DS记录可能未及时从缓存或根域删除，导致出现多余的DS记录。完全不用担心，因为根域中已经有一条有效的DS可以正常验证 XYZ 域了。
常用命令
systemctl restart named
# 查看日志
journalctl -u named -xe | tail -n 30
journalctl -xeu named.service
# 检查配置文件语法
named-checkconf
# 检查配置文件语法
named-checkconf
# 重新载入配置文件，识别新 zone
rndc reconfig
# 热加载所有 zone
rndc reload
# 热加载指定 zone
rndc reload f78fkdns.top
# 立即从主DNS同步
rndc retransfer f78fkdns.top
订阅：
博文 (Atom)