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 535
    • Issues 535
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 104
    • Merge requests 104
  • 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
  • #1878
Closed
Open
Created May 26, 2020 by Cathy Almond@cathyaDeveloper

Improve mirror zone implementation by using an iterator for the zone validation step

Tying loosely into Support ticket #16268

We were never able to replicate problems with client resolution during mirror zone refresh (using IXFR), and neither were we able to replicated 'slowness' of updating the zone itself. The suspicion is now that the reported issues were due to something else and what we were seeing was symptom not cause.

However, along the way (and in #1802 (closed) and #1803 (closed)) what was re-exposed is that the validation step for mirror zone updates doesn't take place within an iterator, so it's anti-social, in that it doesn't relinquish the CPU/thread it's working on until it's finished. This is documented as a known feature of the mirror zone implementation, and most of the time it really should not matter (it doesn't take long to validate the entire root zone, which is what the mirror zone implementation was designed for).

This issue ticket is a placeholder to note that we considered this something that we'd like to do, although it's not burningly urgent in the bigger picture of Things That Need To Be Done.

(We also uncovered that the validation step takes place against the entire zone, for each increment being applied (increment = bundled set of changes between SOA start and end RRs, not each individual change), so is potentially inefficient when pulling IXFRs rather than AXFRs from the root servers - but this has to be balanced against the rate of flux of the mirror zone (low for the root zone), so it's probably not worth tackling this too. )

Assignee
Assign to
Time tracking