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 都有可能引起安全疑虑,之后会提到。

tools, dns

« 邮件MIME格式分析 DNSSEC学习笔记 »