Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 527
    • Issues 527
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 96
    • Merge requests 96
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & 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 Projects
  • BINDBIND
  • Issues
  • #2434
Closed
Open
Created Jan 26, 2021 by Matthijs Mekking@matthijs🏡Owner

Serve stale when fetch limits are hit

See also #2066 (closed) and #2303 (closed)

Serve stale has been improved a lot by updating configuration defaults, adding options stale-refresh-time and stale-answer-client-timeout. Basically there are now two modes:

  1. Resolve the query, fallback to stale data (stale-answer-client-timeout disabled or positive value).
  2. Prefer stale data in cache, then refresh the data in cache (stale-answer-client-timeout 0).

In case 1, BIND will still not return stale data to the client when fetch limits are hit. This is an indication that the upstream (forwarder, or authoritative server) are under attack, and chances are slim we will get a useful response. In this case, we should also return stale data.

Assignee
Assign to
Time tracking