Replies inline. On 10/3/19 3:35 AM, Mukund Sivaraman wrote:
Hi Michael
Isn't "li694-22." a fake domain that only exists on your authoritative server "helium"? And it is unclear if you're also running a fake root zone as in the 1st case you'd described. It's not entirely clear without seeing all the zone's contents and nameserver config.
Anyway, here you're querying helium directly for "hydrogen.li694-22./AAAA". helium is an authoritative for "li694-22." as you've noted - authoritative server algorithm does not perform DNSSEC validation (it is resolver algorithm that does). Basically helium is serving the unsigned "li694-22." zone in this case in isolation. It serves no DNSSEC records because none exist, and returns AA=1.
The nameserver (one that has both authoritative and resolver functionality) prefers to return authoritative data when it is available over cached data.
I admit that this isn't a perfect representation. The point of the case was to highlight potential abnormalities in handling cases where DNSSEC validation should (at least by spec) return SERVFAIL. We're dependent on a signed root to prevent anyone from hijacking the root servers either via BGP, server compromise, etc. Assuming a compromised root server, an attacker can return AA=1 for whatever they like. Assuming a cold cache scenario, a recursive resolver might try the following: Client -> Resolver: I want A IN for icann.org Resolver -> Root Server: icann.org A IN Compromised Root: Here's an authoritative answer for icann.org A IN Resolver: Oh, it's authoritative, I don't need to worry about DNSSEC. Client gets compromised record. In a compromised root scenario, the root servers can respond DO=0 and pretend that they're unsigned, or generate any sort of packet they want. If there's a case where dnssec validation is enabled, CD=0 and there's an escape hole that allows a record to come back to the stub resolver that isn't SERVFAIL, DNSSEC has effectively been undermined. Long story short, I'm seeing abnormalities and soft-fail behaviors regarding DNSSEC and the root. I'm currently rewriting my existing code to better create a baseline to work through to characterize this behavior to know if we've got an actual problem. Michael