GitLab

Summary

BIND doesn't limit, allowing 16-bit unsigned integer number of iterations. Seeing a lot of traffic for a zone with a high iteration number can effectively DDoS the resolver.

CVSS Score: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - 5.3

BIND version used

Affected versions: 9.11, 9.16

Steps to reproduce

1. Set up an authoritative server with a DNSSEC signed zone with high iteration count:

dnssec-signzone -3 - -H 65535 example., then configure named and start

2. Set up a validating resolver.

3. Run a NXDOMAIN style attack

What is the current bug behavior?

Resolver has very low QPS.

What is the expected correct behavior?

Resolver doesn't starve.

Relevant configuration files

To do.

Relevant logs and/or screenshots

N/A

Possible fixes

From the resolver perspective, this situation is actually protocol compliant.

RFC 5155 says:

   A zone owner MUST NOT use a value higher than shown in the table
   below for iterations for the given key size.  A resolver MAY treat a
   response with a higher value as insecure, after the validator has
   verified that the signature over the NSEC3 RR is correct.

                         +----------+------------+
                         | Key Size | Iterations |
                         +----------+------------+
                         | 1024     | 150        |
                         | 2048     | 500        |
                         | 4096     | 2,500      |
                         +----------+------------+

But it also acknowledges this is susceptible to attacks:

12.1.4.  Using High Iteration Values

   Since validators should treat responses containing NSEC3 RRs with
   high iteration values as insecure, presence of just one signed NSEC3
   RR with a high iteration value in a zone provides attackers with a
   possible downgrade attack.

   [...]

   Using a high number of iterations also introduces an additional
   denial-of-service opportunity against servers, since servers must
   calculate several hashes per negative or wildcard response.

Proposed fixes:

When loading a zone (primary server):

• We could error if we try to load a zone with NSEC3 records with too high iteration count.
• Or we could treat it as garbage in/garbage out.

When transferring a zone (secondary server):

• Nothing much we can do about it.

When validating a response from this zone (resolver):

• Treat such NSEC3 records as insecure after validating (as suggested in the RFC).