BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2018-12-11T14:21:09Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/628Remove support for insecure RSAMD52018-12-11T14:21:09ZOndřej SurýRemove support for insecure RSAMD5BIND-9.13.6Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/629Windows Build Errors After !355 (Refactor Message Digest and HMAC API)2018-10-25T21:20:37ZThomas JachWindows Build Errors After !355 (Refactor Message Digest and HMAC API)In order to resolve the build errors caused by !355,
replace
```#include <arpa/inet.h>```
with
```
#ifndef WIN32
#include <arpa/inet.h>
#endif
```
in lib\dns\hmac_link.c
and add
```
<ClInclude Include="..\include\isc\md.h" />
<Cl...In order to resolve the build errors caused by !355,
replace
```#include <arpa/inet.h>```
with
```
#ifndef WIN32
#include <arpa/inet.h>
#endif
```
in lib\dns\hmac_link.c
and add
```
<ClInclude Include="..\include\isc\md.h" />
<ClCompile Include="..\md.c" />
```
to lib\isc\win32\libisc.vcxproj.inhttps://gitlab.isc.org/isc-projects/bind9/-/issues/630Windows - BIND Fails To Start After !853 (FIPS Mode Merges)2018-10-26T00:49:39ZThomas JachWindows - BIND Fails To Start After !853 (FIPS Mode Merges)The following warning is logged on start:
```
FIPS_mode_set failed (crypto failure)
```
```
BIND 9.13.3 (Development Release) <id:cbdb69f4cc>
running on Windows 6 3 build 9600 17415 for x64
built by Visual Studio with 'with-python=no ...The following warning is logged on start:
```
FIPS_mode_set failed (crypto failure)
```
```
BIND 9.13.3 (Development Release) <id:cbdb69f4cc>
running on Windows 6 3 build 9600 17415 for x64
built by Visual Studio with 'with-python=no x64'
compiled by MSVC 1915
compiled with OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
threads support is enabled
```https://gitlab.isc.org/isc-projects/bind9/-/issues/631dns_rdata_compare() for NXT performs case sensitive name comparison2018-10-30T03:59:53ZCathy Almonddns_rdata_compare() for NXT performs case sensitive name comparison### Summary
From https://support.isc.org/Ticket/Display.html?id=13416
9.11.3-S3
### What is the current *bug* behavior?
As reported in the Support ticket:
> I believe ... needs a patch
> pasted below (which, with the subject of this...### Summary
From https://support.isc.org/Ticket/Display.html?id=13416
9.11.3-S3
### What is the current *bug* behavior?
As reported in the Support ticket:
> I believe ... needs a patch
> pasted below (which, with the subject of this report, I believe is
> sufficient to show what's the problem). At the very least, if the
> case sensitive comparison is intentional, the call to
> dns_name_rdatacompare() is redundant and should be removed. Either
> way the code would need some update.
```
diff --git a/lib/dns/rdata/generic/nxt_30.c b/lib/dns/rdata/generic/nxt_30.c
index a155af2..9b3852b 100644
--- a/lib/dns/rdata/generic/nxt_30.c
+++ b/lib/dns/rdata/generic/nxt_30.c
@@ -189,6 +189,9 @@ compare_nxt(ARGS_COMPARE) {
if (order != 0)
return (order);
+ isc_region_consume(&r1, name_length(&name1));
+ isc_region_consume(&r2, name_length(&name2));
+
return (isc_region_compare(&r1, &r2));
}
```
Ensuing dialogue:
> Case sensitive is correct. The name is not down cased for DNSSEC. It is a opaque blob for UPDATE.
>
> --
> Mark Andrews
Submitter:
>
> But RFC4034 specifies NXT as an exception:
>
> 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
> HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
> SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
> the DNS names contained within the RDATA are replaced by the
> corresponding lowercase US-ASCII letters;
>
> Has that been changed since then?
Mark's reply:
> That’s what gets me for doing things from memory while still in bed.
> Yes, we should consume those bytes not that anyone used NXT anymore.
>
> Note that list is wrong, RRSIG and NSEC are not canonicalised as they
> were assigned after the original list of types was released.
>
> Also HINFO does not contain a domain name see Errata.
>
> --
> Mark Andrews, ISC
Submitter:
> Okay, thanks for the confirmation. I agree (or already agreed in this
> report) this is a minor glitch. I just tried to make it sure.
>
> > Note that list is wrong, RRSIG and NSEC are not canonicalised as they
> > were assigned after the original list of types was released.
>
> I agree that having these in the list looks awkward, although I don't
> know if it's really "wrong" (if it is we should probably also report
> it to the RFC errata to prevent any possible interoperability
> problems). But in any case these are not my concern in this report.
> And the BIND 9's implementation for these is at least consistent with
> that interpretation: compare_nsec() does not incorrectly call
> dns_name_rdatacompare(); compare_nsec() and digest_nsec() are
> consistent about handling the next name.
>
> > Also HINFO does not contain a domain name see Errata.
>
> Right.
> FYI: I've just realized RFC6840 updated RFC4034 and excluded NSEC from the list of RRs that require down-casing names in RDATA. Note also that RFC6840 still states down-casing is performed for RRSIG, which is different from the BIND 9's implementation.https://gitlab.isc.org/isc-projects/bind9/-/issues/632EVP_CIPHER_CTX_free and EVP_CIPHER_CTX_new exist in OpenSSL 1.0.12018-10-26T05:05:36ZMark AndrewsEVP_CIPHER_CTX_free and EVP_CIPHER_CTX_new exist in OpenSSL 1.0.1https://gitlab.isc.org/isc-projects/bind9/-/issues/633resource leak in hmac_fromdns2018-10-26T07:04:16ZMark Andrewsresource leak in hmac_fromdns```
*** CID 1440499: Resource leaks (RESOURCE_LEAK)
/lib/dns/hmac_link.c: 363 in hmac_fromdns()
357 memset(hkey->key, 0, sizeof(hkey->key));
358
359 /* Hash the key if the key is longer then chosen MD block size */
360 ...```
*** CID 1440499: Resource leaks (RESOURCE_LEAK)
/lib/dns/hmac_link.c: 363 in hmac_fromdns()
357 memset(hkey->key, 0, sizeof(hkey->key));
358
359 /* Hash the key if the key is longer then chosen MD block size */
360 if (r.length > (unsigned int)isc_md_type_get_block_size(type)) {
361 if (isc_md(type, r.base, r.length, hkey->key, &keylen)
362 != ISC_R_SUCCESS) {
CID 1440499: Resource leaks (RESOURCE_LEAK)
Variable "hkey" going out of scope leaks the storage it points to.
363 return (DST_R_OPENSSLFAILURE);
364 }
365 } else {
366 memmove(hkey->key, r.base, r.length);
367 keylen = r.length;
368 }
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/634Unchecked returns in resolver.c2018-11-05T23:03:06ZMark AndrewsUnchecked returns in resolver.c```
10355 if (fctx->qmin_labels < nlabels) {
10356 /*
10357 * We want to query for qmin_labels from fctx->name
10358 */
10359 dns_fixedname_t fname;
10360 ...```
10355 if (fctx->qmin_labels < nlabels) {
10356 /*
10357 * We want to query for qmin_labels from fctx->name
10358 */
10359 dns_fixedname_t fname;
10360 dns_fixedname_init(&fname);
10361 dns_name_split(&fctx->name,
10362 fctx->qmin_labels,
10363 NULL, dns_fixedname_name(&fname));
CID 1436960 (#1 of 2): Unchecked return value (CHECKED_RETURN) [select issue]
10364 dns_name_dup(dns_fixedname_name(&fname), fctx->mctx,
10365 &fctx->qminname);
10366 fctx->qmintype = dns_rdatatype_ns;
10367 fctx->minimized = true;
10368 } else {
10369 /* Minimization is done, we'll ask for whole qname */
10370 fctx->qmintype = fctx->type;
CID 1436960 (#2 of 2): Unchecked return value (CHECKED_RETURN)
8. check_return: Calling dns_name_dup without checking return value (as is done elsewhere 59 out of 67 times).
10371 dns_name_dup(&fctx->name, fctx->mctx, &fctx->qminname);
10372 fctx->minimized = false;
10373 }
```https://gitlab.isc.org/isc-projects/bind9/-/issues/635unchecked return in query.c2018-10-29T07:21:27ZMark Andrewsunchecked return in query.c```
8694 RUNTIME_CHECK(result == ISC_R_SUCCESS);
8695 dns_rdataset_current(soardataset, &rdata);
CID 1437577 (#1 of 1): Unchecked return value (CHECKED_RETURN)
11. check_return: Calling dns_rdata_tostruct without chec...```
8694 RUNTIME_CHECK(result == ISC_R_SUCCESS);
8695 dns_rdataset_current(soardataset, &rdata);
CID 1437577 (#1 of 1): Unchecked return value (CHECKED_RETURN)
11. check_return: Calling dns_rdata_tostruct without checking return value (as is done elsewhere 169 out of 191 times).
8696 dns_rdata_tostruct(&rdata, &soa, NULL);
```https://gitlab.isc.org/isc-projects/bind9/-/issues/636Selective 'stop' on CNAME-chasing for resolvers2021-10-04T13:27:53ZCathy AlmondSelective 'stop' on CNAME-chasing for resolvers### Description
This feature request is to help organisations who are using recursive servers to 'manage' boundary authoritative DNS services. The scenario specifically, is how to stop resolvers attempting to follow CNAME chains that p...### Description
This feature request is to help organisations who are using recursive servers to 'manage' boundary authoritative DNS services. The scenario specifically, is how to stop resolvers attempting to follow CNAME chains that point outside of the domain (and subdomains of that domain) that are being 'served' this way.
### Request
The scenario is one in which a complex organisation wishes to have all client queries for their authoritative domains (and subdomains) handled solely by a set of nameservers that are Internet-facing. These servers are authoritative for the top level domain(s) but delegate subdomains to other internal servers, who themselves may delegate yet again. It is not possible (for various reasons) for the Internet-facing servers to slave all of the delegated subdomains and sub-sub-domains...
These resolvers, therefore are acting as proxies, and use normal recursion towards the delegated subdomain servers in order to obtain the answers that they need for the clients.
Client queries, as you would expect, are non-recursive (originating from Internet resolvers) but have RD added by means of packet manipulation tools. Similarly, they are also flipping header bit settings again on the way out on the query responses.
One point (there are others - they are not for discussion here) where this design breaks is in handling CNAME chains in some circumstances.
A normal recursive resolver expects to follow a CNAME chain all the way to the final RRset and to return that, along with the CNAME chain itself, to the stub client that queried it with 'RD' set. If it cannot complete that, it will SERVFAIL. A genuine authoritative server will stop attempting to following CNAME chains if they point outside of the zones for which it is authoritative, and will fill the query response with what it has, assuming that the (resolver) client will be able to pick up and make onward queries to other servers to complete the chain.
The 'custom' resolvers in this unusual proxy configuration are only able to resolve names within the organisation's internal namespace. They cannot (and should not - recall that they are emulating authoritative servers) follow CNAMEs that point outside of their domain(s).
But there is currently no mechanism for telling named to stop trying and to return 'what it has so far' when it is configured to be a resolver, so when they encounter 'out of domain' CNAMEs, they fail.
What is wished for, is a configuration option to control this so that a resolver that is masquerading as authoritative can stop CNAME-chasing (probably on a per-domain basis) without SERVFAILing.
This is not an option that would ever be valid for a normal recursive server.
This request has been discussed with engineering - who agreed to do a technical feasibility evaluation only.
### Links / references
https://support.isc.org/Ticket/Display.html?id=13653https://gitlab.isc.org/isc-projects/bind9/-/issues/637Proxy-mode secondary zones "lazy-secondary"2021-12-15T15:20:06ZCathy AlmondProxy-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 https://gitlab.isc.org/isc-projects/bind9/issues/636.
This could be another way to look at meeting the u...### Description
As suggested in https://support.isc.org/Ticket/Display.html?id=13653 along with one tactic explicitly requested in https://gitlab.isc.org/isc-projects/bind9/issues/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 / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/638Record types with empty rdata fields were not being handled correctly.2018-10-30T00:11:23ZMark AndrewsRecord types with empty rdata fields were not being handled correctly.e.g. example.com. APLe.g. example.com. APLMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/639build failing on freebsd2018-10-28T14:18:48ZEvan Huntbuild failing on freebsdIt doesn't like conditionals in makefiles.It doesn't like conditionals in makefiles.https://gitlab.isc.org/isc-projects/bind9/-/issues/640Compile failure on bind-9.11.52019-10-17T00:58:57ZGhost UserCompile failure on bind-9.11.5Hello ISC,
I'm trying to build Bind 9.11.5 here on an older system and I'm seeing a compile failure:
```
colorgcc -I/usr/src/archive/dns/bind -I../.. -I. -I../../lib/dns -Iinclude -I/usr/src/archive/dns/bind/lib/dns/include -I../...Hello ISC,
I'm trying to build Bind 9.11.5 here on an older system and I'm seeing a compile failure:
```
colorgcc -I/usr/src/archive/dns/bind -I../.. -I. -I../../lib/dns -Iinclude -I/usr/src/archive/dns/bind/lib/dns/include -I../../lib/dns/include -I/usr/src/archive/dns/bind/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -D_REENTRANT -DUSE_MD5 -D_GNU_SOURCE -g -O2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c zt.c
In file included from /usr/include/string.h:346,
from /usr/src/archive/dns/bind/lib/isc/include/isc/string.h:26,
from zt.c:23:
/usr/include/bits/string2.h: In function `__mempcpy_small':
/usr/include/bits/string2.h:238: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:242: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:246: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:248: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:252: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:256: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:258: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:262: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:264: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:268: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:270: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:272: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:276: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:278: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h: In function `__strcpy_small':
/usr/include/bits/string2.h:419: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:427: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:432: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:437: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:439: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:444: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h: In function `__stpcpy_small':
/usr/include/bits/string2.h:576: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:580: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:585: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:589: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:594: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:596: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:600: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:602: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:607: warning: pointer of type `void *' used in arithmetic
/usr/include/bits/string2.h:609: warning: pointer of type `void *' used in arithmetic
zt.c: In function `dns_zt_asyncload2':
zt.c:291: parse error before `int'
zt.c:300: `pending' undeclared (first use in this function)
zt.c:300: (Each undeclared identifier is reported only once
zt.c:300: for each function it appears in.)
make[2]: *** [zt.o] Error 1
make[2]: Leaving directory `/usr/src/archive/dns/bind-9.11.5/lib/dns'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/archive/dns/bind-9.11.5/lib'
make: *** [subdirs] Error 1
```
Please note that I had a different Bind 9.11.2-P1 issue on this machine as described in ISC-Bugs #47015. Maybe this is related?
--Davidhttps://gitlab.isc.org/isc-projects/bind9/-/issues/641allow unquoted rpz zone names2018-10-29T16:41:36ZEvan Huntallow unquoted rpz zone namesThis is a nit, but while writing a sample configuration I noticed that RPZ zone names in response-policy statements are required to be in quotation marks. This isn't required elsewhere, and seems inconsistent and unnecessarily fussy.This is a nit, but while writing a sample configuration I noticed that RPZ zone names in response-policy statements are required to be in quotation marks. This isn't required elsewhere, and seems inconsistent and unnecessarily fussy.https://gitlab.isc.org/isc-projects/bind9/-/issues/642isc/stdatomic.h missed from 'make install'2018-10-29T18:35:24ZRay Bellisisc/stdatomic.h missed from 'make install'The header `<isc/stdatomic.h>` isn't installed in the `$(prefix)/include` path when you run `make install`The header `<isc/stdatomic.h>` isn't installed in the `$(prefix)/include` path when you run `make install`https://gitlab.isc.org/isc-projects/bind9/-/issues/643BIND9 with rpz min-update-interval set to 0 can crash if there's a lot of con...2018-10-29T22:12:10ZWitold KrecickiBIND9 with rpz min-update-interval set to 0 can crash if there's a lot of consecutive updatesFixed by !907Fixed by !907Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/644isc_buffer_copyregion() is broken for auto-reallocated buffers2018-10-30T12:52:26ZMichał Kępieńisc_buffer_copyregion() is broken for auto-reallocated buffersWhile `isc_buffer_copyregion()` calls `isc_buffer_reserve()` to ensure the target buffer will have enough available space to append the contents of the source region to it, the variables used for subsequently checking available space are...While `isc_buffer_copyregion()` calls `isc_buffer_reserve()` to ensure the target buffer will have enough available space to append the contents of the source region to it, the variables used for subsequently checking available space are not updated accordingly after that call. This prevents `isc_buffer_copyregion()` from working as expected for auto-reallocated buffers: `ISC_R_NOSPACE` will be returned if enough space is not already available in the target buffer before it is reallocated.BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/645Get rid of vector socket functions2018-11-05T20:05:49ZWitold KrecickiGet rid of vector socket functionsisc_socket_recvv, isc_socket_sendv, isc_socket_sendtov, isc_socket_sendtov2 are used only by httpd and dig, we can get rid of them and simplify socket code.isc_socket_recvv, isc_socket_sendv, isc_socket_sendtov, isc_socket_sendtov2 are used only by httpd and dig, we can get rid of them and simplify socket code.Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/646dnsperf no longer builds with bind2021-09-15T16:12:56ZStephen Morrisdnsperf no longer builds with bindRecent changes to BIND prevent dnsperf (https://gitlab.isc.org/isc-projects/dnsperf) from building.Recent changes to BIND prevent dnsperf (https://gitlab.isc.org/isc-projects/dnsperf) from building.https://gitlab.isc.org/isc-projects/bind9/-/issues/647config.h not copied to BIND installation directory2018-10-30T17:51:13ZStephen Morrisconfig.h not copied to BIND installation directoryWhen BIND is installed in the directory specified by configure's --prefix switch, a number of header files are copied to the installation directory. Three of these files:
* include/isc/strerr.h
* include/isc/hmac.h
* include/isc/md.h
c...When BIND is installed in the directory specified by configure's --prefix switch, a number of header files are copied to the installation directory. Three of these files:
* include/isc/strerr.h
* include/isc/hmac.h
* include/isc/md.h
contain the statement `#include <config.h>`, but config.h is not amongst the files installed.https://gitlab.isc.org/isc-projects/bind9/-/issues/648Windows - !901/!916 Issues2018-11-16T13:56:58ZThomas JachWindows - !901/!916 IssuesThe following changes address the issues.
Add
```
/* Define to 1 if you have the `CRYPTO_zalloc' function. */
@HAVE_CRYPTO_ZALLOC@
/* Define to 1 if you have the `EVP_CIPHER_CTX_free' function. */
@HAVE_EVP_CIPHER_CTX_FREE@
/* Define ...The following changes address the issues.
Add
```
/* Define to 1 if you have the `CRYPTO_zalloc' function. */
@HAVE_CRYPTO_ZALLOC@
/* Define to 1 if you have the `EVP_CIPHER_CTX_free' function. */
@HAVE_EVP_CIPHER_CTX_FREE@
/* Define to 1 if you have the `EVP_CIPHER_CTX_new' function. */
@HAVE_EVP_CIPHER_CTX_NEW@
/* Define to 1 if you have the `EVP_MD_CTX_free' function. */
@HAVE_EVP_MD_CTX_FREE@
/* Define to 1 if you have the `EVP_MD_CTX_new' function. */
@HAVE_EVP_MD_CTX_NEW@
/* Define to 1 if you have the `EVP_MD_CTX_reset' function. */
@HAVE_EVP_MD_CTX_RESET@
/* Define to 1 if you have the `HMAC_CTX_free' function. */
@HAVE_HMAC_CTX_FREE@
/* Define to 1 if you have the `HMAC_CTX_get_md' function. */
@HAVE_HMAC_CTX_GET_MD@
/* Define to 1 if you have the `HMAC_CTX_new' function. */
@HAVE_HMAC_CTX_NEW@
/* Define to 1 if you have the `HMAC_CTX_reset' function. */
@HAVE_HMAC_CTX_RESET@
```
to config.h.win32.
Replace
```
"HAVE_RSA_SET0_KEY",
```
with
```
"HAVE_RSA_SET0_KEY",
"HAVE_CRYPTO_ZALLOC",
"HAVE_EVP_CIPHER_CTX_FREE",
"HAVE_EVP_CIPHER_CTX_NEW",
"HAVE_EVP_MD_CTX_FREE",
"HAVE_EVP_MD_CTX_NEW",
"HAVE_EVP_MD_CTX_RESET",
"HAVE_HMAC_CTX_FREE",
"HAVE_HMAC_CTX_GET_MD",
"HAVE_HMAC_CTX_NEW",
"HAVE_HMAC_CTX_RESET",
```
Replace
```
# check OpenSSL built-in support for DH/DSA/ECDSA/RSA functions
```
with
```
# check OpenSSL built-in support for DH/ECDSA/RSA/CRYPTO_ZALLOC/EVP_CIPHER_CTX/EVP_MD_CTX/HMAC_CTX functions
```
Replace
```
printf "checking OpenSSL built-in support for DH/DSA/ECDSA/RSA functions\n";
```
with
```
printf "checking OpenSSL built-in support for DH/ECDSA/RSA/CRYPTO_ZALLOC/EVP_CIPHER_CTX/EVP_MD_CTX/HMAC_CTX functions\n";
```
Replace
```
printf("This version has no built-in support for DH/ECDSA/RSA functions.\n\n");
```
with
```
printf("This version has no built-in support for DH/ECDSA/RSA/CRYPTO_ZALLOC/EVP_CIPHER_CTX/EVP_MD_CTX/HMAC_CTX functions.\n\n");
```
Replace
```
$configdefh{"HAVE_RSA_SET0_KEY"} = 1;
```
with
```
$configdefh{"HAVE_RSA_SET0_KEY"} = 1;
$configdefh{"HAVE_CRYPTO_ZALLOC"} = 1;
$configdefh{"HAVE_EVP_CIPHER_CTX_FREE"} = 1;
$configdefh{"HAVE_EVP_CIPHER_CTX_NEW"} = 1;
$configdefh{"HAVE_EVP_MD_CTX_FREE"} = 1;
$configdefh{"HAVE_EVP_MD_CTX_NEW"} = 1;
$configdefh{"HAVE_EVP_MD_CTX_RESET"} = 1;
$configdefh{"HAVE_HMAC_CTX_FREE"} = 1;
$configdefh{"HAVE_HMAC_CTX_GET_MD"} = 1;
$configdefh{"HAVE_HMAC_CTX_NEW"} = 1;
$configdefh{"HAVE_HMAC_CTX_RESET"} = 1;
```
in win32utils\Configure.BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/649resolver test failing2018-10-31T11:19:46ZMark Andrewsresolver test failingI:resolver:check that the resolver accepts a reply with empty question section with TC=1 and retries over TCP (67)
I:resolver:failed
qr was not being set in the responses from ans8/ans.pl causing them to be ignored.I:resolver:check that the resolver accepts a reply with empty question section with TC=1 and retries over TCP (67)
I:resolver:failed
qr was not being set in the responses from ans8/ans.pl causing them to be ignored.Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/650There's a slight possibility of race in dig code2021-10-04T13:30:33ZWitold KrecickiThere's a slight possibility of race in dig codein bin/dig/dighost.c query_clear unlinks the query, which sets link->prev/next to (void*) -1, but if the response is still in flight then we'll try to dereference this link in send_done.in bin/dig/dighost.c query_clear unlinks the query, which sets link->prev/next to (void*) -1, but if the response is still in flight then we'll try to dereference this link in send_done.Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/651Add an option to disable qname minimization for selected domains2021-10-04T13:33:45ZWitold KrecickiAdd an option to disable qname minimization for selected domainsNot plannedWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/652Cache snooping is impossible on stub-zones2024-03-01T12:50:10ZRay BellisCache snooping is impossible on stub-zonesWhen a caching BIND server is configured with a static stub zone it's not possible to query the cache with a `-RD` query for any entries at or below that zone cut - the server always returns `REFUSED`.
Tested with `BIND 9.13.3 (Developm...When a caching BIND server is configured with a static stub zone it's not possible to query the cache with a `-RD` query for any entries at or below that zone cut - the server always returns `REFUSED`.
Tested with `BIND 9.13.3 (Development Release) <id:215e3fde22>`.
Since we otherwise do permit cache snooping this should probably be considered a bug.https://gitlab.isc.org/isc-projects/bind9/-/issues/653dig output should not display IDNs unless explicitly requested2024-03-16T06:48:48ZRay Bellisdig output should not display IDNs unless explicitly requestedThe 9.13 behaviour when linked with libidn appears to be a change from earlier versions, where dig will now automagically convert punycode labels into unicode, but worse, fail to do so and terminate with an error if the conversion cannot...The 9.13 behaviour when linked with libidn appears to be a change from earlier versions, where dig will now automagically convert punycode labels into unicode, but worse, fail to do so and terminate with an error if the conversion cannot be done in the current locale.
(as noted by Vixie on the DNS Operations list on 2018/10/31).
I think the default should be to _not_ do this unless the +idnout option is passed.https://gitlab.isc.org/isc-projects/bind9/-/issues/654lame-servers due to qname-minimization2018-11-05T10:14:09ZTony Finchlame-servers due to qname-minimizationAfter the recent qmin refactoring, I noticed a *lot* of lame-servers warnings in my logs, listing the gtld-servers.net IP addresses. These warnings go away if I set `qname-minimization disabled;`
If I turn up the trace level, I can see ...After the recent qmin refactoring, I noticed a *lot* of lame-servers warnings in my logs, listing the gtld-servers.net IP addresses. These warnings go away if I set `qname-minimization disabled;`
If I turn up the trace level, I can see it sending (e.g.) `motherboard.vice.com. AAAA ?` to the gtld-servers then complaining when it gets a referral.
Earlier in the logs (in the space of about 1ms) it logs about doing a `createfind` for *every* gtld-server for this one query. This seems to be much too much! It then goes to find the vice.com NS and DS records, then sends the motherboard.vice.com queries to the gtld-servers. It all seems very confused.BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/655Bind9 Not Detected by system "Linux Mint 19"2018-11-03T02:31:01ZGhost UserBind9 Not Detected by system "Linux Mint 19"I finally figured out how to configure bind9 or so I thought, Because it was working a few months ago, Then when i rebooted my computer after updating bind9 is just acting really weird
I tried running "dig localhost" because It's link...I finally figured out how to configure bind9 or so I thought, Because it was working a few months ago, Then when i rebooted my computer after updating bind9 is just acting really weird
I tried running "dig localhost" because It's linked with /etc/bind/named.conf.default.zones
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
Then my file "/etc/bind/db.local" held It's default
$TTL 604800
@ IN SOA localhost. root.localhost. (
22 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1
My /etc/hosts file has the original 127.0.0.1 localhost and the /etc/bind/named.conf.options file was
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no;
};
So i decided to change 127.0.0.1 to 127.1.0.1 inside of /etc/bind/db.local then restarted bind9 and i got no errors, nothing failed... checkzone came up ok for the file, But when i did a dig localhost the same thing came back 127.0.0.1 So i just copied /etc/bind/db.local to db.locallocal so it couldn't detect it, I restarted bind9, No errors. So i did a dig localhost and it still came back 127.0.0.1
What is happening here, Isn't the point of bind9 to resolve names to IPv4 address's, This isn't only an issue with the localhost, I also tried changing the zone name to a new name and it was not detected, and also made my own file and it resolved my ipv4 from my Ethernet in ifconfig, Not what i told it to resolve in my zone file
By the way i also went inside of /etc/hosts and tried changing 127.0.0.1 to 120.0.1.1https://gitlab.isc.org/isc-projects/bind9/-/issues/656Add support for Utimaco HSM2019-01-01T17:29:25ZOndřej SurýAdd support for Utimaco HSMThere are couple of issues found by my testing:
1. BIND 9.11 and BIND 9.12 fails on DigestUpdate, as Utimaco HSM requires user to be authenticated before any crypto operation is executed and our code checks for MD5 and SHA1 functionalit...There are couple of issues found by my testing:
1. BIND 9.11 and BIND 9.12 fails on DigestUpdate, as Utimaco HSM requires user to be authenticated before any crypto operation is executed and our code checks for MD5 and SHA1 functionality before the login is even attempted
2. ~~BIND 9.13 is broken in some other way (I'll add more info later)~~BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/657Add a seatbelt to IDN2023-11-02T16:32:27ZOndřej SurýAdd a seatbelt to IDNFrom paf on dns-operations:
> Please please please do check what happens when you have bidirectional strings before you decide that having U-LABEL output be the default.
>
> I am the conservative kind that am so nervous over these kind...From paf on dns-operations:
> Please please please do check what happens when you have bidirectional strings before you decide that having U-LABEL output be the default.
>
> I am the conservative kind that am so nervous over these kind of things that I would say "let the user turn on IDN output if the user know what the user is doing".
>
> You might require LOCALE processing, and get different result depending on the shell you use, so "just" look at whether the output is a TTY is something that I think is not enough.
>
> So be careful, and do proper QA, by at least reaching out to people having different directionality by default.
> For bidi issues, please look for example on these old blog posts of mine:
>
> https://stupid.domain.name/node/681
> https://stupid.domain.name/node/682
> https://stupid.domain.name/node/683
>
> You might at least make your code more stable. Add a seatbelt...Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/658$sysconfdir is silently overridden with /etc when "--prefix" is not used2020-01-14T21:16:05ZMichał Kępień$sysconfdir is silently overridden with /etc when "--prefix" is not used@pspacek pointed out to me that when you use `./configure` without `--prefix`, `make install` puts everything under `/usr/local`... except the configuration files. I ran `./configure --help`, which yielded:
```
...
Installation directo...@pspacek pointed out to me that when you use `./configure` without `--prefix`, `make install` puts everything under `/usr/local`... except the configuration files. I ran `./configure --help`, which yielded:
```
...
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
...
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
...
...
```
So far so good. Then I checked `configure.ac` and found [this][1]:
```sh
#
# Special processing of paths depending on whether --prefix,
# --sysconfdir or --localstatedir arguments were given. What's
# desired is some compatibility with the way previous versions
# of BIND built; they defaulted to /usr/local for most parts of
# the installation, but named.boot/named.conf was in /etc
# and named.pid was in /var/run.
#
# So ... if none of --prefix, --sysconfdir or --localstatedir are
# specified, set things up that way. If --prefix is given, use
# it for sysconfdir and localstatedir the way configure normally
# would. To change the prefix for everything but leave named.conf
# in /etc or named.pid in /var/run, then do this the usual configure way:
# ./configure --prefix=/somewhere --sysconfdir=/etc
# ./configure --prefix=/somewhere --localstatedir=/var
#
# To put named.conf and named.pid in /usr/local with everything else,
# set the prefix explicitly to /usr/local even though that's the default:
# ./configure --prefix=/usr/local
#
case "$prefix" in
NONE)
case "$sysconfdir" in
'${prefix}/etc')
sysconfdir=/etc
;;
esac
case "$localstatedir" in
'${prefix}/var')
localstatedir=/var
;;
esac
;;
esac
```
`git blame` indicates that this bit was added in 2000. I think that in 2018 this is wrong and confusing, especially given that `./configure --help` claims that the default value for `$sysconfdir` is `PREFIX/etc`. IMHO we should at least address this in *master*.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/d88efa7e40cbf244ca7886d8ddf0f0361ce8a518/configure.ac#L334-367BIND 9.15.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/659Make task manager more threaded2018-11-15T08:15:44ZWitold KrecickiMake task manager more threadedCurrently task manager is using a single queue for all the runners. It should have a per-runner queue, and possibility to send tasks to specific runners to take advantage of CPU/memory affinity.Currently task manager is using a single queue for all the runners. It should have a per-runner queue, and possibility to send tasks to specific runners to take advantage of CPU/memory affinity.BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/660rndc showzone does not work for all zones2023-12-20T15:37:21ZPetr Špačekpspacek@isc.orgrndc showzone does not work for all zones### Summary
It seems that command `rndc showzone` does not work for certain zones, at very least for built-in zones. This is super inconvenient for scripts which iterate over all zones with intent to get and modify configuration of runn...### Summary
It seems that command `rndc showzone` does not work for certain zones, at very least for built-in zones. This is super inconvenient for scripts which iterate over all zones with intent to get and modify configuration of running process.
### BIND version used
BIND 9.13.0-dev <id:883a9485e9>
commit 883a9485e95916a686e56d81fff5130ac3102953
Date: Thu Feb 15 11:56:13 2018 -0800
### Steps to reproduce
$ rndc showzone 10.in-addr.arpa.
### What is the current *bug* behavior?
```
rndc: 'showzone' failed: failure
```
### What is the expected *correct* behavior?
Ideally equivalent which can be copied into back to config file and does not break anything. (Alternatively a more useful error message.)https://gitlab.isc.org/isc-projects/bind9/-/issues/661rich configuration API2023-11-02T16:32:27ZPetr Špačekpspacek@isc.orgrich configuration API### Description
BIND is hard to configure from outside using APIs, especially when it comes to reading configuration back. It is of course possible to always generate full config file from scratch and restart named process but it has so...### Description
BIND is hard to configure from outside using APIs, especially when it comes to reading configuration back. It is of course possible to always generate full config file from scratch and restart named process but it has some drawbacks:
- previous configuration which requires modification must be stored elsewhere (because named.conf is hard to parse from outside)
- it makes combining manual tweaking in config with automation becomes harder than necessary
### Request
In general I suggest to provide an configuration API which allows user to tweak running instance, and very importantly, also obtain configuration from the running instance. It would make life much easier for people who want to manage BIND using external tools.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/664fetches-per-server quota is lower-bounded to 1 instead of to 2% of quota2019-11-18T18:03:12ZCathy Almondfetches-per-server quota is lower-bounded to 1 instead of to 2% of quotaOn a server with "fetches-per-server 4000;" I was surprised to see a cache dump with the ADB values for a server showing me a quota set to 1.
> ; problem-server.example.com [v4 TTL 2658] [v4 not_found] [v6 unexpected]
> ; 192.0.2.25 [sr...On a server with "fetches-per-server 4000;" I was surprised to see a cache dump with the ADB values for a server showing me a quota set to 1.
> ; problem-server.example.com [v4 TTL 2658] [v4 not_found] [v6 unexpected]
> ; 192.0.2.25 [srtt 948570] [flags 00004000] [ttl -342230] [atr 0.62] [quota 1]
Although we didn't document the lower bound in the ARM (this also needs to be addressed), the KB article ([https://kb.isc.org/docs/aa-01304](https://kb.isc.org/docs/aa-01304)) explaining how fetchlimits work, based on information from Engineering, describes the adjustment algorithm thus:
> The fetches-per-server option sets a hard upper limit to the number of outstanding fetches allowed for a single server. The lower limit is 2% of fetches-per-server, but never below 1. It also allows you to select what to do with the queries that are being limited - either drop them, or send back a SERVFAIL response.
Clearly however, this is not what is in code, as seen in adb.c maybe-adjust-quota(), the last thing we do:
```
/* Ensure we don't drop to zero */
if (addr->entry->quota == 0)
addr->entry->quota = 1;
}
```
The background to this, although very much a corner case, is a mis-configured server that responds to A queries but sends back nothing (so the fetches timeout) for AAAA queries for the same name. This is interacting particularly badly with fetches-per-server because the 'good' queries all get answers and are cached, whereas the 'bad' ones all timeout, SERVFAIL to the client and are not cached.
Turning on servfail cache would mitigate that to some extent.
But nevertheless, the quota going all the way down to 1 (instead of to 80) is making matter much worse.
Please fix, because although this corner case is not our problem as such (the mis-behaving server is being fixed), it is bad that the quota is going down so low that it's very hard to get enough queries to be processed in order to recalculate the atr often enough to be reasonably representative of the query rate to this server.
There was also no evidence of the low quota in the logging - presumably because it had been a rock bottom for longer than the logfile sample I looked at - which was for several hours. It therefore needed a cache dump to identify the problem.
(P.S. I'm assuming it's inefficient to calculate "2% of quota" every time we pass this way, so the bottom limit probably wants calculating initially to use here, and might well be something we want to add to adb on a per-server basis too, in anticipation of future work on fetches-per-server to allow for server-specific quota overrides)
Reference: https://support.isc.org/Ticket/Display.html?id=13720November 2019 (9.11.13, 9.14.8, 9.15.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/665Add "rndc fetchlimits" command to dump currently-active ADB rate-limited serv...2022-07-18T19:01:53ZCathy AlmondAdd "rndc fetchlimits" command to dump currently-active ADB rate-limited servers and zones### Description
Per issue [https://gitlab.isc.org/isc-projects/bind9/issues/664](https://gitlab.isc.org/isc-projects/bind9/issues/664) and Support ticket [https://support.isc.org/Ticket/Display.html?id=13720](https://support.isc.org/Tic...### Description
Per issue [https://gitlab.isc.org/isc-projects/bind9/issues/664](https://gitlab.isc.org/isc-projects/bind9/issues/664) and Support ticket [https://support.isc.org/Ticket/Display.html?id=13720](https://support.isc.org/Ticket/Display.html?id=13720), it can be hard to determine whether or not a specific server is being limited by fetches-per-server if the quota is not actively being adjusted up or down. The most likely scenario where a server is being invisibly limited is when the quota has already dropped to the lowest value and has been sitting there for some time.
### Request
BIND stores the current values of quota and atr (adjusted timeout rate) in the ADB entry for each server IP address.
Whilst dumping cache in order to look at the ADB entries is one way of seeing which servers are currently being rate-limited, this method of checking is not exactly 'accessible' and it would be far nicer to have a feature of rndc that does this and formats them nicely for a DNS administrator or sysadmin.
> ; problem-server.example.com [v4 TTL 2658] [v4 not_found] [v6 unexpected]
> ; 192.0.2.25 [srtt 948570] [flags 00004000] [ttl -342230] [atr 0.62] [quota 1]
Obviously, only dump the ones with a non-zero atr and/or quota < fetches-per-server
We could perhaps do something similar for fetches-per-zone.
The option's documentation should clearly indicate that per-zone rate limiting will reset and resume periodically as the zone to server mapping expires from ADB and is renewed. I believe (though happy to be told otherwise) that active address-based ADB entries will persist and not reset while the server is being queried frequently.
### Links / referencesJuly 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/666Use multiple event loops in socket code2018-11-15T11:35:48ZWitold KrecickiUse multiple event loops in socket codeWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/667[ISC-support #13620] create 'destination-port' option for 'server' statements2019-11-01T10:18:44ZBrian Conry[ISC-support #13620] create 'destination-port' option for 'server' statements### Description
There are times when it is known that the DNS server on a specific address is listening on a non-standard port, but not all of the places where a server can be specified allow an explicit destination port (though some do...### Description
There are times when it is known that the DNS server on a specific address is listening on a non-standard port, but not all of the places where a server can be specified allow an explicit destination port (though some do).
### Request
Before opening an outbound connection BIND already has to look up the destination address in a table of some sort to know if the configuration specifies things like 'bogus' or a source port to use. This seems like the perfect place to add an option to configure a 'destination-port' for that address.
### Links / references
https://support.isc.org/Ticket/Display.html?id=13620https://gitlab.isc.org/isc-projects/bind9/-/issues/668subdomain-delegation to dnsmasq no longer works2018-11-08T04:16:59ZGhost Usersubdomain-delegation to dnsmasq no longer workssee also https://bugzilla.redhat.com/show_bug.cgi?id=1647464
for years it was no problem having a dnsmasq on developer machines and a zone-delegation for subdomains so that they can maintain their development hostnames in /etc/hosts and...see also https://bugzilla.redhat.com/show_bug.cgi?id=1647464
for years it was no problem having a dnsmasq on developer machines and a zone-delegation for subdomains so that they can maintain their development hostnames in /etc/hosts and epose it to the rest of the network with a local dnsmasq
for some Fedora leases now it gives SERVFAIL and teaching they guys maintain maned on their local machines is really overkill
```
cat /var/named/chroot/var/named/zones/example.com.dns | grep openvpn-flow
openvpn-flow IN A 192.168.196.244
flow-home IN NS openvpn-flow
```
```
dig NS flow-home.example.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44943
```
```
dig contentlounge.flow-home.example.com.
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46063
```
as you can clearly see asking the dnsmasq server directly from the host the main-zone is runnign works without issues - so what does named wrong?
```
dig contentlounge.flow-home.example.com. @192.168.196.244
;; ANSWER SECTION:
contentlounge.flow-home.example.com. 604800 IN A 192.168.196.244
```
https://gitlab.isc.org/isc-projects/bind9/-/issues/669Intermittent TCP test failure2019-11-28T12:25:32ZOndřej SurýIntermittent TCP test failureJob [#86348](https://gitlab.isc.org/isc-projects/bind9/-/jobs/86348) failed for 68ca9877921892968c718865363e9115ba5095bf:Job [#86348](https://gitlab.isc.org/isc-projects/bind9/-/jobs/86348) failed for 68ca9877921892968c718865363e9115ba5095bf:BIND 9.15.xWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/670Add static code checks to CI2019-07-22T22:48:11ZMichał KępieńAdd static code checks to CIWe could wire certain tools, e.g. [Coccinelle][1], into CI, in order to automatically detect certain shortcomings of the code being pushed to GitLab. The subject is fairly broad and thus this is basically just a placeholder issue.
A qu...We could wire certain tools, e.g. [Coccinelle][1], into CI, in order to automatically detect certain shortcomings of the code being pushed to GitLab. The subject is fairly broad and thus this is basically just a placeholder issue.
A quick example:
1. Put the following contents into a file called `unreachable.spatch`.
```
@@
@@
INSIST(0);
+ ISC_UNREACHABLE();
... when != ISC_UNREACHABLE();
```
2. Invoke `spatch` (part of Coccinelle) e.g. like this, from the top-level directory of a working copy of the BIND repository:
```
spatch --sp-file unreachable.spatch --dir . --very-quiet
```
The above will output (on standard output) a patch file which can be applied to the source tree in order to ensure all occurrences of `INSIST(0);` are directly followed by an `ISC_UNREACHABLE();` statement. In-place modification can be done with the help of the `--in-place` switch, etc.
[1]: http://coccinelle.lip6.fr/https://gitlab.isc.org/isc-projects/bind9/-/issues/671Delay logging about nxdomain in qname minimization process2018-11-14T20:14:41ZWitold KrecickiDelay logging about nxdomain in qname minimization processWhen doing qname minimization in relaxed mode, if we find an nxdomain result during the process, we issue a "disabling qname minimization for 'domain' due to nxdomain" log message. However, this really could mean that the domain is non e...When doing qname minimization in relaxed mode, if we find an nxdomain result during the process, we issue a "disabling qname minimization for 'domain' due to nxdomain" log message. However, this really could mean that the domain is non existent.
We should only issue this message if the 'final' domain was found.Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/672Get rid of compile-time pk11_flavor and use a runtime one.2018-11-08T17:07:10ZWitold KrecickiGet rid of compile-time pk11_flavor and use a runtime one.When compiling --with-pkcs=(somemodule) pk11_flavor is set, setting some configuration options. However, pkcs11 module path is a configurable option, and e.g. ubuntu compiles by default with softhsm, but user can use the binary with Ulti...When compiling --with-pkcs=(somemodule) pk11_flavor is set, setting some configuration options. However, pkcs11 module path is a configurable option, and e.g. ubuntu compiles by default with softhsm, but user can use the binary with Ultimaco HSM.
The code should detect dynamically what pkcs11 library is being used and act accordingly.https://gitlab.isc.org/isc-projects/bind9/-/issues/673fix windows build resource discover2018-11-09T01:38:46ZMark Andrewsfix windows build resource discoverMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/674Abort when memory allocation or other mandatory resource allocation fails2019-01-09T21:03:29ZEvan HuntAbort when memory allocation or other mandatory resource allocation failsIn discussion at the group meeting in Amsterdam, we decided that going forward, we should have `isc_mem_get()` and `isc_mem_allocate()` abort rather than returning NULL when the system is out of memory.
We should expand this to other re...In discussion at the group meeting in Amsterdam, we decided that going forward, we should have `isc_mem_get()` and `isc_mem_allocate()` abort rather than returning NULL when the system is out of memory.
We should expand this to other resources like:
* pthread mutexBIND-9.13.6https://gitlab.isc.org/isc-projects/bind9/-/issues/675Don't use 'typename'2018-11-14T19:03:11ZMark AndrewsDon't use 'typename'typename is a reserved name in C++. For consistency don't use classname either.typename is a reserved name in C++. For consistency don't use classname either.https://gitlab.isc.org/isc-projects/bind9/-/issues/676isc_result_toid tables not complete2018-11-11T23:51:04ZMark Andrewsisc_result_toid tables not completeMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/687Reduce the overall files we consider copyrightable2018-11-12T15:14:34ZOndřej SurýReduce the overall files we consider copyrightable* configuration files (`CONF-C`)
* zone file (*.db)
And perhaps some more...* configuration files (`CONF-C`)
* zone file (*.db)
And perhaps some more...BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/688prefer kyua over aft-run2018-11-14T11:12:05ZMark Andrewsprefer kyua over aft-runas kyua supports cmocka and aft-run doesn't make kyua the preferred unit test manageras kyua supports cmocka and aft-run doesn't make kyua the preferred unit test managerMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/689dig: fix behavior for -6 used with IPv4-mapped IPv6 addresses2023-11-02T16:32:27ZMichał Kępieńdig: fix behavior for -6 used with IPv4-mapped IPv6 addressesThis is a spin-off from !755. Over there, @each [said][1]:
> If "dig -6" is used but only v4 addresses are in resolv.conf, I would have expected it to use v4-mapped addresses instead of giving up -- that's what it does if an ipv4 addre...This is a spin-off from !755. Over there, @each [said][1]:
> If "dig -6" is used but only v4 addresses are in resolv.conf, I would have expected it to use v4-mapped addresses instead of giving up -- that's what it does if an ipv4 address is specified on the command line with the -6 flag.
To which I [replied][2]:
> What does _not_ make sense to me, though (...), is why we attempt using IPv4-mapped IPv6 addresses when `-6` was specified. Apparently we have been doing this for the past 17 years (since da5795a32a5b28fc8afd59e4887e19ec1252d0d0). I personally find this very confusing. The man page for `dig` says:
>
> ```
> -6
> Use IPv6 only.
> ```
> To me, this means: "`dig` will only communicate using IPv6". But if you use `-6` in conjunction with an IPv4 address, it **will** use IPv4 to send the query. After all, IPv4-mapped IPv6 addresses are not some kind of an IPv6 transition mechanism but merely a way of storing an IPv4 address in an `AF_INET6` socket structure. To me, this looks as if `dig` fails to deliver on its promise not to use IPv4. What is the use case for doing this?
The way I read it, @ondrej [agreed][3] with me:
> I think this is wrong. If -6 is specified I would expect dig to use only IPv6 to communicate with the outside.
Given the above, I propose to, at minimum, change the default in `dig` from `+mapped` to `+nomapped`, the rationale being that `dig` should not implicitly use IPv4 if `-6` was explicitly specified, but it is okay to allow the user to keep using this quirk if it is explicitly requested by passing `+mapped` on the command line.
The somewhat more extreme version of this change would treat command lines in the likes of `dig -6 @192.0.2.1` (or, correspondingly, `dig -6 @::ffff:192.0.2.1`) as errors, i.e. we would completely remove the `+[no]mapped` option, causing `-6` to become a more strict limit.
Any thoughts on this are welcome.
[1]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_21896
[2]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_21997
[3]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_22998Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/690Systematic concurrency testing of named and other BIND 9 tools2023-11-02T16:32:28ZOndřej SurýSystematic concurrency testing of named and other BIND 9 toolsWe should add systematic concurrency testing to our CI, here are some links to get us started:
https://dl.acm.org/citation.cfm?id=1985824
https://www.faculty.ece.vt.edu/chaowang/pubDOC/Wang11HaPSet.pdf
https://insights.sei.cmu.edu/sei...We should add systematic concurrency testing to our CI, here are some links to get us started:
https://dl.acm.org/citation.cfm?id=1985824
https://www.faculty.ece.vt.edu/chaowang/pubDOC/Wang11HaPSet.pdf
https://insights.sei.cmu.edu/sei_blog/2014/10/thread-safety-analysis-in-c-and-c.html
http://diy.inria.fr + http://diy.inria.fr/linux/
http://www.1024cores.net/home/relacy-race-detector
And on Windows:
https://archive.codeplex.com/?p=chesstool
https://pdfs.semanticscholar.org/186e/82657c803bf9f5f58be4d6ff17d1420dbbeb.pdfNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/691Add thread safety testing in the CI2021-03-04T15:27:01ZOndřej SurýAdd thread safety testing in the CIWe should expand our testing in our CI to test for thread safety.
* It will need some annotation for parts that are not synchronized, but safe
* Both Helgrind and ThreadSanitizer should be used
Let's start by doing comparative tests on...We should expand our testing in our CI to test for thread safety.
* It will need some annotation for parts that are not synchronized, but safe
* Both Helgrind and ThreadSanitizer should be used
Let's start by doing comparative tests on the release branches in the Jenkins CI, and build the tools to compare the TS and Helgrind results, and use those tools to have a GitLab CI job that would not allow regressions.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/692"dig @localhost -b 127.0.0.1 ANY" hangs and triggers a crash2019-01-08T10:57:11ZMichael McNally"dig @localhost -b 127.0.0.1 ANY" hangs and triggers a crash### Summary
ISC Support Customer reports a minor problem (via support ticket #13746)
with dig.
### Steps to reproduce
He writes:
If I run dig as follows (while not having anything listen on port 53 on "localhost"):
```
% dig @localhos...### Summary
ISC Support Customer reports a minor problem (via support ticket #13746)
with dig.
### Steps to reproduce
He writes:
If I run dig as follows (while not having anything listen on port 53 on "localhost"):
```
% dig @localhost -b 127.0.0.1 ANY
;; Connection to 127.0.0.1#53(127.0.0.1) for . failed: connection refused.
```
it hangs here, and if I then tries to terminate it, it crashes as follows:
```
^Cdighost.c:4161: INSIST(current_lookup == ((void*)0)) failed, back trace
```
According to his report
* "@localhost"
* "-b 127.0.0.1", and
* (qtype is) "ANY"
are all required in order to trigger the behavior
### What is the current *bug* behavior?
Hangs and then crashes with an INSIST assertion if sent an interrupt signal.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/693Automatically configure DNS64 when forwarding is enabled for IPV4ONLY.ARPA2018-11-15T23:23:25ZMark AndrewsAutomatically configure DNS64 when forwarding is enabled for IPV4ONLY.ARPAWhen the IPV4ONLY.ARPA namespace is covered by a forward directive periodically query for IPV4ONLY.ARPA/AAAA using that forward directive and if AAAA records are found, construct DNS64 prefixes based on the returned addresses. See RFC 70...When the IPV4ONLY.ARPA namespace is covered by a forward directive periodically query for IPV4ONLY.ARPA/AAAA using that forward directive and if AAAA records are found, construct DNS64 prefixes based on the returned addresses. See RFC 7050.
Additionally look for IPV4ONLY.ARPA/APL for exclusion acls. Family 1 for mapped and family 2 for excluded. If not found populate mapped with RFC 1918 addresses and populate excluded with ::ffff:0:0/96 as per RFC 6174.https://gitlab.isc.org/isc-projects/bind9/-/issues/694checklibs libs isc/printf.h check is incomplete2018-11-16T11:37:35ZMark Andrewschecklibs libs isc/printf.h check is incompleteThe git grep should be:
```git grep -wl '\(printf\|snprintf\|sprintf\|vsnprintf\|fprintf\)' lib bin```The git grep should be:
```git grep -wl '\(printf\|snprintf\|sprintf\|vsnprintf\|fprintf\)' lib bin```https://gitlab.isc.org/isc-projects/bind9/-/issues/695dnssec-verify needs to better handle incomplete NSEC3 chains without a NSEC3P...2023-11-02T16:32:28ZMark Andrewsdnssec-verify needs to better handle incomplete NSEC3 chains without a NSEC3PARAMThese sort chains should just be a notice. They could be in the process of being added or removed.
Additionally dnssec-verify should report the chain's parameters when reporting a error or notice.These sort chains should just be a notice. They could be in the process of being added or removed.
Additionally dnssec-verify should report the chain's parameters when reporting a error or notice.Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/696Suppress duplicate NSEC3 chain generation requests via rndc.2023-11-02T16:32:28ZMark AndrewsSuppress duplicate NSEC3 chain generation requests via rndc.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/697Do not attempt to generate DNSSEC records when required keys are not present2022-03-01T09:36:55ZMichael McNallyDo not attempt to generate DNSSEC records when required keys are not present### Description
Recently a customer who is responsible for a very large zone accidentally initiated resigning when no ZSK was present (they keep it off-line and only mount it when required.) The results were not good.
### Request
If ...### Description
Recently a customer who is responsible for a very large zone accidentally initiated resigning when no ZSK was present (they keep it off-line and only mount it when required.) The results were not good.
### Request
If BIND cannot properly perform a signing action because required keys are not present it should fail (loudly) without altering the zone.
### Links / references
https://support.isc.org/Ticket/Display.html?id=13752Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/698cmoka atomic_store and atomic_storeq tests are broken2018-11-17T01:31:46ZMark Andrewscmoka atomic_store and atomic_storeq tests are brokenThey need to wait for the tasks to complete.They need to wait for the tasks to complete.https://gitlab.isc.org/isc-projects/bind9/-/issues/699Prometheus exporter and Grafana template for BIND2020-11-12T00:32:28ZVicky Riskvicky@isc.orgPrometheus exporter and Grafana template for BINDIt would be nice to have a supported Prometheus exporter, so users could more easily get and analyse their BIND metrics in a well-supported open source metrics system. Since we know what the metrics are for, it would also be good to prov...It would be nice to have a supported Prometheus exporter, so users could more easily get and analyse their BIND metrics in a well-supported open source metrics system. Since we know what the metrics are for, it would also be good to provide a related Grafana template for displaying the most useful metrics.
There is already a BIND exporter published by Digital Ocean: https://github.com/digitalocean/bind_exporter which might be good to look at for reference.
- this can wait until after we revise the statistics infrastructure
- NB the Prometheus.io project has some 'Best practices' for exporters (https://prometheus.io/docs/instrumenting/writing_exporters/)
- On the question of whether this should be embedded in BIND or external - if it is possible to avoid running this code if the user doesn't need the feature, that is ideal. So if this is a candidate for a BIND hook extension, that would be ideal.
- obv. it would be a problem if this has a big impact on BIND performance. Overall, one wouldn't want to spend more than 15% of capacity tops on metrics and diagnostics I wouldn't think
- if it is possible to also include some system/platform metrics (I dk how you get them) so that users could correlate things like cpu and memory on the platform, that would be idea. I realize this may be more of a systems engineering than dev task, if there are separate exporters for the platform metrics.
- I see the existing exporters do have complaints about packaging, requests for help with building, all the usual user problems so, we might need to be prepared to provide this in an installable package for at least our subscribers.https://gitlab.isc.org/isc-projects/bind9/-/issues/700Windows builds failing2018-11-16T13:13:27ZMark AndrewsWindows builds failingc:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x32-vs2017\lib\isc\win32\socket.c(2534): error C2198: 'isc_socketmgr_create2': too few arguments for call [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x32-vs2017\lib\isc...c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x32-vs2017\lib\isc\win32\socket.c(2534): error C2198: 'isc_socketmgr_create2': too few arguments for call [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x32-vs2017\lib\isc\win32\libisc.vcxproj]Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/701opts is incorrectly declared inside the loop2018-11-16T22:49:12ZMark Andrewsopts is incorrectly declared inside the loop14367 for (;;) {
assignment: Assigning: opts = true.
14368 bool opts = true;
14369
14370 /* Check for options */
14371 ptr = next_token(lex, text);
14372 if (ptr ==...14367 for (;;) {
assignment: Assigning: opts = true.
14368 bool opts = true;
14369
14370 /* Check for options */
14371 ptr = next_token(lex, text);
14372 if (ptr == NULL) {
14373 return (ISC_R_UNEXPECTEDEND);
14374 }
14375
const: At condition opts, the value of opts must be equal to 1.
dead_error_condition: The condition !opts cannot be true.
14376 if (!opts) {
CID 1441108 (#1 of 1): Logically dead code (DEADCODE)
dead_error_line: Execution cannot reach this statement: nametext = ptr;.
14377 nametext = ptr;Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/702unchecked returns in server.c2018-11-17T00:53:32ZMark Andrewsunchecked returns in server.c```
putstr(text, "zone ");
7605 putmem(text, (const void *) zone_name, zone_name_len);
CID 1441198 (#1 of 2): Unchecked return value (CHECKED_RETURN) [select issue]
7606 putstr(text, " ");
7607 putmem(text, (con...```
putstr(text, "zone ");
7605 putmem(text, (const void *) zone_name, zone_name_len);
CID 1441198 (#1 of 2): Unchecked return value (CHECKED_RETURN) [select issue]
7606 putstr(text, " ");
7607 putmem(text, (const void *) zone_config, zone_config_len);
CID 1441198 (#2 of 2): Unchecked return value (CHECKED_RETURN)
20. check_return: Calling putstr without checking return value (as is done elsewhere 177 out of 185 times).
7608 putstr(text, ";\n");
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/703resource leak in dlz_filesystem_driver.c2018-11-16T23:16:11ZMark Andrewsresource leak in dlz_filesystem_driver.c```645 cd = (config_data_t *) dbdata;
646
647 /* allocate memory for list */
1. alloc_fn: Storage is returned from allocation function isc__mem_get. [Note: The source code implementation of the function has been overrid...```645 cd = (config_data_t *) dbdata;
646
647 /* allocate memory for list */
1. alloc_fn: Storage is returned from allocation function isc__mem_get. [Note: The source code implementation of the function has been overridden by a user model.]
2. var_assign: Assigning: dir_list = storage returned from isc__mem_get(named_g_mctx, 16UL, "../../contrib/dlz/drivers/dlz_filesystem_driver.c", 648U).
648 dir_list = isc_mem_get(named_g_mctx, sizeof(dlist_t));
3. Condition dir_list == NULL, taking false branch.
649 if (dir_list == NULL) {
650 result = ISC_R_NOTFOUND;
651 goto complete_allnds;
652 }
653
654 /* initialize list */
655 ISC_LIST_INIT(*dir_list);
656
4. Condition create_path(zone, NULL, NULL, cd, &basepath) != 0, taking true branch.
657 if (create_path(zone, NULL, NULL, cd, &basepath) != ISC_R_SUCCESS) {
CID 1441211 (#1 of 1): Resource leak (RESOURCE_LEAK)
5. leaked_storage: Variable dir_list going out of scope leaks the storage it points to.
658 return (ISC_R_NOTFOUND);
659 }
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/704named fails to generate missing DNSSEC signatures for NSEC3 records generated...2023-11-02T16:25:43ZMichał Kępieńnamed fails to generate missing DNSSEC signatures for NSEC3 records generated by a previous instanceIf NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If `named` is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records gener...If NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If `named` is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records generated by the previous `named` instance will remain unsigned.
This is due to the fact that when `named` is restarted, NSEC3 chain creation is started from scratch (since database iterator state is not maintained between restarts) and if a pre-existing NSEC3 record is found by `dns_nsec3_addnsec3()`, it will [first remove the old record and then re-add an identical one][1]. This is not an issue in itself but the subsequent call to `do_one_tuple()` involves [invoking `dns_diff_appendminimal()`][2], which in turn removes changes which cancel each other out from the diff structure. In the case of `dns_nsec3_addnsec3()`, the diff structure in question is the one that is subsequently [passed to `dns__zone_updatesigs()`][3], which means that in order for any NSEC3 record to be (re)signed, it must be present in that diff structure; this will be the case for newly created NSEC3 records but not for these which were already present in the zone database; it will also not be an issue for records which were both pre-existing and signed before `named` was restarted since their signatures would simply be preserved.
(Related to [Support RT #13752][4])
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/nsec3.c#L707-716
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/nsec3.c#L318
[3]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/zone.c#L8080-8082
[4]: https://support.isc.org/Ticket/Display.html?id=13752Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/705negative value passed to close on socket.c and resource leak2018-11-23T01:00:33ZMark Andrewsnegative value passed to close on socket.c and resource leak```
5457#if defined(SO_REUSEPORT) && defined(__linux__)
5458 int sock, yes = 1;
1. negative_return_fn: Function socket(2, SOCK_DGRAM, 0) returns a negative number.
2. var_assign: Assigning: signed variable sock = soc...```
5457#if defined(SO_REUSEPORT) && defined(__linux__)
5458 int sock, yes = 1;
1. negative_return_fn: Function socket(2, SOCK_DGRAM, 0) returns a negative number.
2. var_assign: Assigning: signed variable sock = socket.
5459 sock = socket(AF_INET, SOCK_DGRAM, 0);
3. Condition sock < 0, taking true branch.
5460 if (sock < 0) {
CID 1441410 (#1 of 1): Argument cannot be negative (NEGATIVE_RETURNS)
4. negative_returns: sock is passed to a parameter that cannot be negative.
5461 close(sock);
5462 return;
```
also sock is not closed if setsockopt succeeds.
```
CID 1441415 (#1 of 1): Resource leak (RESOURCE_LEAK)
8. leaked_handle: Handle variable sock going out of scope leaks the handle.
5476}
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/706Unchecked isc_mem_get's in dnssec-signzone.c and socket.c2018-11-22T16:03:38ZMark AndrewsUnchecked isc_mem_get's in dnssec-signzone.c and socket.cisc_mem_get() can still return NULL on quota failures even with exiting on malloc() failure.
Note there are multiple failures reported here.
```
673 key = ISC_LIST_NEXT(key, link))
674 {
CID 1441414 (#3 of 3): D...isc_mem_get() can still return NULL on quota failures even with exiting on malloc() failure.
Note there are multiple failures reported here.
```
673 key = ISC_LIST_NEXT(key, link))
674 {
CID 1441414 (#3 of 3): Dereference null return value (NULL_RETURNS)
14. dereference: Dereferencing a null pointer nowsignedby.
675 if (nowsignedby[key->index])
676 continue;
```
```
3752
3753 }
3754
CID 1441417 (#5 of 5): Dereference null return value (NULL_RETURNS)
24. dereference: Dereferencing a pointer that might be null thread->epoll_events when calling watch_fd. [show details]
3755 result = watch_fd(thread, thread->pipe_fds[0], SELECT_POKE_READ);
3756 return (result);
```
```
1900 isc__socket_t *sock;
1901
1. returned_null: isc__mem_get returns null. [Note: The source code implementation of the function has been overridden by a user model.]
2. var_assigned: Assigning: sock = null return value from isc__mem_get.
1902 sock = isc_mem_get(manager->mctx, sizeof(*sock));
1903
CID 1441418 (#1 of 1): Dereference null return value (NULL_RETURNS)
3. dereference: Dereferencing a null pointer sock.
1904 sock->common.magic = 0;
```
```
3942 */
10. returned_null: isc__mem_get returns null. [Note: The source code implementation of the function has been overridden by a user model.]
11. var_assigned: Assigning: manager->threads = null return value from isc__mem_get.
3943 manager->threads = isc_mem_get(mctx, sizeof(isc__socketthread_t)
3944 * manager->nthreads);
3945 isc_mem_attach(mctx, &manager->mctx);
3946
12. Condition i < manager->nthreads, taking true branch.
3947 for (i=0; i < manager->nthreads; i++) {
CID 1441421 (#2 of 2): Dereference null return value (NULL_RETURNS)
13. dereference: Dereferencing a null pointer manager->threads.
3948 manager->threads[i].manager = manager;
```https://gitlab.isc.org/isc-projects/bind9/-/issues/707Remove ISC_MEMFLAG_INTERNAL2021-04-19T07:17:42ZOndřej SurýRemove ISC_MEMFLAG_INTERNALThe default system allocators are much better now on our supported systems, and it should be possible to just remove the `ISC_MEMFLAG_INTERNAL` magic without any performance loss.The default system allocators are much better now on our supported systems, and it should be possible to just remove the `ISC_MEMFLAG_INTERNAL` magic without any performance loss.BIND 9.17 BackburnerOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/708Critical problem in Bind 9.12.3!2018-12-20T13:10:46ZHakan GustafssonCritical problem in Bind 9.12.3!<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
For about a month ago we upgraded to bind 9.12.2-P2 in our production servers and all seems normal for about a couple of weeks. But last weekend, three of our 5 bind servers stops in 12 hours. We upgraded then to 9.12.3 in a hope for the problem to be solved, but this morning one of our servers stops again. When we start the server again all seems normal.
Good to know is that for about 48 hours before the first problem we run into for a week ago, I had change the dnssec-validation auto; to dnssec-validation no; on all the servers that stops. I did that to troubleshoot a domain we couldn't reach.
### BIND version used
```
BIND 9.12.3 <id:6c8e92c>
running on Linux x86_64 2.6.32-754.6.3.el6.x86_64 #1 SMP Tue Sep 18 10:29:08 EDT 2018
built by make with '--prefix=/service/dns/bind-9.12.3' '--sysconfdir=/data/dns/named' '--localstatedir=/var' '--with-openssl=/service/dns/openssl' '--enable-threads' '--enable-ipv6' '--with-libxml2' '--with-randomdev=/dev/urandom'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-23)
compiled with OpenSSL version: OpenSSL 1.0.2p 14 Aug 2018
linked to OpenSSL version: OpenSSL 1.0.2p 14 Aug 2018
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20706
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.3
threads support is enabled
```
### Steps to reproduce
We don't know.
### What is the current *bug* behavior?
The server stops.
### What is the expected *correct* behavior?
Not relevant here.
### Relevant configuration files
```
options {
directory "/data/dns/named";
listen-on {
"interfaces";
};
listen-on-v6 {
"interfaces";
};
version "hakan 181112";
allow-recursion {
"umu";
};
dnssec-enable yes;
dnssec-validation no;
query-source address 130.239.4.100 port 0;
recursion yes;
allow-transfer {
"transferservers";
};
```
### Relevant logs and/or screenshots
```
18-Nov-2018 02:11:38.455 general: critical: rbtdb.c:1509: fatal error:
18-Nov-2018 02:11:38.455 general: critical: RUNTIME_CHECK(rbtdb->next_serial != 0) failed
18-Nov-2018 02:11:38.455 general: critical: exiting (due to fatal error in library)
```
### Possible fixes
Nonhttps://gitlab.isc.org/isc-projects/bind9/-/issues/709Get rid of message catalogs2019-01-09T23:07:57ZOndřej SurýGet rid of message catalogsThe message catalogs in BIND are incomplete and something you usually don't expect from network daemon anyway.The message catalogs in BIND are incomplete and something you usually don't expect from network daemon anyway.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/710AddressSanitizer: heap-buffer-overflow socket_test.c:104 in event_done2018-11-19T17:02:43ZOndřej SurýAddressSanitizer: heap-buffer-overflow socket_test.c:104 in event_doneI found this while working on #707 and after some thinking about what I did wrong in the MR, I realised that I did nothing wrong and this is a bug hidden by small allocations allocator and it could be reproduced by `CFLAGS="-fsanitize=ad...I found this while working on #707 and after some thinking about what I did wrong in the MR, I realised that I did nothing wrong and this is a bug hidden by small allocations allocator and it could be reproduced by `CFLAGS="-fsanitize=address,undefined -DISC_MEM_USE_INTERNAL_MALLOC=0 -Os -g" ./configure --with-cmocka` and running `lib/isc/tests/socket_test`.
One more reason why #707 will be useful.
```
=================================================================
==49218==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c0000002fc at pc 0x000109aa74f1 bp 0x7000089a8c90 sp 0x7000089a8c88
READ of size 4 at 0x60c0000002fc thread T21
#0 0x109aa74f0 in event_done socket_test.c:104
#1 0x109b27382 in dispatch task.c:1116
#2 0x109b1b340 in run task.c:1293
#3 0x7fff7b1b9338 in _pthread_body (libsystem_pthread.dylib:x86_64+0x3338)
#4 0x7fff7b1bc2a6 in _pthread_start (libsystem_pthread.dylib:x86_64+0x62a6)
#5 0x7fff7b1b8444 in thread_start (libsystem_pthread.dylib:x86_64+0x2444)
Address 0x60c0000002fc is a wild pointer.
SUMMARY: AddressSanitizer: heap-buffer-overflow socket_test.c:104 in event_done
Shadow bytes around the buggy address:
0x1c1800000000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x1c1800000010: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x1c1800000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
0x1c1800000030: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x1c1800000040: 00 00 00 00 00 00 01 fa fa fa fa fa fa fa fa fa
=>0x1c1800000050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
0x1c1800000060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c1800000070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c1800000080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c1800000090: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c18000000a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Thread T21 created by T0 here:
#0 0x109ec21cd in wrap_pthread_create (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4f1cd)
#1 0x109b8af27 in isc_thread_create thread.c:65
#2 0x109b1a6ed in isc_taskmgr_create task.c:1380
#3 0x109aa859c in isc_test_begin isctest.c:89
#4 0x109aa2166 in _setup socket_test.c:51
#5 0x109e6ab17 in cmocka_run_one_test_or_fixture (libcmocka.0.dylib:x86_64+0x5b17)
#6 0x109e68ec2 in _cmocka_run_group_tests (libcmocka.0.dylib:x86_64+0x3ec2)
#7 0x7fff7afc708c in start (libdyld.dylib:x86_64+0x1708c)
==49218==ABORTING
Abort trap: 6
```
Marking as confidential as I have no idea about the impact of this one (is the bug only in the test or in the library?), but it affects v9.10+ that have the test (version <= 9.9 doesn't have the test nor DSCP support).BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/711LeakSanitizer: detected memory leaks2018-11-19T06:57:35ZOndřej SurýLeakSanitizer: detected memory leaks`lib/isc/tests/lex_test.c` reports:
```
=================================================================
==897==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 658 byte(s) in 2 object(s) allocated from:
#0 0x7f58a314ced...`lib/isc/tests/lex_test.c` reports:
```
=================================================================
==897==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 658 byte(s) in 2 object(s) allocated from:
#0 0x7f58a314ced0 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f58a2d5e08f in default_memalloc /builds/isc-private/bind9/lib/isc/mem.c:720
Indirect leak of 4440 byte(s) in 10 object(s) allocated from:
#0 0x7f58a314ced0 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f58a2d5e08f in default_memalloc /builds/isc-private/bind9/lib/isc/mem.c:720
SUMMARY: AddressSanitizer: 5098 byte(s) leaked in 12 allocation(s).
```BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/712LeakSanitizer: detected memory leaks in delv2018-11-19T16:38:56ZOndřej SurýLeakSanitizer: detected memory leaks in delvWith gcc 8, the LeakSanitizer reports:
```
=================================================================
==20969==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 201 byte(s) in 1 object(s) allocated from:
#0 0x7f260a...With gcc 8, the LeakSanitizer reports:
```
=================================================================
==20969==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 201 byte(s) in 1 object(s) allocated from:
#0 0x7f260aecaed0 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f2608b4a08f in default_memalloc /builds/isc-private/bind9/lib/isc/mem.c:720
Indirect leak of 4189 byte(s) in 24 object(s) allocated from:
#0 0x7f260aecaed0 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f2608b4a08f in default_memalloc /builds/isc-private/bind9/lib/isc/mem.c:720
SUMMARY: AddressSanitizer: 4390 byte(s) leaked in 25 allocation(s).
```
and the dnssec and mkeys tests fail: https://gitlab.isc.org/isc-private/bind9/-/jobs/99009
Both are using `delv` for the tests.BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/713Use atomics instead of locks in isc_mem2019-05-10T21:20:28ZOndřej SurýUse atomics instead of locks in isc_memBIND 9.15.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/715side effect in assertion in name_test.c2018-11-22T23:19:02ZMark Andrewsside effect in assertion in name_test.c625
626 p1 = l1.base;
627 p2 = l2.base;
628 for (j = 0; j < l1.length; j++) {
CID 1441457 (#1 of 1): Side effect in assertion (ASSERT_SIDE_EFFECT)
assert_side_effect: Argument p1++ of _as...625
626 p1 = l1.base;
627 p2 = l2.base;
628 for (j = 0; j < l1.length; j++) {
CID 1441457 (#1 of 1): Side effect in assertion (ASSERT_SIDE_EFFECT)
assert_side_effect: Argument p1++ of _assert_int_equal() has a side effect. The containing function might work differently in a non-debug build.
629 assert_int_equal(*p1++, *p2++);
630 }Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/716remove logically dead code try #22018-11-22T22:17:44ZMark Andrewsremove logically dead code try #214438
cond_const: Condition is_option, taking true branch. Now the value of is_option is equal to 1.
const: At condition is_option, the value of is_option must be equal to 1.
dead_error_condition: The condition !is_opti...14438
cond_const: Condition is_option, taking true branch. Now the value of is_option is equal to 1.
const: At condition is_option, the value of is_option must be equal to 1.
dead_error_condition: The condition !is_option cannot be true.
14439 if (!is_option) {
CID 1441449 (#1 of 1): Logically dead code (DEADCODE)
dead_error_line: Execution cannot reach this statement: nametext = ptr;.
14440 nametext = ptr;BIND-9.13.5Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/717bin/named/server.c:load_zones can leak memory2018-11-22T22:57:20ZMark Andrewsbin/named/server.c:load_zones can leak memory```
9373 isc_task_endexclusive(server->task);
CID 1438877 (#1 of 1): Resource leak (RESOURCE_LEAK)
14. leaked_storage: Variable zl going out of scope leaks the storage it points to.
9374 return (result);
``````
9373 isc_task_endexclusive(server->task);
CID 1438877 (#1 of 1): Resource leak (RESOURCE_LEAK)
14. leaked_storage: Variable zl going out of scope leaks the storage it points to.
9374 return (result);
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/718Backquotes in config.h.win322023-03-16T11:03:07ZThomas JachBackquotes in config.h.win32A few comments in config.h.win32 contain backquotes instead of single quotes.A few comments in config.h.win32 contain backquotes instead of single quotes.https://gitlab.isc.org/isc-projects/bind9/-/issues/719Make isc_results static2021-10-07T06:48:12ZWitold KrecickiMake isc_results staticCurrently there's a dynamic list of results handled by lib/isc/result.c, and e.g. isc_result_totext requires a lock.
Since we don't have any external users now, and nobody will be adding any results from the outside, we can move all the...Currently there's a dynamic list of results handled by lib/isc/result.c, and e.g. isc_result_totext requires a lock.
Since we don't have any external users now, and nobody will be adding any results from the outside, we can move all the result codes from libdns, ns, isccfg, etc. to libisc - and make the list static.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/720model _assert_true() for coverity2018-11-21T02:37:11ZMark Andrewsmodel _assert_true() for coverityMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/721Performance impact of various features2022-06-03T10:15:20ZVicky Riskvicky@isc.orgPerformance impact of various features### Description
ISC support gets a lot of questions about how to improve BIND server performance, and whether enabling a specific feature will improve or degrade performance.
Users considering enabling various features, including thos...### Description
ISC support gets a lot of questions about how to improve BIND server performance, and whether enabling a specific feature will improve or degrade performance.
Users considering enabling various features, including those intended to improve performance, have no guidelines about what to expect. Today, all they can do is enable the feature and wait and see if performance goes up or down. Operators of highly available systems can't be expected to experiment on production servers when there is a performance problem.
Features that do or could be expected to impact performance include: RRL, fetches per server, minimal responses, prefetch, with-tuning-large, dnstap, query logging, logging level settings, DNSSEC validation(?), RPZ (?), <add others>
### Request
Realizing that local traffic and platform will affect the results, can we profile these features in a lab setting and provide some rules of thumb on the likely impact such as:
* enabling this feature is likely to cost you 8 - 12% QPS performance?
* enabling this feature is likely to improve performance 2 - 5% if you have, eg. a large number of zones with few records in each
* enabling this feature is likely to chew up another x% of your memory (in the XYZ scenario)
It would be very helpful to figure out a way to profile resolvers as well as authoritative servers. I realize this is a hard problem and would require getting a query sample from some operator(s), possibly via OARC (to ensure anonymity).
the interesting metrics include:
- queries per second that can be successfully responded to
- memory utilization (platform statistic)
- cache hit rateNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/722Refactor RBT2023-10-31T11:31:45ZOndřej SurýRefactor RBT(This is just a placeholder for future ideas for refactoring some RBT...)
Since RBT was invented in seventies, there has been some improvements to the algorithm since, namely:
* Lock-Free Red-Black Trees Using CAS
* https://www.cs.um...(This is just a placeholder for future ideas for refactoring some RBT...)
Since RBT was invented in seventies, there has been some improvements to the algorithm since, namely:
* Lock-Free Red-Black Trees Using CAS
* https://www.cs.umanitoba.ca/~hacamero/Research/RBTreesKim.pdf
* http://swapnil-pimpale.github.io/lock-free-BST/
* Left-leaning Red-Black Trees:
* http://www.cs.princeton.edu/~rs/talks/LLRB/RedBlack.pdf
* http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.139.282
* http://www.cs.princeton.edu/~rs/talks/LLRB/LLRB.pdf
* http://www.mew.org/~kazu/proj/red-black-tree/
* http://25thandclement.com/~william/projects/llrb.h.html
* OpenBSD's `<sys/tree.h>`:
* https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/sys/tree.hBIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/723Use thread annotations2018-11-22T10:30:00ZOndřej SurýUse thread annotationsClang 8 (and maybe earlier) has support for Thread Safety Analysis:
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
that allows thread annotations like `GUARDED_BY`, `REQUIRES(...)` and others to annotate variables, pointers and ...Clang 8 (and maybe earlier) has support for Thread Safety Analysis:
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
that allows thread annotations like `GUARDED_BY`, `REQUIRES(...)` and others to annotate variables, pointers and functions with hints for the analysis engine.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/724Make ISC_LIST implementation lockless2023-11-02T16:32:29ZOndřej SurýMake ISC_LIST implementation locklessHere's a good implementation: http://concurrencykit.org/doc/ck_queue.html which needs to be rewritten using C11 atomics instead of `ck_pr`.Here's a good implementation: http://concurrencykit.org/doc/ck_queue.html which needs to be rewritten using C11 atomics instead of `ck_pr`.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/725Use better test framework for system tests2020-04-29T12:28:10ZOndřej SurýUse better test framework for system testsThis was previously sharness for shell tests, but it looks that using pytest is much better choice.This was previously sharness for shell tests, but it looks that using pytest is much better choice.May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/726Build fix for BIND 9.13.4 on NetBSD2018-11-22T14:43:57ZHåvard EidnesBuild fix for BIND 9.13.4 on NetBSD### Description
BIND 9.13.4 fails to build on NetBSD 8.0 for a couple of reasons:
- The newish pthread-using module is not adapted to NetBSD; one function is missing,
another has a different way of setting up the `cpuset_t`, and a ...### Description
BIND 9.13.4 fails to build on NetBSD 8.0 for a couple of reasons:
- The newish pthread-using module is not adapted to NetBSD; one function is missing,
another has a different way of setting up the `cpuset_t`, and a third has an extra arg.
- The `configure.ac` script can be simplified to be the same as for FreeBSD and OpenBSD;
it does not work as is when using libtool because `ld` doesn't recognize the `-pthread` flag
when building in `bin/tests/system/dyndb/driver`, ref.
libtool: link: ld -Bshareable -x -o .libs/sample.so .libs/db.o .libs/driver.o .libs/instance.o .libs/lock.o .libs/log.o .libs/syncptr.o .libs/zone.o -L/usr/lib -L/usr/pkg/lib ../../../../../lib/dns/.libs/libdns.so /usr/local/src/bind-9.13.4/lib/isc/.libs/libisc.so -lgssapi ../../../../../lib/isc/.libs/libisc.so -lcrypto /usr/pkg/lib/libxml2.so -lz -llzma -lm -pthread -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib
ld: unrecognized option '-pthread'
ld: use the --help option for usage information
### Request
Apply the diff which is attached below, or something along these lines.[bind-9.13.4.diff](/uploads/ec4ab2db5af29f898db850eacc67ef25/bind-9.13.4.diff)
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/727Follow-up from "Bound tasks for resolver; Task quantum tweaks."2022-07-01T00:53:36ZWitold KrecickiFollow-up from "Bound tasks for resolver; Task quantum tweaks."The following discussion from !1117 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1117#note_32136): (+4 comments)
> What would happen if this would be the defaul...The following discussion from !1117 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1117#note_32136): (+4 comments)
> What would happen if this would be the default?
> ```
> if (c < 0) {
> c = task->threadid;
> }
> ```
> and just drop the `task->bound;` variable?Not plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/728Inconsistent lock ordering?2019-12-12T11:57:41ZStephen MorrisInconsistent lock ordering?As part of the process of seeing whether Helgrind will produce any useful output for BIND, I've been looking at the lock order conflict reports it has produced. These are cases where Helgrind has detected that a pair of locks (or a cycle...As part of the process of seeing whether Helgrind will produce any useful output for BIND, I've been looking at the lock order conflict reports it has produced. These are cases where Helgrind has detected that a pair of locks (or a cycle of locks) was acquired in a particular order in one part of the program and in another order elsewhere, something that could lead to a deadlock. (See the [relevant part of the Helgrind documentation](http://valgrind.org/docs/manual/hg-manual.html#hg-manual.lock-orders) for information about how Helgrind detects inconsistent lock ordering.)
I ran BIND (set up as a recursive server) through Helgrind for 60 minutes, sending it a moderately heavy query load. The attached file gives the first three lock order violation reports in the output. (The full output can be be found on the [internal ISC Jenkins web site](https://jenkins.isc.org/view/BIND-jobs_testing/job/bind9-helgrind/18). I'd like to get an opinion as to whether these are useful reports (and whether they reveal significant problems) before we spend too much time on this.
The configuration used for the test was:
* BIND instance 1: the configuration defined a "root" zone with a single TLD, served by BIND instance 2.
* Bind instance 2: serves a single (signed) zone of 100,000 records.
* Bind instance 3: set up as a recursive server. The queries to it from queryperf comprises A queries: 95% were for records in the zone served by instance 2, the remainder were for names that did not exist.
FWIW, my take on the lock reports is:
*==7409== Thread \#8: lock order "0x111CA668 before 0x81EE348" violated*
These locks appear to be associated with a zone (the "root" zone?) and view (the default view?) created during the call to load_configuration. In one part of load_configuration a call is made to dns_view_setviewcommit which acquires the
locks in one order. Later on, a call is made to dns_zone_setview which acquires the locks in the reverse order.
This is not really a problem in the test as only one thread is executing load_configuration and (presumably) no other threads are able to access the locks and structures they protect until it returns. However, I don't know whether this would hold true in a system where a reconfiguration is executed. (No reconfigurations were executed while the test was running.)
*==7409== Thread \#8: lock order "0x112935E8 before 0x81EE348" violated*
This seems similar to the previous report: both locks are accessed from within load_configuration. dns_view_setviewcommit acquires the locks in one order, but dns_zone_setview acquires them in the reverse order.c, although the detailed call stack is different.
*==7409== Thread \#4: lock order "0x11B3C068 before 0x10E2CFC8" violated*
Looking at lock 0x10E2CFC8, this is stored in res->buckets[bucketnum].lock in the function validated (resolver.c, line 5292) where res is of type dns_resolver_t*. When accessed in dns_resolver_createfetch (validator.c, line 10499) it is accessed via res->lock (again res is of type dns_resolver_t*). This makes me wonder whether the lock has been created, destroyed and another lock created at the same address. I don't believe that Helgrind would detect that.
[locks3.txt](/uploads/e9b64cc10d9b5171aa8305f76f93dfc8/locks3.txt)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/729init_hasreuseport will not work on systems w/o IPv42018-11-23T04:31:35ZMark Andrewsinit_hasreuseport will not work on systems w/o IPv4Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/730Python module installation is broken in BIND 9.13.42019-01-31T07:42:20ZMichał KępieńPython module installation is broken in BIND 9.13.4The fix for #601 introduced by !980 breaks Python module installation due to setting `PYTHON_INSTALL_DIR` and `PYTHON_INSTALL_LIB` to `unspec` and `--install-dir=unspec`, respectively, when `--with-python-install-dir` is not used.
This ...The fix for #601 introduced by !980 breaks Python module installation due to setting `PYTHON_INSTALL_DIR` and `PYTHON_INSTALL_LIB` to `unspec` and `--install-dir=unspec`, respectively, when `--with-python-install-dir` is not used.
This prevents BIND 9.13.4 packages with Python support from being built:
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/epel-7-ppc64le/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/epel-7-x86_64/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-27-i386/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-27-ppc64le/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-27-x86_64/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-28-i386/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-28-ppc64le/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-28-x86_64/00827985-isc-bind/builder-live.log
I implemented a [workaround][1] in the `*.spec` file to fix RPM builds but this problem should be properly addressed in the BIND repository.
[1]: https://gitlab.isc.org/isc-packages/rpms/bind/commit/f1a57c873729d145f7ce72315120d6e37a7a8980BIND-9.13.5Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/731Catalog zone incorrect logging2018-11-28T12:31:26ZTony FinchCatalog zone incorrect loggingI changed the authoritative servers for a number of zones in my catalog zone; when my secondary server (BIND 9.13.4) picked up the new catalog zone, it logged the change incorrectly.
```
2018-11-23.11:59:05.410 general: info: catz: upda...I changed the authoritative servers for a number of zones in my catalog zone; when my secondary server (BIND 9.13.4) picked up the new catalog zone, it logged the change incorrectly.
```
2018-11-23.11:59:05.410 general: info: catz: updating catalog zone 'catz.arpa.cam.ac.uk' with serial 1542974068
2018-11-23.11:59:05.410 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
2018-11-23.11:59:05.411 general: info: catz: modifying zone '88.60.193.in-addr.arpa' from catalog 'catz.arpa.cam.ac.uk' - success
```
The zones that changed were the ones listed below, so `named` logged the correct number of zones, it just logged the wrong names...
I have checked that my secondary is correctly transferring `maths.cam.ac.uk` from its new servers, and `88.60.193.in-addr.arpa` is still being transferred from its (different) upstreams. So it seems to be just the logging that is wrong.
```
damtp.cam.ac.uk
dpmms.cam.ac.uk
maths.cam.ac.uk
newton.cam.ac.uk
statslab.cam.ac.uk
16.111.131.in-addr.arpa
17.111.131.in-addr.arpa
18.111.131.in-addr.arpa
20.111.131.in-addr.arpa
24.111.131.in-addr.arpa
145.111.131.in-addr.arpa
```https://gitlab.isc.org/isc-projects/bind9/-/issues/732BIND 9.13.4 does not compile on CentOS 6 (i386)2018-11-26T10:22:36ZMichał KępieńBIND 9.13.4 does not compile on CentOS 6 (i386)Commit 22e5231f99ceac8371ac0e74a114df64aa3fc868 [causes the `_mm_pause()` intrinsic to be used on i386 machines][1]. Newer toolchains seem to be fine with this; the stock one available on CentOS 6 for i386 - [not so much][2].
[1]: http...Commit 22e5231f99ceac8371ac0e74a114df64aa3fc868 [causes the `_mm_pause()` intrinsic to be used on i386 machines][1]. Newer toolchains seem to be fine with this; the stock one available on CentOS 6 for i386 - [not so much][2].
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/ad0b4e9d416a7802904eef235a55fb07a36743bb/lib/isc/rwlock.c#L47-49
[2]: https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/epel-6-i386/00828410-isc-bind/builder-live.logBIND-9.13.5Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/733Rewrite various logging functions to variadic macros...2023-11-02T16:32:29ZOndřej SurýRewrite various logging functions to variadic macros...There's a lot of pre-C99 code that defines extra logging functions in different places in the code, like this:
```
static void
manager_log(isc__socketmgr_t *sockmgr,
isc_logcategory_t *category, isc_logmodule_t *module, int l...There's a lot of pre-C99 code that defines extra logging functions in different places in the code, like this:
```
static void
manager_log(isc__socketmgr_t *sockmgr,
isc_logcategory_t *category, isc_logmodule_t *module, int level,
const char *fmt, ...) ISC_FORMAT_PRINTF(5, 6);
static void
manager_log(isc__socketmgr_t *sockmgr,
isc_logcategory_t *category, isc_logmodule_t *module, int level,
const char *fmt, ...)
{
char msgbuf[2048];
va_list ap;
if (! isc_log_wouldlog(isc_lctx, level))
return;
va_start(ap, fmt);
vsnprintf(msgbuf, sizeof(msgbuf), fmt, ap);
va_end(ap);
isc_log_write(isc_lctx, category, module, level,
"sockmgr %p: %s", sockmgr, msgbuf);
}
```
With C99, this could be rewritten using variadic macros like this:
```
#define manager_log(sockmgr, category, module, level, fmt, ...) \
if (isc_log_wouldlog(isc_lctx, level)) { \
isc_log_write(isc_lctx, category, module, level, "sockmgr %p: " # fmt, sockmgr, __VA_ARGS__); \
}
```
Using variadic macros would lead to having fewer functions.
@joey, could you take care of it please?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/734Follow-up from "WIP: Fix compilation on CentOS 6 (i386)"2021-10-04T13:44:49ZOndřej SurýFollow-up from "WIP: Fix compilation on CentOS 6 (i386)"The following discussion from !1129 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1129#note_32353): (+1 comment)
> If we are doing this, we probably should fix t...The following discussion from !1129 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1129#note_32353): (+1 comment)
> If we are doing this, we probably should fix the ARMv6 builds too.https://gitlab.isc.org/isc-projects/bind9/-/issues/735Remove ability to disable DBC assertions2019-01-31T10:37:20ZOndřej SurýRemove ability to disable DBC assertionsThere's a strong rationale for removing the ability to disable REQUIRE/ENSURE/INSIST assertions:
1) we don't write the code in a way that allows the assertions to be disable;
2) we don't really test the code with disabled assertionsThere's a strong rationale for removing the ability to disable REQUIRE/ENSURE/INSIST assertions:
1) we don't write the code in a way that allows the assertions to be disable;
2) we don't really test the code with disabled assertionsBIND-9.13.6Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/736Unify the way we use different __attribute__s2023-11-02T16:32:29ZOndřej SurýUnify the way we use different __attribute__sWe use different `__attribute__(())`` where available in a different way.
Refactor the usage (and documentation), so there's only one "style".We use different `__attribute__(())`` where available in a different way.
Refactor the usage (and documentation), so there's only one "style".Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/737Uniquely number and document emitted log messages2018-11-23T15:24:27ZOndřej SurýUniquely number and document emitted log messagesCathy Almond @cathya wrote:
> Can we, off the back of this, take a look at the Kea model for uniquely numbering and documenting emitted logged messages and open a feature request for doing something similar in BIND?
Brian Conry wrote:
>...Cathy Almond @cathya wrote:
> Can we, off the back of this, take a look at the Kea model for uniquely numbering and documenting emitted logged messages and open a feature request for doing something similar in BIND?
Brian Conry wrote:
> I've had it on my personal wish-todo-list to figure out how to generate the catalog files as part of a make operation, ever since I had to troubleshoot a problem with the text start typing instead of out of memory because the OS vendor had pre-installed catalog files that that matched their build of BIND.
>
> But eliminating the (almost completely) unused catalog functionality would work too.
>
> Actually, doing the "unique numbering" thing seems to me like it would be a helpful step if we were to try to preserve support for catalog files, so it seems to me to be something that we should do regardless.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/738Cleanup unused checks from configure.ac2020-07-02T06:26:14ZOndřej SurýCleanup unused checks from configure.acThere's a lot of accumulated cruft in `configure.ac`, it would be great to cross-check macros in generated `config.h` with their actual usage in the rest of the code, and remove the cruft from `configure.ac`, and matching stuff from `win...There's a lot of accumulated cruft in `configure.ac`, it would be great to cross-check macros in generated `config.h` with their actual usage in the rest of the code, and remove the cruft from `configure.ac`, and matching stuff from `win32util/Configure`.BIND 9.15.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/740DNS server (BIND) stops forwarding and resolving url that works with forwarde...2018-11-26T12:52:56ZGhost UserDNS server (BIND) stops forwarding and resolving url that works with forwarder. Restart helps.Hello Team,
I have whitelisted 1 url that needs to be resolved from other DNS. So it forwards the request to other dns for resolution. But sometimes it stops resolving the urls and after restart of service it works.
It is intermittent ...Hello Team,
I have whitelisted 1 url that needs to be resolved from other DNS. So it forwards the request to other dns for resolution. But sometimes it stops resolving the urls and after restart of service it works.
It is intermittent and if we dont restart, even though it starts working again...
[root@gpdcmdnns005 data]# dig @10.122.255.219 onboard.princess.com
; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @10.122.255.219 onboard.princess.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29675
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;onboard.princess.com. IN A
;; AUTHORITY SECTION:
princess.com. 3180 IN SOA princess.com. domains.princess.com. 2018101602 14400 3600 604800 7200
;; Query time: 0 msec
;; SERVER: 10.122.255.219#53(10.122.255.219)
;; WHEN: Sun Nov 25 17:58:00 EST 2018
;; MSG SIZE rcvd: 93
[root@gpdcmdnns005 data]#
[root@gpdcmdnns005 data]# systemctl restart named
******************* After restart the service*****
[root@gpdcmdnns005 data]# dig @10.122.255.219 onboard.princess.com
; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @10.122.255.219 onboard.princess.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49514
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;onboard.princess.com. IN A
;; ANSWER SECTION:
onboard.princess.com. 5 IN A 10.26.129.20
;; AUTHORITY SECTION:
com. 60432 IN NS k.gtld-servers.net.
com. 60432 IN NS e.gtld-servers.net.
com. 60432 IN NS i.gtld-servers.net.
com. 60432 IN NS b.gtld-servers.net.
com. 60432 IN NS h.gtld-servers.net.
com. 60432 IN NS c.gtld-servers.net.
com. 60432 IN NS d.gtld-servers.net.
com. 60432 IN NS g.gtld-servers.net.
com. 60432 IN NS m.gtld-servers.net.
com. 60432 IN NS a.gtld-servers.net.
com. 60432 IN NS l.gtld-servers.net.
com. 60432 IN NS f.gtld-servers.net.
com. 60432 IN NS j.gtld-servers.net.
;; ADDITIONAL SECTION:
f.gtld-servers.net. 92616 IN A 192.35.51.30
f.gtld-servers.net. 92616 IN AAAA 2001:503:d414::30
b.gtld-servers.net. 92616 IN A 192.33.14.30
b.gtld-servers.net. 92616 IN AAAA 2001:503:231d::2:30
m.gtld-servers.net. 92616 IN A 192.55.83.30
m.gtld-servers.net. 92616 IN AAAA 2001:501:b1f9::30
k.gtld-servers.net. 92616 IN A 192.52.178.30
k.gtld-servers.net. 92616 IN AAAA 2001:503:d2d::30
h.gtld-servers.net. 92616 IN A 192.54.112.30
h.gtld-servers.net. 92616 IN AAAA 2001:502:8cc::30
l.gtld-servers.net. 92616 IN A 192.41.162.30
l.gtld-servers.net. 92616 IN AAAA 2001:500:d937::30
j.gtld-servers.net. 92616 IN A 192.48.79.30
j.gtld-servers.net. 92616 IN AAAA 2001:502:7094::30
d.gtld-servers.net. 92616 IN A 192.31.80.30
d.gtld-servers.net. 92616 IN AAAA 2001:500:856e::30
g.gtld-servers.net. 92616 IN A 192.42.93.30
g.gtld-servers.net. 92616 IN AAAA 2001:503:eea3::30
a.gtld-servers.net. 92616 IN A 192.5.6.30
a.gtld-servers.net. 92616 IN AAAA 2001:503:a83e::2:30
i.gtld-servers.net. 92616 IN A 192.43.172.30
i.gtld-servers.net. 92616 IN AAAA 2001:503:39c1::30
e.gtld-servers.net. 92616 IN A 192.12.94.30
e.gtld-servers.net. 92616 IN AAAA 2001:502:1ca1::30
c.gtld-servers.net. 92616 IN A 192.26.92.30
c.gtld-servers.net. 92616 IN AAAA 2001:503:83eb::30
;; Query time: 3 msec
;; SERVER: 10.122.255.219#53(10.122.255.219)
;; WHEN: Sun Nov 25 17:59:55 EST 2018
;; MSG SIZE rcvd: 861
****NAMED.CONF configuration:*****
allow-query { any; };
// Forward all DNS queries to Google Plubic DNS.
forwarders {
208.67.220.220;
208.67.222.222;
};
dnssec-enable no;
dnssec-validation no;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view labguest {
response-policy { zone "rpz"; };
match-clients { labguest; };
allow-recursion { any; };
zone "rpz" {
type master;
file "/var/named/db.rpz";
//allow-query { none; };
allow-transfer { 127.0.0.1 ; };
};
zone "." IN {
type hint;
file "named.ca";
};
zone "gp.ocean.com" IN {
type master;
file "fwd.gp.ocean.com.db";
allow-query { any; };
};
zone "119.255.122.10.in-addr.arpa" IN {
type master;
file "1.0.0.127.db";
allow-update { none; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
};https://gitlab.isc.org/isc-projects/bind9/-/issues/742[ISC-support #13767] NSEC3 typemap improperly includes DNSKEY RRset instead o...2018-12-14T02:53:55ZCathy Almond[ISC-support #13767] NSEC3 typemap improperly includes DNSKEY RRset instead of ignoring it as out-of-zone### Summary
During an in-depth validation of a DNSSEC-signed zone (using NSEC3), it was uncovered that there was an inconsistency that not all zone validation tools highlighted.
Due to an administrative error, a delegated zone had inse...### Summary
During an in-depth validation of a DNSSEC-signed zone (using NSEC3), it was uncovered that there was an inconsistency that not all zone validation tools highlighted.
Due to an administrative error, a delegated zone had inserted both its DS and KSK DNSKEY RRs into the parent zone. The NSEC3 RR covering those included DNSKEY in the typemap, even though the DNSKEY RR should be occluded by the delegation and ignored. (We don't know if named also signed the out-of-zone RRset, but this should be checked for also as a potential extension to this defect).
We do not believe that this defect causes validation failures in DNSSEC-validating resolvers.
### BIND version used
9.11.4-P2
### What is the current *bug* behavior?
As identified by jdnssec-verifyzone:
$ jdnssec-verifyzone -v 2 (zone redacted for privacy)
WARNING: Typemap for NSEC3 RR (name redacted for privacy) for (zone redacted for privacy) did not match what was expected. Expected 'NS DS RRSIG', got 'NS DS RRSIG DNSKEY'
zone did not verify.
(Note that neither dnssec-verify nor validns perceived this as wrong)
### What is the expected *correct* behavior?
The covering NSEC3 should not have included the DNSKEY RR in the typemap
Reported in Support ticket https://support.isc.org/Ticket/Display.html?id=13767