Michael Casadevall wrote on 2019-10-02 00:30:
Looking at the document, one thing that jumps out of me is both data integrity and route hijacking. I feel like this document puts far too much faith in validating resolvers to catch compromised root servers and route hijacking.
When I did work on creating a root server emulation setup for testing root IDNs, generally speaking, unless I went out of my way to force strict compliance, non-signed/invalidly signed data would just be accepted if it came from the roots even before I inserted my fake KSK into the mix.
The short version, is if I can pop a root server and inject malicious traffic, I can't tamper with the root server data without causing signature validation failures. I *can* freely change the NS records to MITN any DNS lookups to a TLD especially if I'm just echoing signed data. That's a pretty darn effective way to essentially cast a dragnet on all lookups to a TLD.
Furthermore, I'm not convinced that the recursive resolver infrastructure as a whole will properly fail if someone injected a bad zone into the root. The defaults on far too many things are to soft-fail vs. hard-fail.
it's vital that we find out how common this behaviour is. data exfiltration by unsigned (delegation) NS RR is not concerning, since the data is public, and since in the earlier part of the story a root name server had to be compromised -- so exfiltration is already on the table, be it from one vantage point or another. however, if soft fails are sometimes ignored, we need to study it closely.
The canonical example I can bring out is .local/.lan. These TLDs are common in private networks, and if my understanding is correct, the roots get pinged for these TLDs all the time. The root server send NXDOMAIN (with signed NSEC if DO=1) but these hosts still (presumably) work for the locations that use them. If recursive resolvers were hardfailing for non-existant TLDs, we'd see a lot of pain when the root zone was originally signed.
generally speaking, local names like .lan or .local (or .tor) are handled as "hosts file fallback" or as a plugin, and those namespaces rely on an NXD response from DNS in order to open up the next namespace in their local logic path.
Taking the case that I've popped a RSO, and can control one of the root servers zonefile freely, I can delete all DNSSEC data and just send whatever records I like. How much of the validating recursive infrastructure is going to properly hard-fail if they receive unsigned data, or a mix of signed and unsigned data?
all of it. the RDNS config includes a binding from a static key to some subtree of the DNS -- often called a "trust anchor". in bind9 as observed, if it gets unsigned data for a subtree (such as ".") that has a trust anchor defined for it, the stub resolve will get a SERVFAIL answer. if _any_ available validating RDNS does not behave that way, we need to set our hair on fire until we get it either fixed or shamed/decertified.
Speaking from my position on the other end of the stack, I have a bunch of stuff here that either falls over with DNSSEC or actively lies (AD=1) when it's impossible for that to be true.
we need details.
DNSSEC can provide the security we want with regards to data integrity, but I think we're assuming too much of the DNS ecosystem to say that it's effective at preventing root zone tampering without actual data to support that.
I could probably re-purpose some of my original root zone emulator work to actually test this behavior more in-depth but I think that's a separate discussion (esp. with regards to what to test and such). Michael please either continue, or share more detail about prior experiments.
-- P Vixie