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
  • #870

Closed
Open
Opened Feb 07, 2019 by Michał Kępień@michalMaintainer

Mirror zone data may not be used during resolution despite being available

Consider a server configured with two mirror zones:

  • bar., which has its data loaded,
  • foo.bar., which is not loaded (has expired, has not yet been transferred etc.)

(To make the example more dramatic/realistic, use . instead of bar. and org. instead of foo.bar..)

If a query then arrives for a name at or below foo.bar, named will not use bar zone data for resolution purposes, even though it is available.

This happens due to the way dns_zt_find() was modified to support mirror zones (see 8d996fd7).

I am opening this ticket mostly to publicly indicate that this is a known issue. While handling this scenario more elegantly is possible1, IMHO it is not critical enough to warrant the added complexity. Feel free to prove me wrong.

For now, I plan to resolve this ticket by adding a code comment explaining the issue. If this ever becomes a real-world problem, we will tackle it then.

  1. e.g. by employing dns_rbt_findnode() instead of dns_rbt_findname() when the options argument passed to dns_zt_find() has the DNS_ZTFIND_MIRROR bit set and then going up the node chain in case the deepest match in the zone table is not loaded ↩

Edited Feb 07, 2019 by Michał Kępień
Assignee
Assign to
BIND 9.13.x
Milestone
BIND 9.13.x
Assign milestone
Time tracking
None
Due date
None
Reference: isc-projects/bind9#870