Skip to content
GitLab
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 577
    • Issues 577
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 116
    • Merge requests 116
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and 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 ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #596
Closed
Open
Issue created Oct 14, 2018 by Cathy Almond@cathyaDeveloper

Option to eliminate cross-zone glue in authoritative server responses

Description

BIND in all currently-supported versions will return any cross-zone or out-of zone glue that it happens to have in its possession in its referral responses to clients.

There are three scenarios when it might do this:

a) The zone administrators added the out-of-zone glue to the zone when adding a delegation NS RRset and associated A/AAAA RRs. This out-of-zone glue is loaded by BIND anyway, isn't returned if queried-for directly (obviously - the server isn't auth for the zone), but it will be returned as glue in referrals to delegated zones whose out-of-zone RRs "need" it.

b) The authoritative server is serving multiple zones (e.g. Verisign serve both .com and .net) and thus quite often the cross-zone glue is available authoritatively.

c) The authoritative server is delegating e.g. bar.com and foo.com where some of foo.com's servers are in the bar.com domain and are also authoritative for bar.com, therefore are included (legitimately) as bar.com's glue.

There are situations where returning out-of-zone glue is undesirable (see references below).

The scenario a) can be mitigated by the zone administrator manually (remove the out-of-zone glue from the zone).

Scenarios b) and c) are currently unavoidable - named returns the out of zone glue regardless.

Request

In its simplest form, just stop adding out-of-zone glue to referral query responses for delegated subdomains.

There is a more complex discussion however. The DNS RFCs currently don't forbid the following scenario:

foo.com.au. IN NS ns1.bar.com.
bar.com.au. IN NS ns1.foo.com.
ns1.foo.com. IN A 1.2.3.4
ns1.bar.com. IN A 1.2.3.5

Because each of the delegated subdomains is dependent on the other one, the glue is required. And that's just a very simple delegation dependency chain - it's possible to make more complicated ones.

So either we need a mechanism for signalling (on a per zone basis) that out-of-zone glue if available should be served. Or, we need to clarify whether or not this scenarios is permissible in the DNS (RFC update - feed the camel..?)

References: https://support.isc.org/Ticket/Display.html?id=13434 https://indico.dns-oarc.net/event/29/contributions/660/attachments/630/1013/2018-10-OARC-Verisign-TLDs.pdf

Links / references

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