2

Long time listener, first time caller here.

I'm writing a DNS resolver with DNSSEC validation incorporated, and have noticed something that i can't really understand, after several read-throughs of the affected RFCs.

During a resolution that is a domain in the uk. (specifically co.uk.) TLD i encounter a DNSSEC validation triggered infinite loop. For the sake of simplicity let's assume the process has all the root zone cached already, so let's proceed from there:

  • execute query for co.uk. IN NS at one of the registered uk. nameservers

    ; <<>> 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
  • before anything (like treating the response elements valid), DNSSEC validation should occur; so naturally we execute a query for the DNSKEY with which the RRSIG was signed (we notice that co.uk. is the signer of the records)
  • in order to obtain the DNSKEY for zone co.uk. we need to know the NS authoritative on that zone (reminder, that we already have that information, but didn't manage to validate it yet), therefore we launch a co.uk. IN NS query to the parent zone (uk.) nameserver, and we're back at the beginning.

I am certain that this is a design flaw, but can't really understand what. Logically (and the key step here, that triggers the loop is, that) one shouldn't consider using RRs before validation, and child zone delegation records, again, logically, shouldn't be signed with the child zone's DNSKEY, i think even if the parent zone is authoritative for the child zone too.

Please help and thank you in advance

Johnny Credit
  • 21
  • 1
  • Have a look at authoritative nameservers of `.uk` and `.co.uk`: you will see it is the same set. I think your problems come from that. If also depends if you do top down or bottom above validation. `dig co.uk. DS @dns2.nic.uk.` gives you a DS and same with DNSKEY instead of DS (same nameserver because of previous observation), so the DS signed can verify the DNSKEY which would then validate the RRSIG on .co.uk records. BTW you are a little offtopic here since it is not really a programming question. – Patrick Mevzek May 21 '18 at 21:06
  • Hi. Thanks for that! I know that the same server is authoritative for both of the zones, and this causes the problem alongside with bottom-up validation. The thing is if i do top down validation i would get the same problem, because i can't validate the RRSIG for the DNSKEY record (which is signed with the DNSKEY i'm querying for) – Johnny Credit May 21 '18 at 21:16
  • Oh, sorry i misunderstood what you were saying, @PatrickMevzek. I can see your point, in this case the process got confused because it had to recognize it needs an extra DS query before going forward. Because the same-server delegation did not provide one. Thanks again for the tip! – Johnny Credit May 21 '18 at 21:59

1 Answers1

0

As you noticed, the same name servers are authoritative for both .UK and CO.UK, so you didn't get a normal referral response from the parent zone, which would have DS and NS records in the authority section, but rather an authoritative response from the child zone, with NS records in the answer section.

So you do need an extra DS query to the .UK name servers, as you realized, but be aware that you don't need that DS record in order to validate the DNSKEY and RRSIG records for the NS records. The (non-apex) NS records returned in a normal delegation response are not signed, and do not require validation. When you get back a child zone response, the NS records are apex records, and (if the zone is DNSSEC-signed) there will be an RRSIG for the NS record set, but it is not required to validate those NS records before using them as name servers for the zone. A validating recursive name server only ever needs to validate NS records when it is processing an explicit NS query from a client.

Ultimately, DNSSEC relies on validating the data in zones, not the names or addresses of the name servers that are providing them. This is rather different than many other security protocols, like HTTPS, which authenticate the server (and possibly client) endpoints only.

Alex Dupuy
  • 5,624
  • 2
  • 34
  • 33