[RSSAC Caucus] Threat Mitigation for the Root Server System

[Michael Casadevall]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3106 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20191003/37702c1e/pEpkey.asc>