kk Blog —— 通用基础


date [-d @int|str] [+%s|"+%F %T"]
netstat -ltunp
sar -n DEV 1

RRSIG、DNSKEY、信任炼和NSEC

1
2
3
4

dig @192.58.128.30 +dnssec . A
dig @192.58.128.30 +dnssec . NS

dig @192.58.128.30 +dnssec . DNSKEY

https://www.dazhuanlan.com/xwuxin/topics/1848106

DNSSEC 验证流程

第一步：RRSIG

前述提到，DNSSEC 的状况下，每一个纪录都应该要经过数字签章做签署的动作。所以 DNSSEC 里面有提到一种 DNS 纪录，这个纪录叫做 RRSIG，会附在 DNS 请求的回复当中。

内容大概像这样：

1
2
3
4
5
6
7
8
9

   网域名称       TTL  类型   内容
   a.z.w.example. 3600 IN MX  1 ai.example.
   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                              4kX18MMR34i8lC36SR5xBni8vHI= )

第一行是 ai.example 这个网域的 MX 纪录。

第二行是给第一笔记录使用的 RRSIG 纪录。

RRSIG 的格式是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[对应格式] [算法编号] [涵盖数量]  [有效时间长短] [签章期限] 
|            |         |              |           |
|   ---------/         |              |           |
|  /  -----------------/              |           |
|  | /  /-----------------------------/           |
|  | |  |   /-------------------------------------/
|  | |  |   |
|  | |  |   |
MX 5 2 3600 20040509183619 ( 20040409183619 38519 example. OM.....HI= ) 
                             |               |     |         |
  /--------------------------/               |     |         |
  |          /-------------------------------/     |         |
  |          |      /------------------------------/         |
  |          |      |            /---------------------------/
[签署日期] [Tag] [签署者名称] [内容，base64]

DNSKEY

随着 RRSIG 的出现，我们拿到凭证的内容了。不过我们需要验证这个签章是不是伪造的，然后是谁签的。这个信息，会在 DNSKEY 纪录当中。

1
2
3
4
5
6
7

   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                          kfzj31GajIQKY+5CptLr3buXA10h
                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                          742iU/TpPSEDhm2SNKLijfUppn1U
                                          aNvv4w==  )

DNSKEY 里面会包含拿去签署 RRSIG 的公钥。

不过，即使我们能够确认「这个 RRSIG 和 DNSKEY 对得起来」，也还不能够确认「这个 DNSKEY 真的属于这个网域」。

所以我们会需要一个能够信任方式，来验证这个 DNSKEY。

就像前面提到的 HTTPS 凭证信任链的状况，我们可能有几种做法，可以验证这个东西：

  1. 用其他的方式去获得「这个网域真正的公钥」，例如 PGP、中华邮政寄 U 盘、用纸抄、用 scp 先下载一份

  2. 叫别人证明你是合法的（参考 HTTPS 中介凭证机制）

信任链机制

前述提到，只拿到 DNSKEY 没什么用。然后若要将上述第一种取得真正公钥的方式，放到 DNS 这种许多人用的协定之上，是不可行的。想像一下，你要联网之前，必须要插 U 盘。这是一个多荒诞的事情？

所以，我们可以依赖上一级网域的 DNS 纪录，把上一级凭证的公钥放在那边。在 DNSSEC 中，这个叫做 DS (Delegation Signer) 纪录。由于你可以指定非常多的子网域，所以 DS 纪录中，只会记载「这个凭证的指纹 (hash)」。

真的很短，他长得像这样：

1
2

 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                            98631FAD1A292118 )

然后假设一笔 DNSKEY 是被上一级签署过的话，他会看起来像这样：

1
2
3
4
5
6
7
8
9

dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                         fwJr1AYtsmx3TGkJaNXVbfi/
                                         2pHm822aJ5iI9BMzNXxeYCmZ
                                         DRD99WYwYqUSdjMmmAphXdvx
                                         egXd/M5+X7OrzKBaMbCVdFLU
                                         Uh6DhweJBjEVv5f2wwjM9Xzc
                                         nOf+EPbtG9DMBmADjFDc2w/r
                                         ljwvFw==
                                         ) ;  key id = 60485

其中，我们会发现 key id 和上面的 DS 纪录是一样的。另外，是可以通过 DNSKEY 去计算出 DS 的数值，所以我们可以通过证明这两个之间的关系，来保证 DNSKEY 纪录的可靠性。 特殊状况: 找不到纪录怎么办？ (NSEC)

在 DNS 的状况下，基本上，若找不到东西，只要回复 NXDOMAIN 就好了。不过在 DNSSEC 的状况下，由于回复的数据内容内也要证明这消息不是伪造的，但这东西根本查不到，所以我们要想办法告诉对方「我真的找不到」。

DNSSEC 想到了这个问题，所以又有一种纪录叫做 NSEC (Next Secure)。这个纪录里面会记载说「下一笔纪录是什么」。

所以，假设今天有 A、B、D。有人问了 C，你找不到，但是你可以用 NSEC 和他说：「下一笔真的是 D，我知道他还有 A、RRSIG 和 NSEC，你可以看看 D 是不是真的有这些东西」来确保你没有说谎。

由于 DNS 纪录是以字母来做排序的，所以你可以确定「真的没有那笔东西」。

另外，若某一个网域的纪录是存在的，只是问错类别（例如你有 A 但对方问 MX）的话，这时候的回复里面会告诉对方这个网域所有的纪录。

不过，不管是不是这个状况，NSEC 都有可能引起安全疑虑，之后会提到。