[RSSAC Caucus] Threat Mitigation for the Root Server System

[Michael Casadevall]

Replies inline.

On 10/3/19 5:14 AM, Mukund Sivaraman wrote:
>> 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.
> 
> Nod, but do note that this particular case you've described is not a bug
> as validation does not occur. You're directly querying an authority.
> 

This is arguable because the server is both authoritative and recursive.
I'd expect identical behavior. I'll concede this point in general.

> In case of a validating resolver, what you are describing will not
> happen as it will try to construct either a secure or insecure path from
> the root to the data being validated. A validating resolver has
> pre-configured trust anchors for the root zone and expects the root zone
> to be signed. It will then attempt to follow a trust chain to whatever
> it is validating.

Just as a sanity check, I poked a hole in boron's ACL and confirmed this
behavior, although I got NXDOMAIN instead of SERVFAIL as the error which
surprised me but makes sense since the root zone obviously doesn't have
li694-22 so NSEC would dictate NXDOMAIN is the right response.

Bind's log was as follows:

Oct 03 11:31:45 junkyard named[2500]: running
Oct 03 11:31:46 junkyard named[2500]: managed-keys-zone: Key 20326 for
zone . acceptance timer complete: key now trusted
Oct 03 11:31:46 junkyard named[2500]: resolver priming query complete
Oct 03 11:31:47 junkyard named[2500]: resolver priming query complete
Oct 03 11:31:47 junkyard named[2500]:   validating li694-22/SOA: got
insecure response; parent indicates it should be secure
Oct 03 11:31:47 junkyard named[2500]: no valid RRSIG resolving
'helium.li694-22/DS/IN': 173.255.194.21#53

This confirms validating setup is infact working (and as an added bonus,
is the default on Ubuntu 18.04 LTS). No surprise here, but now I know I
can attempt to replicate setups.

> Try to replicate what you're stating as an experiment:
> 
> 1. Setup authoritative server serving the ICANN root zone.
> 
> 2. Setup a *separate* validating resolver with the ICANN root zone trust
> anchor (should be present by default) that has its root hints configured
> to query your authoritative that serves the root zone.
> 
> 3. Compromise the example.org. domain by adding records directly into
> your root zone, and any other changes you want to make to the root zone
> such as deleting the .org delegation to facilitate this. (The public
> example.org is a signed zone btw.)
> 
> 4. At the validating resolver, try to query example.org./A and see if
> you get an AD=1 answer.
I did infact do exactly this for most of yesterday and this morning and
BIND on Ubuntu 18.04 properly returned SERVFAIL or NXDOMAIN no matter
how I fiddled with the root. I did learn quite a bit more about how
DNSSEC works in practice by manually fiddling with NSEC and other
records in my test root.

I happy to be proven wrong and learn something along the way. I also did
some testing with other DNS resolvers shipped in Ubuntu. I found unbound
and BIND correctly do DNSSEC validation "out of the box", but PowerDNS
Recursor I had to go through it's configuration files and edit them
before I got DNSSEC validating behavior. I also noticed slight
behavioral differences between Unbound and PDNS recursor on how it
handled some invalid records but no place where it did the wrong thing.

I also did some investigations with dnsmasq (which granted is a stub
resolver) and found that it requires a lot of setup to do any DNSSEC
validation correctly at all assuming it was even compiled with it. (the
version in Ubuntu does have DNSSEC enabled, but doesn't ship with it
configured; I need to further investigate things like Youti Linux and
buildroot to see how they handle dnsmasq).

I believe a lot of the earlier oddness I reported seeing was the
behavior of directly asking BIND for information when it both a
recursive resolver + authoritative zone and that confused me overall.
I'm glad to have that mystery solved and have better confidence on the
default behaviors of some resolvers.

There's still likely a fair bit of value in strapping DNS servers to a
bench and seeing how they behave, as well as looking deeper into how
distributions are configuring and shipping popular DNS resolvers in
regards to DNSSEC as well as looking deeper into router distribution
firmwares and how they in turn handle DNSSEC configuration and similar
questions. I'm going to likely sleep on this for a bit but feedback and
places in which to look for low hanging fruit are most welcome.

Thank you all for your patience,
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/20191004/68c07a4f/pEpkey.asc>