Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
BIND
BIND
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 591
    • Issues 591
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 113
    • Merge Requests 113
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #1830

Closed
Open
Opened May 08, 2020 by Cathy Almond@cathyaDeveloper

Feature request: Adapt BIND cache management so that fetched RRsets with TTL=0 use a different 'throw-away' cache

Inspired by Support ticket #16297

The problem is the cache can get filled up with TTL=0 records, causing the resolver to 'grind to a halt.'

For BIND resolvers that routinely field a large proportion of client queries that result in authoritative RRsets with TTL=0 (and we only have to look back at other reports where we've had problems making sure that TTL=0 content is handled properly and served solely to the clients making the query originally or which have been added to the fetch via clients-per-query before it has been complete, to know that these environments do exist...), can't we just avoid adding them to cache at all?

Suggestion:

A new TTL=0 cache This would be used as a temporary storage place for all content that comes back with TTL=0 but which needs to persist for the lifetime of the client queries that are waiting for recursion to complete (so might include some intermediate fetch results as well as the answers needed for the client query responses. When serving responses to clients, use both main cache and TTL=0 cache. (OR perhaps there could be a way to flag to the tasks responding to clients that they should also look in TTL=0 cache when assembling the query response)

I would hope, given that the content is due to be thrown away as soon as all the clients have been responded to, that it might be easier to manage this in terms of access control than in main cache.

The big advantage to main cache, is that this content is kept out of it, thus reducing cache flux and cache maintenance overhead involved in adding and then cleaning up these non-persisting RRsets.

(Implementing this would also obviate the need to action #1829 (closed) )

Edited Jul 08, 2020 by Vicky Risk
Assignee
Assign to
January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)
Milestone
January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9) (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: isc-projects/bind9#1830