Operational Notification: Impact of Stricter Glue Checking

[Victoria Risk]

Hello BIND users,

We have just published an Operational Notification at https://kb.isc.org/docs/strict-glue, which is included below. This is an issue you should be aware of, but it is not a software vulnerability, so there is no associated updated version of BIND. 

- ISC Support

--------------------------
DOCUMENT VERSION: 1.0

POSTING DATE: 15 December 2025

CANONICAL URL: https://kb.isc.org/docs/strict-glue

PROGRAM IMPACTED: BIND

VERSIONS AFFECTED:

* BIND 9.18.41 and later

* BIND 9.20.15 and later

* BIND 9.21.14 and later

DESCRIPTION:

BIND versions released in October 2025 included changes in how BIND
processes referrals in delegations. BIND now only trusts glue records if,
in the associated NS record, the target name (right side) is a subdomain of
the owner name (left side). Glue associated with other names is ignored,
and those names are iteratively resolved instead. This enhances the
security posture of BIND, but some unintended side effects may also be
encountered. Operators should be aware of the potential consequences.

EXAMPLE:

Consider the following hypothetical delegations for <example.org.> from the
<com.> top-level-domain.

The glue in the following delegation would be accepted:

example.org. NS ns1.example.org.
example.org. NS ns2.example.org.
ns1.example.org. A 198.51.100.42
ns2.example.org. A 203.0.113.53

The glue in the following delegation would now be ignored (in prior
versions, it was acceptable). Instead, BIND will now proceed to resolve
<isc.org.>, and obtain NS and A records from the authoritative servers.

example.org. NS ns1.isc.org.
example.org. NS ns2.isc.org.
ns1.isc.org. A 149.20.2.26
ns2.isc.org. A 199.6.1.52

IMPACT:

* Increased outgoing queries:

- BIND resolvers may make an increased number of outgoing queries in
the process of following referrals.

- In some cases, referrals to nameservers will themselves result in a
new nameserver lookup. This can even repeat for longer chains of
nested lookups.

- The increased number of lookups may result in queries which
previously worked, now exceeding configured limits

- This often manifests as a query which gets SERVFAIL on the first
try, but works on a subsequent attempt, after some intermediate
records have already been cached.

* Broken delegations may be uncovered:

- Glue records may have accidentally been hiding problems with the
authoritative records

- Now BIND will find the authoritative records, which may have been
broken all along

- This often manifests as a domain that "was working" yielding
SERVFAIL or behaving inconsistently, after updating a BIND resolver

SOLUTION:

* Zone administrators should:

- Avoid long chains of nested referrals to new sets of name servers

- Avoid cyclic referrals entirely (A refers to B, B refers to A)

- Ensure glue records are consistent with records elsewhere

- Ensure NS records are consistent between parent and child zones

- Review all relevant records when changes are made, to maintain the
above over time

* Resolver administrators should:

- Be alert for trouble resulting from this change

- Adjust configuration parameters as appropriate to find a balance
between operational efficiency and any corresponding security
exposure


The configuration parameters most likely to be involved are:

* max-query-count

Iterative queries sent while resolving a single client query.
Cumulative across CNAME redirections.

* max-recursion-queries

Iterative queries sent while resolving a single name. Each CNAME
redirection begins a new counter at zero.

* max-recursion-depth

Depth of nesting while resolving a single name. For example, when an
NS record targets another domain, and that domain has an NS record
that targets a third name, and so on.

DIAGNOSTICS:

Log messages regarding these and similar limits are logged in the "resolver"
category, at debug level 3. Routinely logging at debug levels is usually
not recommended, due to the significant performance impact. It may be
appropriate on a small scale, such as a test lab, or a server collecting
samples.

To examine why a given name is not resolving, the "delv" tool with the
"+ns" switch can be used (available in BIND 9.20 and later). This
instantiates a full nameserver instance in the delv process, and uses it to
resolve the given query. The "-d" switch can be used to specify the debug
level. For example (all one line):

delv -d3 +ns failing-name.example.com. A | grep -i -e fail -e exceed

WORKAROUNDS:

Resolver administrators who find BIND can no longer resolve names for a
domain with broken glue can use a "static-stub" zone in their "named.conf" to
override published NS records and force a given set of name servers be used
to resolve the domain. For example:

// work around broken glue for "example.com" domain
zone "example.com." {
type static-stub;
server-addresses {
198.51.100.42; // ns1.example.com
203.0.113.53; // ns2.example.com
};
};

Note that long-term use of static-stub is not recommended. It is intended
to be used as a short-term workaround until a problem can be corrected.

DOCUMENT REVISION HISTORY:

* 1.0 Initial publication, 15 December 2025

DO YOU STILL HAVE QUESTIONS?

Questions regarding this notification should be mailed to
bind-security at isc.org or posted as confidential GitLab issues at
https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issue[confidential]=true

ISC SECURITY VULNERABILITY DISCLOSURE POLICY:

Details of our current security advisory policy and practice can be found
in the ISC Software Defect and Security Vulnerability Disclosure Policy at
https://kb.isc.org/docs/aa-00861

HOW TO SUBMIT A BUG REPORT TO ISC:

If you have encountered a problem with BIND (or with any other ISC
software), details on how to submit a report can be found at
https://www.isc.org/reportbug/

LEGAL DISCLAIMER:

Internet Systems Consortium (ISC) is providing this notice on an "AS IS"
basis. No warranty or guarantee of any kind is expressed in this notice and
none should be implied. ISC expressly excludes and disclaims any warranties
regarding this notice or materials referred to in this notice, including,
without limitation, any implied warranty of merchantability, fitness for a
particular purpose, absence of hidden defects, or of non-infringement. Your
use or reliance on this notice or materials referred to in this notice is
at your own risk. ISC may change this notice at any time. A stand-alone
copy or paraphrase of the text of this document that omits the document URL
is an uncontrolled copy. Uncontrolled copies may lack important
information, be out of date, or contain factual errors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-announce/attachments/20251215/2773adbd/attachment-0001.htm>