Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 532
    • Issues 532
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 101
    • Merge requests 101
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • 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
  • #637

Closed
Open
Created Oct 26, 2018 by Cathy Almond@cathyaDeveloper

Proxy-mode secondary zones "lazy-secondary"

Description

As suggested in https://support.isc.org/Ticket/Display.html?id=13653 along with one tactic explicitly requested in #636.

This could be another way to look at meeting the underlying need by means of a proxy or lazy-secondary service?

Request

The end goal is being able to maintain a 'proxy' or 'boundary' authoritative DNS server set for an organization, without needing to explicitly provision the servers as secondaries for all internal domains and subdomains thereof, but instead make use of recursive resolution and cached answers to fulfill (non-recursive) queries from Internet resolvers.

The needs are:

  • Respond authoritatively for everything within the internal domain space
  • Use recursion to obtain answers for zones that have been configured as covered by 'proxy-mode' or 'lazy-secondary', even if client requests do not have 'RD' set, and would not otherwise be permitted to access recursive services
  • Don't break DNSSEC (so no synthesizing of RRsets)
  • Stop chasing CNAMEs where they point outside of the internal domain space
  • Don't recurse at all, outside of the 'proxy-mode' domains and subdomains

Limitations and provisos:

  • The DNS administrator will need be to be responsible for configuring an internal root that enables recursion within the organisation's namespace, but not to beyond that.
  • This set-up is inevitably going to deliver some query responses to the clients that provide other NS RRsets within the organisation that should be unreachable (assuming that the boundary routing is correctly configured).
  • It will not be possible to 'hide' these nameserver names/addresses without breaking DNSSEC.
  • The organisation's boundary routers must deliver queries addressed to the internal routers to the server providing proxy services, and it must accept them, with their original addresses (providing that those addresses are within its managed address space)
  • Query responses should be sent from the address they were originally addressed to - effectively the zones being proxied are also having their servers 'spoofed'
  • Since cache is being used to 'lazy-secondary' authoritative responses, the TTLs would ordinarily vary due to counting down - is there any mechanism to still count down and refresh as normal, but when responding authoritatively, to use the original TTL as obtained from the internal authoritative server?

... and anything else I didn't yet think of

Links / references

Edited Oct 04, 2021 by Ondřej Surý
Assignee
Assign to
Time tracking