Feature request: harden-below-nxdomain with NSEC3 opt-out

[mnordhoff]

(Hi! I hope it's appropriate to file feature requests here.)

The documentation for harden-below-nxdomain explains:

          Very  old  software might return nxdomain for empty nonterminals
          (that usually happen for reverse IP address lookups),  and  thus
          may  be  incompatible  with  this.   To  try  to avoid this only
          DNSSEC-secure nxdomains are used, because the old software  does
          not  have DNSSEC.  ...  The nxdomain must be secure,
          this means nsec3 with optout is insufficient.

I'd like to request that harden-below-nxdomain also apply to NSEC3 opt-out responses. The critical thing that indicates RFC 8020 compliance is whether the zone is secure or not. Even if the response lacks the AD bit because it's using NSEC3 opt-out, the authoritative DNS server is still implementing DNSSEC and ought to be handling ENTs correctly.

To quote myself making an equivalent feature request in PowerDNS/pdns#9901:

It would complicate the code, but from a user perspective, I think it would be nice if harden-below-nxdomain did also cover NSEC3 opt-out. This is a total guess, but I'd think queries for expired or misspelled domains in NSEC3 opt-out TLDs would be a medium-sized fraction of NXDOMAINs.

But I understand if it's not worth it. :)

[mnordhoff]

There's a solid argument that harden-below-nxdomain shouldn't apply to insecure responses (like NSEC3 opt-out responses) to reduce the damage caused by forged NXDOMAINs. But that's not the argument currently being made in the man page.

[wcawijngaards]

The difference is that for NSEC3 optout, underneath the optout is is nearly impossible to figure out where the zone really is. You may say that it is possible, with debug information, but from the results from the upstream wire not so. We can tell it is optout, but then if it is still 'in zone' or not, is not that easy, certainly not for co-hosted zones where there is an NSEC3 opt-out insecure delegation from one zone to the other.

Your argument that the server may still be newer, and thus it would work fine for unsigned zones as well, is true for a whole bunch of servers. But critically, not all of them, and specifically, for a number of zones hosted under load balancing efforts, like from a cdn, those are from different sourced servers. And those have an issue detecting zones underneath the nxdomain, because they may not know about it.

So if we enable this for nsec3-optout, and then in .com, this happens to a load balanced domain in a CDN, I think it would disappear?

[mnordhoff]

Hmm. Can you trust one label underneath a secure zone?

Hypothetical example: com is a secure TLD. example.com doesn't exist.

Putting aside the issue of foo.example.com or foo.bar.example.com, can you rely on an NSEC3 opt-out NXDOMAIN for example.com?

When I filed this issue, I would have said "yes", but now I'm not entirely sure.

Hypothetical scenario:

com is a secure zone. example.com is an insecure zone cut seemingly hosted on the same nameservers. Verisign actually uses dnsdist to direct queries for example.com/DS to their good nameservers, and other example.com queries to a horrible load balancer. example.com/DS gets an NSEC3 opt-out NODATA response. example.com/A gets NXDOMAIN. www.example.com/A returns real A records.

That case seems possible (but maybe tricky) to distinguish.

[wcawijngaards]

Not sure, without the secure on the NXDOMAIN itself, how to know what type of server it is from.

If we just allow optout ranges for NSEC3, that would be similar to allowing use for unsigned zones. If anything under the nsec3 is allowed. But one label only, not sure, if that would work. And that could depend on individual cases. Is the case you cite something that happens, you think? I would mean you could not really use that NXDOMAIN to harden-below from.