dnssec 详解需要慢慢分析

DNSSEC 分为两部分

dnssec 目前.gov 普及率80%  .com 使用率1.5% ,所以用的不对，只在根和顶级域用的比较多，为啥呢，因为真的有点慢.查询过程变得异常复杂.不是简单的那个她了，文件也大了三倍以上。

对于之前512 mtu  的限制无限超出。EDNS 和tcp 解决这个。

20:21:55.920878 IP gateway.49226 > localhost.localdomain.domain: 56265+ [1au] A? www.baidu.com. (54)
20:21:55.921462 IP localhost.localdomain.52695 > 110.242.68.134.domain: 22983 [1au] A? www.baidu.com. (54)
20:21:55.922806 IP localhost.localdomain.36795 > public1.114dns.com.domain: 37540+ PTR? 200.200.168.192.in-addr.arpa. (46)
20:21:55.937688 IP 110.242.68.134.domain > localhost.localdomain.52695: 22983*- 1/5/6 CNAME www.a.shifen.com. (239)
20:21:55.938063 IP localhost.localdomain.55211 > e.gtld-servers.net.domain: 60697 [1au] DS? baidu.com. (50)
20:21:55.949491 IP public1.114dns.com.domain > localhost.localdomain.36795: 37540 NXDomain 0/1/0 (123)
20:21:55.953575 IP localhost.localdomain.41659 > public1.114dns.com.domain: 16133+ PTR? 1.200.168.192.in-addr.arpa. (44)
20:21:55.984576 IP public1.114dns.com.domain > localhost.localdomain.41659: 16133 NXDomain 0/1/0 (121)
20:21:55.986113 IP localhost.localdomain.40992 > public1.114dns.com.domain: 13255+ PTR? 134.68.242.110.in-addr.arpa. (45)
20:21:56.738933 IP localhost.localdomain.54009 > m.gtld-servers.net.domain: 19231 [1au] DS? baidu.com. (50)
20:21:56.945054 IP m.gtld-servers.net.domain > localhost.localdomain.54009: 19231*-| 0/4/1 (465)
20:21:58.363399 IP localhost.localdomain.36438 > 14.215.178.80.domain: 43452 [1au] A? _.a.shifen.com. (55)
20:21:58.406243 IP 14.215.178.80.domain > localhost.localdomain.36438: 43452- 0/5/6 (213)
20:21:58.407532 IP localhost.localdomain.41967 > 112.80.255.253.domain: 52831 [1au] A? www.a.shifen.com. (57)
20:21:58.436887 IP 112.80.255.253.domain > localhost.localdomain.41967: 52831*- 2/0/1 A 220.181.38.149, A 220.181.38.150 (105)
20:21:58.438179 IP localhost.localdomain.48683 > h.gtld-servers.net.domain: 22794 [1au] DS? shifen.com. (51)
20:21:58.642058 IP h.gtld-servers.net.domain > localhost.localdomain.48683: 22794*-| 0/4/1 (466)
20:21:59.046311 IP localhost.localdomain.domain > gateway.49226: 56265 3/0/1 CNAME www.a.shifen.com., A 220.181.38.150, A 220.181.38.149 (132)
20:22:00.992411 IP localhost.localdomain.40992 > public1.114dns.com.domain: 13255+ PTR? 134.68.242.110.in-addr.arpa. (45)
20:22:01.024855 IP public1.114dns.com.domain > localhost.localdomain.40992: 13255 NXDomain 0/1/0 (134)
20:22:01.026206 IP localhost.localdomain.50340 > public1.114dns.com.domain: 48652+ PTR? 114.114.114.114.in-addr.arpa. (46)
20:22:01.066326 IP public1.114dns.com.domain > localhost.localdomain.50340: 48652 1/0/0 PTR public1.114dns.com. (78)
20:22:01.067241 IP localhost.localdomain.56127 > public1.114dns.com.domain: 56061+ PTR? 30.94.12.192.in-addr.arpa. (43)
20:22:01.106109 IP public1.114dns.com.domain > localhost.localdomain.56127: 56061 1/0/0 PTR e.gtld-servers.net. (75)
20:22:01.106406 IP localhost.localdomain.44652 > public1.114dns.com.domain: 44512+ PTR? 30.83.55.192.in-addr.arpa. (43)
20:22:01.138881 IP public1.114dns.com.domain > localhost.localdomain.44652: 44512 1/0/0 PTR m.gtld-servers.net. (75)
20:22:01.139128 IP localhost.localdomain.52873 > public1.114dns.com.domain: 41877+ PTR? 80.178.215.14.in-addr.arpa. (44)
20:22:01.180286 IP public1.114dns.com.domain > localhost.localdomain.52873: 41877 NXDomain 0/1/0 (108)
20:22:01.180736 IP localhost.localdomain.47316 > public1.114dns.com.domain: 54697+ PTR? 253.255.80.112.in-addr.arpa. (45)
20:22:01.225729 IP public1.114dns.com.domain > localhost.localdomain.47316: 54697 NXDomain 0/1/0 (99)
20:22:01.226944 IP localhost.localdomain.46526 > public1.114dns.com.domain: 32671+ PTR? 30.112.54.192.in-addr.arpa. (44)
20:22:01.260771 IP public1.114dns.com.domain > localhost.localdomain.46526: 32671 1/0/0 PTR h.gtld-servers.net. (76)

https://bind9.readthedocs.io/en/v9_16_24/dnssec-guide.html#validation

一、dnssec-validation DNSSEC-验证

dnssec-validation 是解析服务器对响应的记录进行验证的功能，必须是信任链可信的域名才行

默认auto ，开启这个功能递归服务器就会去验证是否可信任

options {
    dnssec-validation auto;    #开启dnssec-validation auto 功能必须要配置正确的时间，时间也要校验
};

This “auto” line enables automatic DNSSEC trust anchor configuration using the managed-keys feature. In this case, no manual key configuration is needed. There are three possible choices for the dnssec-validation option:
此“自动”行使用托管密钥功能启用自动DNSSEC信任锚配置。在这种情况下，不需要手动钥匙配置。dnssec验证选项有三种可能的选择：
yes: DNSSEC validation is enabled, but a trust anchor must be manually configured. No validation actually takes place until at least one trusted key has been manually configured.
是：已启用DNSSEC验证，但必须手动配置信任锚。在手动配置至少一个受信任密钥之前，不会实际进行验证。
no: DNSSEC validation is disabled, and the recursive server behaves in the “old-fashioned” way of performing insecure DNS lookups.
否：DNSSEC验证已禁用，递归服务器以“老式”方式执行不安全的DNS查找。
auto: DNSSEC validation is enabled, and a default trust anchor (included as part of BIND 9) for the DNS root zone is used. This is the default; BIND automatically does this if there is no dnssec-validation line in the configuration file.
自动：已启用DNSSEC验证，并使用DNS根区域的默认信任锚点（包含在BIND 9中）。这是默认值；如果配置文件中没有dnssec验证行，BIND会自动执行此操作。

 这是我当前的环境

[root@localhost etc]# named -V
BIND 9.16.24 (Extended Support Version) <id:93e3098>
running on Linux x86_64 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018
built by make with '--prefix=/opt/sgccdns' '--disable-static' '--with-openssl'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled

default paths:
  named configuration:  /opt/sgccdns/etc/named.conf
  rndc configuration:   /opt/sgccdns/etc/rndc.conf
  DNSSEC root key:      /opt/sgccdns/etc/bind.keys   #dnssec 信任密钥,根的公钥
  nsupdate session key: /opt/sgccdns/var/run/named/session.key
  named PID file:       /opt/sgccdns/var/run/named/named.pid
  named lock file:      /opt/sgccdns/var/run/named/named.lock
[root@localhost etc]# 

 1.权威服务器dnssec 

 那么DNSSEC的答案到底是如何验证的呢？让我们首先看看如何生成可验证的信息。在权威服务器上，每个DNS记录（或消息）都通过哈希函数运行，然后通过私钥对该哈希值进行加密。此加密哈希值是数字签名。

2.递归服务器如何验证

 验证冲突解决程序查询资源记录时，它同时接收纯文本消息和数字签名。验证解析程序知道所使用的哈希函数（它列在数字签名记录本身中），因此它可以获取纯文本消息并通过相同的哈希函数运行它以生成哈希值，我们称之为哈希值X。验证解析程序还可以获取公钥（发布为DNSKEY记录），解密数字签名，并获取权威服务器生成的原始散列值，我们称之为散列值Y。如果散列值X和Y相同，并且时间正确（下面将详细说明这意味着什么），则验证答案，这意味着该答案来自权威服务器（真实性），运输过程中内容物保持完整（完整性）。

注解: 这里递归服务器看到响应的记录中包含 RRSIG  type 类型的记录后会校验数字签名，会请求 type DNSKEY 的公钥，解密后得到权威哈希的值Y，然后根据www.isc.org. 300 IN RRSIG CNAME 13 3 300 中13 表示SHA256

计算 www.isc.org. 300 IN CNAME dualstack.osff2.map.fastly.net. 的 散列值 X，比较X=Y ?

root@localhost etc]# dig @192.168.200.200 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.16.24 <<>> @192.168.200.200 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53780
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 790fd8c0692d24a70100000061e0056eb8d7e148d63ef519 (good)
;; QUESTION SECTION:
;www.isc.org.        IN A

;; ANSWER SECTION:
www.isc.org.        300 IN CNAME dualstack.osff2.map.fastly.net.
www.isc.org.        300 IN RRSIG CNAME 13 3 300 (
                20220123151519 20211224144419 27566 isc.org.
                QSz8TD9BvYxxQAS3OuatwDISaabQoqlVqH872T2adlty
                75gk7QQsiDLAvRseeGxzseaxkP7CYzCH365SaixmtA== )
dualstack.osff2.map.fastly.net.    30 IN A    151.101.74.217

;; Query time: 1469 msec
;; SERVER: 192.168.200.200#53(192.168.200.200)
;; WHEN: Thu Jan 13 18:56:46 CST 2022
;; MSG SIZE  rcvd: 231

[root@localhost etc]# 

2.验证父级

作为验证的一部分询问父区域。它一直重复这个获取密钥、验证、询问父级、其父级和其父级的过程，直到验证解析器到达它信任的密钥为止。在理想的、完全部署的DNSSEC环境中，所有验证解析器只需要信任一个密钥：根密钥。也就是DNSSEC root key: /opt/sgccdns/etc/bind.keys 

 第5 步开始验证父级,前面的递归服务器验证

如何进行认证,DS 记录

DS

43

RFC 4034

委托签发者

此记录用于鉴定DNSSEC已授权区域的签名密钥。

DS 值是当前zone 的DNSKEY 文件hash 值，管理员发邮件把hash给上级域管理员,在对应的NS 记录底下加一个DS 记录,和DS记录对应RRSIG 签名记录,

获取RRSIG 和DS 记录后用父域的public key 解密看和DS 记录值是否一样，一致后继续向上级查询直到root 查询，当前这个例子查到org 后它的根域是 root (.) ,它的public 就是bind.key

有点类似域名证书吊销列表的查询过程

父域查询

C:\Users\zy>dig @192.168.200.200  isc.org   DS +dnssec

; <<>> DiG 9.14.4 <<>> @192.168.200.200 isc.org DS +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10354
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: ec03d46628ca29b10100000061e0166bce4270d7b1479eb9 (good)
;; QUESTION SECTION:
;isc.org.                       IN      DS

;; ANSWER SECTION:
isc.org.                80042   IN      DS      7250 13 2 A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697 CDA01CB2
isc.org.                80042   IN      RRSIG   DS 8 2 86400 20220130152229 20220109142229 54255 org. O76M527q9ojaoNDa4uN0fjBmddfKCbWbHY2pWDapVXnCEMrw4uwFCr9O ZToOgThOqE+rD0jQl1JURtquzVbkFIPtR82uNgHn2GejVQx1S36xhFK6 E6bzJyhb36KfEqyr31BXlTbkdwfJBw/h9uL6OstFUSzoV85lVY+cLULN 3VQ=

;; Query time: 1 msec
;; SERVER: 192.168.200.200#53(192.168.200.200)
;; WHEN: Thu Jan 13 20:10:12 中国标准时间 2022
;; MSG SIZE  rcvd: 275


C:\Users\zy>

根域查询

C:\Users\zy>dig @192.168.200.200  org   DS +dnssec

; <<>> DiG 9.14.4 <<>> @192.168.200.200 org DS +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1729
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 7198add6eaf05ccf0100000061e017187cc1d97eb48fe0d0 (good)
;; QUESTION SECTION:
;org.                           IN      DS

;; ANSWER SECTION:
org.                    79869   IN      DS      26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
org.                    79869   IN      RRSIG   DS 8 1 86400 20220126050000 20220113040000 9799 . RN7ckY5ipFbNRABGEusgewk7HrBBpSTdfgNCR5GMSYF5Kg5Z/M+/lipL H8h5ACf9YNJnsd/CY4+G77eGFJzOZrP+kk5HlV8kri+pKqQMDbW2GDBk lu89DRHxO325PAm1lXXqYyAojNOweZKNFLeRs7IEXieUD1RFxD20cBNP KWSxYwh77QLUSjTmWJtRCqgg9kD2LiJNQAf+ntsZfOl5/KwnRQ7/l0ia Ci/d6eCj52TAxXJfgi+q9sttUYqfJMe0OjbHpAjSxNacA2AoQr/s3AsZ VYPTl/ULfaU/ut8ODoIDi24d1s8i9gDH8LMckF6wI20hQkZ2DFzYaxYx CnSbeA==

;; Query time: 1 msec
;; SERVER: 192.168.200.200#53(192.168.200.200)
;; WHEN: Thu Jan 13 20:13:05 中国标准时间 2022
;; MSG SIZE  rcvd: 395


C:\Users\zy>

trust-anchors

[root@localhost etc]# cat bind.keys 
# The bind.keys file is used to override the built-in DNSSEC trust anchors
# which are included as part of BIND 9.  The only trust anchors it contains
# are for the DNS root zone (".").  Trust anchors for any other zones MUST
# be configured elsewhere; if they are configured here, they will not be
# recognized or used by named.
#
# To use the built-in root key, set "dnssec-validation auto;" in the
# named.conf options, or else leave "dnssec-validation" unset.  If
# "dnssec-validation" is set to "yes", then the keys in this file are
# ignored; keys will need to be explicitly configured in named.conf for
# validation to work.  "auto" is the default setting, unless named is
# built with "configure --disable-auto-validation", in which case the
# default is "yes".
#
# This file is NOT expected to be user-configured.
#
# Servers being set up for the first time can use the contents of this file
# as initializing keys; thereafter, the keys in the managed key database
# will be trusted and maintained automatically.
#
# These keys are current as of Mar 2019.  If any key fails to initialize
# correctly, it may have expired.  In that event you should replace this
# file with a current version.  The latest version of bind.keys can always
# be obtained from ISC at https://www.isc.org/bind-keys.
#
# See https://data.iana.org/root-anchors/root-anchors.xml for current trust
# anchor information for the root zone.

trust-anchors {
        # This key (20326) was published in the root zone in 2017.
        . initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
                +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
                ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
                0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
                oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
                RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
                R1AkUTV74bU=";
};
[root@localhost etc]# 

来自: https://www.cloudflare.com/zh-cn/dns/dnssec/how-dnssec-works/

来自: https://www.cloudflare.com/zh-cn/dns/dnssec/root-signing-ceremony/

委派签名者记录

DNSSEC 引入了委派签名者（DS）记录，以允许将信任从父区域转移到子区域。区域操作员对包含公共 KSK 的 DNSKEY 记录进行哈希处理，并将其提供给父区域以作为 DS 记录发布。

每次将解析器引用到子区域时，父区域也会提供 DS 记录。此 DS 记录是解析器获知子区域启用 DNSSEC 的方式。为了检查子区域的公共 KSK 的有效性，解析器对其进行哈希处理并将其与父区域的 DS 记录进行比较。如果两者匹配，则解析器可以假定公共 KSK 未被篡改，这意味着它可以信任子区域中的所有记录。这就是在 DNSSEC 中建立信任链的方式。

请注意，KSK 的任何变更都需要更改父区域的 DS 记录。更改 DS 记录是一个多步骤的过程，如果执行不正确，最终可能会破坏该区域。首先，父级需要添加新的 DS 记录，然后需要等到原始 DS 记录的 TTL 过期后将其删除。这就是为什么换掉区域签名密钥比密钥签名密钥要容易得多。

信任链

现在，在区域内建立信任并将其连接到父区域的方法已经有了，但是我们如何信任 DS 记录呢？DS 记录就像其他任何 RRset 一样签署，这意味着它在父级中具有相应的 RRSIG。整个验证过程不断重复，直到获得父级的公共 KSK。为了验证父级的公共 KSK，我们需要转到父级的 DS 记录，以此类推，沿着信任链上行。

但是，当我们最终到达根 DNS 区域时，又有一个问题：没有父 DS 记录可用于验证。在这里，我们可以看到全球互联网非常人性的一面：

在“根区域签名仪式”上，来自世界各地的特定几人以公开且经严格审核的方式签署根 DNSKEY RRset。这次仪式会产生一个 RRSIG 记录，该记录可用于验证根名称服务器的公共 KSK 和 ZSK。我们不会由于父级的 DS 记录而信任公共 KSK，而是因为信任访问私有 KSK 所涉的安全性过程而假定其有效。

在父区域和子区域之间建立信任的能力是 DNSSEC 不可或缺的一部分。如果信任链中的任何部分被破坏，我们就不能信任我们所请求的记录，因为中间人可能会更改记录并将我们引导到任何 IP 地址。

 dig 114.114.114.114 www.isc.org. A +dnssec +multiline   使用dnssec 请求响应RRSIG ,默认递归服务器不向clinet 响应这个
 dig 114.114.114.114 www.isc.org. A +cd  不发送dnssec 标记的请求,那权威就不发这个        

C:\Users\zy>dig 114.114.114.114 www.isc.org. A +dnssec +multiline +trace

; <<>> DiG 9.14.4 <<>> 114.114.114.114 www.isc.org. A +dnssec +multiline +trace
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36560
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;114.114.114.114.               IN      A

;; AUTHORITY SECTION:
.                       57507   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2022011201 1800 900 604800 86400

;; Query time: 80 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan 13 20:43:56 中国标准时间 2022
;; MSG SIZE  rcvd: 119

.                       85920 IN NS m.root-servers.net.
.                       85920 IN NS b.root-servers.net.
.                       85920 IN NS c.root-servers.net.
.                       85920 IN NS d.root-servers.net.
.                       85920 IN NS e.root-servers.net.
.                       85920 IN NS f.root-servers.net.
.                       85920 IN NS g.root-servers.net.
.                       85920 IN NS h.root-servers.net.
.                       85920 IN NS a.root-servers.net.
.                       85920 IN NS i.root-servers.net.
.                       85920 IN NS j.root-servers.net.
.                       85920 IN NS k.root-servers.net.
.                       85920 IN NS l.root-servers.net.
.                       85920 IN RRSIG NS 8 0 518400 (
                                20220126050000 20220113040000 9799 .
                                XYgOzIz7vvY0tEa6tZm68wTTBE7Z3SRXpA3iNggs1V0C
                                hJrnM7TBp/wQPYMZp2mo+msGrdvwAKGx+YFEMdky/ksu
                                0xMiNLs0/ABAR1zatBevZS7jRAAxKgWWbS8U4RhaN/P1
                                w4P+vocpXe9qQrGpR2vQNzeyTaSNgjMFwyVL/UL4p/yt
                                YHzBZNOxZDBdhIiXLdzzKNMldjQN/DUMtGlumDs3mokZ
                                zvo9oNs4v7PNL4VsMPwH81ECH5Dzu95oO3nanJksLMn5
                                bvv/bYo1mhqU/IW2FyAG+uoMFNYb46Ak7zD9n37t8nuY
                                Z5VsFqIRS9HcGLNwLAOXnEOFJFiSrmHvtw== )
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 80 ms

org.                    172800 IN NS d0.org.afilias-nst.org.
org.                    172800 IN NS a0.org.afilias-nst.info.
org.                    172800 IN NS c0.org.afilias-nst.info.
org.                    172800 IN NS a2.org.afilias-nst.info.
org.                    172800 IN NS b0.org.afilias-nst.org.
org.                    172800 IN NS b2.org.afilias-nst.org.
org.                    86400 IN DS 26974 8 2 (
                                4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0A
                                EAFF14745C0D16E1DE32 )
org.                    86400 IN RRSIG DS 8 1 86400 (
                                20220126050000 20220113040000 9799 .
                                RN7ckY5ipFbNRABGEusgewk7HrBBpSTdfgNCR5GMSYF5
                                Kg5Z/M+/lipLH8h5ACf9YNJnsd/CY4+G77eGFJzOZrP+
                                kk5HlV8kri+pKqQMDbW2GDBklu89DRHxO325PAm1lXXq
                                YyAojNOweZKNFLeRs7IEXieUD1RFxD20cBNPKWSxYwh7
                                7QLUSjTmWJtRCqgg9kD2LiJNQAf+ntsZfOl5/KwnRQ7/
                                l0iaCi/d6eCj52TAxXJfgi+q9sttUYqfJMe0OjbHpAjS
                                xNacA2AoQr/s3AsZVYPTl/ULfaU/ut8ODoIDi24d1s8i
                                9gDH8LMckF6wI20hQkZ2DFzYaxYxCnSbeA== )
;; Received 777 bytes from 198.41.0.4#53(a.root-servers.net) in 174 ms

isc.org.                86400 IN NS ns.isc.afilias-nst.info.
isc.org.                86400 IN NS ns1.isc.org.
isc.org.                86400 IN NS ns2.isc.org.
isc.org.                86400 IN NS ns3.isc.org.
isc.org.                86400 IN DS 7250 13 2 (
                                A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F
                                4531D33DE697CDA01CB2 )
isc.org.                86400 IN RRSIG DS 8 2 86400 (
                                20220130152229 20220109142229 54255 org.
                                O76M527q9ojaoNDa4uN0fjBmddfKCbWbHY2pWDapVXnC
                                EMrw4uwFCr9OZToOgThOqE+rD0jQl1JURtquzVbkFIPt
                                R82uNgHn2GejVQx1S36xhFK6E6bzJyhb36KfEqyr31BX
                                lTbkdwfJBw/h9uL6OstFUSzoV85lVY+cLULN3VQ= )
;; Received 446 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 144 ms

www.isc.org.            300 IN CNAME dualstack.osff2.map.fastly.net.
www.isc.org.            300 IN RRSIG CNAME 13 3 300 (            #这里没有DS 类型因为没有子域继续委派了 end
                                20220123151519 20211224144419 27566 isc.org.
                                QSz8TD9BvYxxQAS3OuatwDISaabQoqlVqH872T2adlty
                                75gk7QQsiDLAvRseeGxzseaxkP7CYzCH365SaixmtA== )
;; Received 215 bytes from 199.6.1.52#53(ns2.isc.org) in 263 ms


C:\Users\zy>

二、Signing 签字

也就是如何对管理的域名生成对应 DS RRSIG 和其他相关记录,有机会再写