co.uk.使用DNSSEC进行DNS区域验证

时间:2018-05-21 19:08:12

标签: dns dnssec

长时间听众,第一次来电。

我正在编写一个DNS解析器,其中包含DNSSEC验证,并且经过多次对受影响的RFC的反复阅读后发现了一些我无法理解的内容。

在作为uk.(特别是co.uk.)TLD中的域的解析期间,我遇到DNSSEC验证触发了无限循环。 为了简单起见,我们假设该进程已经缓存了所有根区域,所以让我们从那里开始:

  • 在其中一个已注册的co.uk. IN NS名称服务器上执行uk.的查询

    ; <<>> DiG 9.10.5 <<>> co.uk. NS @nsa.nic.uk +dnssec
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54513
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 14
    ;; WARNING: recursion requested but not available
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 4096
    ;; QUESTION SECTION:
    ;co.uk.                         IN      NS
    
    ;; ANSWER SECTION:
    co.uk.                  172800  IN      NS      dns3.nic.uk.
    co.uk.                  172800  IN      NS      dns2.nic.uk.
    co.uk.                  172800  IN      NS      dns1.nic.uk.
    co.uk.                  172800  IN      NS      nsb.nic.uk.
    co.uk.                  172800  IN      NS      nsc.nic.uk.
    co.uk.                  172800  IN      NS      nsa.nic.uk.
    co.uk.                  172800  IN      NS      nsd.nic.uk.
    co.uk.                  172800  IN      NS      dns4.nic.uk.
    co.uk.                  172800  IN      RRSIG   NS 8 2 172800         20180622150723 20180518150505 33621 co.uk.         pYoHwxWpkPP6FfIUk14o5qsO0cxA3CaPvfKGT++MuBhW9Ls/7Xnl6WwE pyU3BIDylkVyELe6be6hCwVOfV3VWcT1JW86RJexhRtU74ZHWdVNnjYd +oQVOQ0V/rhDorVSKdA0G+uDyq11T6Z1ecCERlks63GF21aPM9bWEJD6 cOo=
    
    ;; ADDITIONAL SECTION:
    nsa.nic.uk.             172800  IN      A       156.154.100.3
    nsb.nic.uk.             172800  IN      A       156.154.101.3
    nsc.nic.uk.             172800  IN      A       156.154.102.3
    nsd.nic.uk.             172800  IN      A       156.154.103.3
    dns1.nic.uk.            172800  IN      A       213.248.216.1
    dns2.nic.uk.            172800  IN      A       103.49.80.1
    dns3.nic.uk.            172800  IN      A       213.248.220.1
    dns4.nic.uk.            172800  IN      A       43.230.48.1
    nsa.nic.uk.             172800  IN      AAAA    2001:502:ad09::3
    dns1.nic.uk.            172800  IN      AAAA    2a01:618:400::1
    dns2.nic.uk.            172800  IN      AAAA    2401:fd80:400::1
    dns3.nic.uk.            172800  IN      AAAA    2a01:618:404::1
    dns4.nic.uk.            172800  IN      AAAA    2401:fd80:404::1
    
  • 之前(如处理响应元素有效),应该进行DNSSEC验证;所以我们自然会对RRSIG签名的DNSKEY执行查询(我们注意到co.uk.是记录的签名者)
  • 为了获得区域co.uk.的DNSKEY,我们需要知道该区域的NS权威(提醒,我们已经拥有该信息,但尚未设法验证它),因此我们启动对父区域(co.uk. IN NS)名称服务器的uk.查询,我们回到了开头。

我确信这是一个设计缺陷,但不能真正理解什么。逻辑上(以及触发循环的关键步骤),在验证之前不应该考虑使用RR,并且逻辑上,子区域委托记录不应该与子区域的DNSKEY签名,我甚至认为如果父区域也是子区域的权威。

请提前帮助并谢谢

1 个答案:

答案 0 :(得分:0)

如您所见,.UK和CO.UK都具有相同的名称服务器,因此您没有从父区域获得正常的引用响应,该父区域在权限部分具有DS和NS记录,但是而是来自子区域的权威回应,答案部分带有NS记录。

因此,您确实意识到,确实需要对.UK域名服务器进行额外的DS查询,但是请注意,您不需要该DS记录即可为NS记录验证DNSKEY和RRSIG记录。正常委派响应中返回的(非顶点)NS记录未签名,并且不需要验证。当您获得子区域响应时,NS记录是顶点记录,并且(如果区域是DNSSEC签名的)将为NS记录集提供RRSIG,但是在使用它们之前不需要验证这些NS记录。作为区域的名称服务器。验证递归名称服务器仅在处理来自客户端的显式NS查询时才需要验证NS记录。

最终,DNSSEC依赖于验证区域中的数据,而不是验证提供数据的名称服务器的名称或地址。与许多其他安全协议(例如HTTPS)不同,HTTPS仅对服务器(甚至可能是客户端)端点进行身份验证。