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

长时间的听众，第一次打电话到这里

我正在编写一个包含DNSSEC验证的DNS解析器，在对受影响的RFC进行了多次通读之后，我注意到了一些我不能真正理解的东西

在作为

uk.

（特别是

co.uk.

）TLD域的解析过程中，我遇到了DNSSEC验证触发的无限循环。 为了简单起见，假设进程已经缓存了所有根区域，那么让我们从这里开始：

• 执行对

  co.uk的查询。在英国注册的
  名称服务器之一的NS
  中
  
  ; <<>> 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
  
  ；挖掘9.10.5 co.uk。NS@nsa.nic.uk+dnssec
  ;; 全局选项：+cmd
  ;; 得到答案：
  ;; ->>HEADER正如您所注意到的，相同名称的服务器对.UK和CO.UK都具有权威性，因此您没有从父区域获得正常的转介响应（在权威部分中有DS和NS记录），而是从子区域获得权威性响应，在应答部分中有NS记录
  
  因此，正如您所意识到的，您确实需要对.UK名称服务器进行额外的DS查询，但请注意，您不需要该DS记录来验证NS记录的DNSKEY和RRSIG记录。在正常委派响应中返回的（非apex）NS记录没有签名，不需要验证。当您返回子区域响应时，NS记录是apex记录，并且（如果该区域是DNSSEC签名的），NS记录集将有一个RRSIG，但是在将这些NS记录用作该区域的名称服务器之前，不需要验证这些NS记录。验证递归名称服务器仅在处理来自客户端的显式NS查询时需要验证NS记录
  
  最终，DNSSEC依赖于验证区域中的数据，而不是验证提供这些数据的名称服务器的名称或地址。这与许多其他安全协议（如HTTPS）截然不同，HTTPS仅对服务器（可能还有客户端）端点进行身份验证。
  请查看
  .uk
  和
  .co.uk
  的权威名称服务器：您将看到它是同一组。我认为你的问题就在于此。如果还取决于您是进行自上而下还是自下而上的验证<代码>dig co.uk。DS@dns2.nic.uk。
  为您提供了一个DS和相同的DNSKEY，而不是DS（由于之前的观察，名称服务器相同），因此DS签名可以验证DNSKEY，然后验证.co.uk记录上的RRSIG。顺便说一句，你在这里有点离题，因为这不是一个真正的编程问题。谢谢你！我知道同一台服务器对这两个区域都具有权威性，这导致了问题以及自底向上的验证。问题是，如果我进行自顶向下的验证，我也会遇到同样的问题，因为我无法验证DNSKEY记录的RRSIG（该记录是用我查询的DNSKEY签名的）。哦，对不起，我误解了你的意思，@PatrickMevzek。我可以理解你的观点，在这种情况下，过程变得混乱，因为它必须在继续之前认识到它需要一个额外的DS查询。因为同一个服务器委派没有提供。再次感谢你的提示！