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