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 和其他相關記錄,有機會再寫
