Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 634
    • Issues 634
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 90
    • Merge requests 90
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #2445
Closed
Open
Issue created Jan 28, 2021 by Matthijs Mekking@matthijs🏡Developer

NSEC3 iterations considered harmful

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

  1. Set up a validating resolver.

  2. 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).
Edited Oct 11, 2021 by Michał Kępień
Assignee
Assign to
Time tracking