BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-04-26T13:32:59Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2307"dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answering2022-04-26T13:32:59ZMichał Kępień"dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answeringThis started happening after !4115. It seems that each UDP query does
time out after 5 seconds, but `dig` never tries the "next server"
(127.0.0.1) after its "first pick" (::1) fails to respond.
The problem is easily reproducible with ...This started happening after !4115. It seems that each UDP query does
time out after 5 seconds, but `dig` never tries the "next server"
(127.0.0.1) after its "first pick" (::1) fails to respond.
The problem is easily reproducible with the following `named.conf`:
```
options {
listen-on port 5300 { 127.0.0.1; };
listen-on-v6 { none; };
};
```
Test with: `dig @localhost isc.org.` - it will time out even though it
should not. This is a change in behavior that was caught by [automated
RPM tests][1].
[1]: https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/57751April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2306Compilation broken on systems without <sys/un.h>2020-11-26T15:52:36ZMichal NowakCompilation broken on systems without <sys/un.h>Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
s...Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
ssu_external.c:59:31: warning: unused parameter ‘path’ [-Wunused-parameter]
59 | ux_socket_connect(const char *path) {
| ~~~~~~~~~~~~^~~~
getaddrinfo.c: In function ‘get_local’:
getaddrinfo.c:1243:32: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr_un’
1243 | ai = ai_alloc(AF_LOCAL, sizeof(*slocal));
| ^
getaddrinfo.c:1249:16: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
getaddrinfo.c:1249:47: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
```
I don't know what operating systems might be affected, probably none (even Solaris 10 has it), one can "emulate" it like this and rebuild with `autoreconf -fi`:
```patch
--- a/configure.ac
+++ b/configure.ac
@@ -1799,9 +1799,9 @@ AS_IF([test "$enable_linux_caps" = "yes"],
AC_SUBST([LIBCAP_LIBS])
AC_CHECK_HEADERS(sys/un.h,
-ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
-,
ISC_PLATFORM_HAVESYSUNH="#undef ISC_PLATFORM_HAVESYSUNH"
+,
+ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
)
AC_SUBST(ISC_PLATFORM_HAVESYSUNH)
```
I tried for a short while and followed the compiler in fixing warnings and disabling code with `#ifdef ISC_PLATFORM_HAVESYSUNH` but I end up with either failing `tsiggss` system test or crashing `named`.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2305Did we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?2020-12-16T20:50:12ZMichael McNallyDid we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about t...A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about this because the behavior differed from an earlier version of BIND which did not exhibit the issue.
After some troubleshooting, it turns out that, due to a combination of factors -- some specific to the domain but also some applying to the server, they are hitting the max-recursion-queries limit of 75 queries that was set as part of the remediation for [CVE-2020-8616](https://kb.isc.org/docs/cve-2020-8616) (intended to prevent an exploit, demonstrated as a proof-of-concept by the researchers who reported it, that could send a server chasing a huge number of queries when processing a referral.)
The situation reported by the customer seems to demonstrate that a server with a not-very-unusual configuration can hit the limit while processing a common, fairly high-profile zone. Should we then adjust the limit, make changes to the log message visibility when the limit is hit, and/or make other changes?December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2304Insecure data handling and null pointer dereferences in test-async.c2021-09-03T05:05:05ZMichal NowakInsecure data handling and null pointer dereferences in test-async.c@each Coverity identified following problems in the new `bin/tests/system/hooks/driver/test-async.c`:
```
*** CID 313488: Insecure data handling (TAINTED_SCALAR)
/bin/tests/system/hooks/driver/test-async.c: 345 in async_query_done_begi...@each Coverity identified following problems in the new `bin/tests/system/hooks/driver/test-async.c`:
```
*** CID 313488: Insecure data handling (TAINTED_SCALAR)
/bin/tests/system/hooks/driver/test-async.c: 345 in async_query_done_begin()
339 }
340
341 /* initial call */
342 state->async = true;
343 state->hookpoint = NS_QUERY_DONE_BEGIN;
344 state->origresult = *resp;
>>> CID 313488: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted variable "qctx->client" to a tainted sink.
345 ns_query_hookasync(qctx, doasync, state);
346 return (NS_HOOK_RETURN);
347 }
348
349 static ns_hookresult_t
350 async_qctx_destroy(void *arg, void *cbdata, isc_result_t *resp) {
```
```
*** CID 281450: Null pointer dereferences (REVERSE_INULL)
/bin/tests/system/hooks/driver/test-async.c: 163 in plugin_register()
157
158 *instp = inst;
159
160 return (ISC_R_SUCCESS);
161
162 cleanup:
>>> CID 281450: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "inst" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
163 if (result != ISC_R_SUCCESS && inst != NULL) {
164 plugin_destroy((void **)&inst);
165 }
166
167 return (result);
168 }
```
More information at https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=37570751&defectInstanceId=11302475&mergedDefectId=313488.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2303Override fetch-limits when stale-answer-enable is 'yes' for queries that are ...2021-06-08T09:11:23ZCathy AlmondOverride fetch-limits when stale-answer-enable is 'yes' for queries that are attempting to refresh positive stale RRsetsSee also #2066, #2273, #2247 and #2248
The final piece of the puzzle is having Serve Stale play nicely with fetch-limits.
See also [https://bugs.isc.org/Ticket/Display.html?id=41259](https://bugs.isc.org/Ticket/Display.html?id=41259)
...See also #2066, #2273, #2247 and #2248
The final piece of the puzzle is having Serve Stale play nicely with fetch-limits.
See also [https://bugs.isc.org/Ticket/Display.html?id=41259](https://bugs.isc.org/Ticket/Display.html?id=41259)
Q. When fetch-limits are triggered, how do you give precedence to known 'good' client queries?
A. You base this on the existence of stale content already in cache.
Q. How do you override fetch-limits in a safe way (so that you don't override fetch-limits for every 'good' client query and still overwhelm the authoritative servers?
A. You have to have serving of stale answers enabled - that way you already have a built-in mechanism to rate-limit the refresh retries.
The current (and soon to be improved) implementation of serve-stale still only triggers serving of stale content if there is a stale answer already in cache that could be used, AND an attempt to refresh the stale content has timed out. If we don't attempt to refresh it, then it won't be served stale and the stale-refresh-time countdown won't be started for this query.
The same also applies if we served it stale once, but the stale-refresh-time has now expired again, and we need to try again to contact the authoritative servers - if we get blocked by fetch-limits (fetches-per-zone or fetches-per-server) we still won't use the stale data.
My request is that if these three condition are met, that we bypass fetchlimits and try to resolve the query anyway. The conditions are:
- The server has `stale-answer-enable yes;`
- The name/type being resolved can be answered from cache, should it be necessary to serve a stale answer
- This is not a negative response (NXDOMAIN or NXRRSET)
The risk of bypassing fetchlimits is low
a) we know that this query has been resolved before, so it might be possible to again and it is a better candidate query to bypass fetchlimits than a brand new name that this resolver hasn't encountered before - particularly if this resolver is also being used to participate in a PRSD-style attack
b) even if the query times out, this will trigger serving of the stale answer to all other clients who arrive with the same query during `stale-refresh-time`
It would be really good to get this into the December releases with the other improvements to Serve Stalehttps://gitlab.isc.org/isc-projects/bind9/-/issues/2302DOT scalability, performance testing2021-09-13T20:52:00ZVicky Riskvicky@isc.orgDOT scalability, performance testingWe need to find a way to test with a large number of DOT connections for scalability. I understand our current perflab set up cannot do this.
The goals of this might include:
- checking that DOT scaling is equivalent to TCP scaling (if...We need to find a way to test with a large number of DOT connections for scalability. I understand our current perflab set up cannot do this.
The goals of this might include:
- checking that DOT scaling is equivalent to TCP scaling (if it is much worse we might consider that a bug)
- providing some guidance to users about throughput (e.g. as a % of UDP performance)
- verifying (functionally) that rate limits work as expected for DOThttps://gitlab.isc.org/isc-projects/bind9/-/issues/2301Add FIPS mode enabled builds to GitLab CI2022-06-22T15:06:44ZMichal NowakAdd FIPS mode enabled builds to GitLab CIBIND9 supports FIPS mode (`--enable-fips-mode`) but is not regularly tested in the CI. For this to happen this needs to be accomplished:
- [ ] Basic FIPS build fixes integrated https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/...BIND9 supports FIPS mode (`--enable-fips-mode`) but is not regularly tested in the CI. For this to happen this needs to be accomplished:
- [ ] Basic FIPS build fixes integrated https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4281 ([performs](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4281/diffs#87db583be5c13c1f7b3c958b10e03d67b6a2ca06) builds with `--enable-fips-mode`)
- [ ] System test can run without MD5 (there's plenty of `algorithm hmac-md5;` in system test or implicit expectation of MD5 in `dig` invocations in `acl` and `allow-query` system tests)
- [ ] Red Hat FIPS patches by @pemensik at https://src.fedoraproject.org/rpms/bind/tree/master for `v9_11` evaluated
- [ ] FIPS-enabled host or VM image (most likely with CentOS)
- [ ] CI job(s) with `--enable-fips-mode` in the build stage and subsequent unit and system test CI jobsNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2300rndc retransfer with specific master2023-11-06T16:08:49ZPeter Daviesrndc retransfer with specific master### Description
rndc retransfer with specific master
The rndc tool has a retransfer zone command.
**retransfer zone [class [view]]** Retransfer the given slave zone from the master server.
It may be useful to be able to specify ...### Description
rndc retransfer with specific master
The rndc tool has a retransfer zone command.
**retransfer zone [class [view]]** Retransfer the given slave zone from the master server.
It may be useful to be able to specify a master server with this command. Where there are more than one server defined as master for the zone.
[RT #17310](https://support.isc.org/Ticket/Display.html?id=17310)https://gitlab.isc.org/isc-projects/bind9/-/issues/2299Restart running transfer2023-11-06T16:06:19ZPeter DaviesRestart running transfer### Description
The ability to:
retransfer the zone with something like "rndc force-retransfer [zone]"
which would abort the current inflight transfer and restart it.
It has been noted transfer of large resigned zones can get qu...### Description
The ability to:
retransfer the zone with something like "rndc force-retransfer [zone]"
which would abort the current inflight transfer and restart it.
It has been noted transfer of large resigned zones can get quenched at source.
[RT #17310](https://support.isc.org/Ticket/Display.html?id=17310)https://gitlab.isc.org/isc-projects/bind9/-/issues/2298multiple definition of `librpz_dnsrpzd_path'2021-03-04T10:29:10ZDavid Fordmultiple definition of `librpz_dnsrpzd_path'<!--
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
during compilation, a link failure is returned because of multiple definitions of the `librpz_dnsrpzd_path` symbol
### BIND version used
source of 9.14.7
### Steps to reproduce
compile with dnsrps enabled
### What is the current *bug* behavior?
```
gcc -I/tmp/bind/trunk/src/bind-9.14.7 -I../.. -I. -I../../lib/dns -Iinclude -I/tmp/bind/trunk/src/bind-9.14.7/lib/dns/include -I../../lib/dns/include -I/tmp/bind/trunk/src/bind-9.14.7/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I/usr/include -I/usr/include -DGSSAPI -DUSE_ISC_SPNEGO -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE -I/usr/include -pthread -I/usr/include/libxml2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--export-dynamic -o libdns.la -rpath /usr/lib \
-version-info 1310:2:0 \
acl.lo adb.lo badcache.lo byaddr.lo cache.lo callbacks.lo catz.lo clientinfo.lo compress.lo db.lo dbiterator.lo dbtable.lo diff.lo dispatch.lo dlz.lo dns64.lo dnsrps.lo dnssec.lo ds.lo dyndb.lo ecs.lo fixedname.lo forward.lo ipkeylist.lo iptable.lo journal.lo keydata.lo keytable.lo lib.lo log.lo lookup.lo master.lo masterdump.lo message.lo name.lo ncache.lo nsec.lo nsec3.lo nta.lo order.lo peer.lo portlist.lo private.lo rbt.lo rbtdb.lo rcode.lo rdata.lo rdatalist.lo rdataset.lo rdatasetiter.lo rdataslab.lo request.lo resolver.lo result.lo rootns.lo rpz.lo rrl.lo rriterator.lo sdb.lo sdlz.lo soa.lo ssu.lo ssu_external.lo stats.lo tcpmsg.lo time.lo timer.lo tkey.lo tsec.lo tsig.lo ttl.lo update.lo validator.lo version.lo view.lo xfrin.lo zone.lo zonekey.lo zoneverify.lo zt.lo spnego.lo dst_api.lo dst_parse.lo dst_result.lo gssapi_link.lo gssapictx.lo hmac_link.lo openssl_link.lo openssldh_link.lo opensslecdsa_link.lo openssleddsa_link.lo opensslrsa_link.lo pkcs11rsa_link.lo pkcs11ecdsa_link.lo pkcs11eddsa_link.lo pkcs11.lo key.lo client.lo ecdb.lo geoip.lo ../../lib/isc/libisc.la -L/usr/lib -lcrypto -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ljson-c -llmdb -lm -lGeoIP -L/usr/lib -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl
libtool: link: gcc -shared -fPIC -DPIC .libs/acl.o .libs/adb.o .libs/badcache.o .libs/byaddr.o .libs/cache.o .libs/callbacks.o .libs/catz.o .libs/clientinfo.o .libs/compress.o .libs/db.o .libs/dbiterator.o .libs/dbtable.o .libs/diff.o .libs/dispatch.o .libs/dlz.o .libs/dns64.o .libs/dnsrps.o .libs/dnssec.o .libs/ds.o .libs/dyndb.o .libs/ecs.o .libs/fixedname.o .libs/forward.o .libs/ipkeylist.o .libs/iptable.o .libs/journal.o .libs/keydata.o .libs/keytable.o .libs/lib.o .libs/log.o .libs/lookup.o .libs/master.o .libs/masterdump.o .libs/message.o .libs/name.o .libs/ncache.o .libs/nsec.o .libs/nsec3.o .libs/nta.o .libs/order.o .libs/peer.o .libs/portlist.o .libs/private.o .libs/rbt.o .libs/rbtdb.o .libs/rcode.o .libs/rdata.o .libs/rdatalist.o .libs/rdataset.o .libs/rdatasetiter.o .libs/rdataslab.o .libs/request.o .libs/resolver.o .libs/result.o .libs/rootns.o .libs/rpz.o .libs/rrl.o .libs/rriterator.o .libs/sdb.o .libs/sdlz.o .libs/soa.o .libs/ssu.o .libs/ssu_external.o .libs/stats.o .libs/tcpmsg.o .libs/time.o .libs/timer.o .libs/tkey.o .libs/tsec.o .libs/tsig.o .libs/ttl.o .libs/update.o .libs/validator.o .libs/version.o .libs/view.o .libs/xfrin.o .libs/zone.o .libs/zonekey.o .libs/zoneverify.o .libs/zt.o .libs/spnego.o .libs/dst_api.o .libs/dst_parse.o .libs/dst_result.o .libs/gssapi_link.o .libs/gssapictx.o .libs/hmac_link.o .libs/openssl_link.o .libs/openssldh_link.o .libs/opensslecdsa_link.o .libs/openssleddsa_link.o .libs/opensslrsa_link.o .libs/pkcs11rsa_link.o .libs/pkcs11ecdsa_link.o .libs/pkcs11eddsa_link.o .libs/pkcs11.o .libs/key.o .libs/client.o .libs/ecdb.o .libs/geoip.o -Wl,-rpath -Wl,/tmp/bind/trunk/src/bind-9.14.7/lib/isc/.libs ../../lib/isc/.libs/libisc.so -L/usr/lib -lcrypto -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ljson-c -llmdb -lGeoIP -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl -march=x86-64 -mtune=generic -O2 -pthread -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--export-dynamic -pthread -Wl,-soname -Wl,libdns.so.1310 -o .libs/libdns.so.1310.0.2
/usr/bin/ld: .libs/rpz.o:(.bss+0x0): multiple definition of `librpz_dnsrpzd_path'; .libs/dnsrps.o:(.bss+0x80): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:580: libdns.la] Error 1
make[2]: Leaving directory '/tmp/bind/trunk/src/bind-9.14.7/lib/dns'
make[1]: *** [Makefile:84: subdirs] Error 1
make[1]: Leaving directory '/tmp/bind/trunk/src/bind-9.14.7/lib'
make: *** [Makefile:91: subdirs] Error 1
```
### What is the expected *correct* behavior?
normal compile
### Relevant configuration files
```
└─> grep -iP 'rp(s|z)' config.log config.h
config.log: $ ./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin --localstatedir=/var --disable-static --enable-fixed-rrset --enable-full-report --enable-dnsrps --with-python=/usr/bin/python --with-geoip --with-openssl --with-libidn2 --with-libjson --with-libxml2 --with-lmdb --with-libtool --with-dlz-postgres
config.log:configure:17485: checking for librpz __attribute__s
config.log:config.status:1482: creating bin/tests/system/rpz/Makefile
config.log:BIND9_CONFIGARGS='CONFIGARGS='\''--prefix=/usr'\'' '\''--sysconfdir=/etc'\'' '\''--sbindir=/usr/bin'\'' '\''--localstatedir=/var'\'' '\''--disable-static'\'' '\''--enable-fixed-rrset'\'' '\''--enable-full-report'\'' '\''--enable-dnsrps'\'' '\''--with-python=/usr/bin/python'\'' '\''--with-geoip'\'' '\''--with-openssl'\'' '\''--with-libidn2'\'' '\''--with-libjson'\'' '\''--with-libxml2'\'' '\''--with-lmdb'\'' '\''--with-libtool'\'' '\''--with-dlz-postgres'\'' '\''CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE'\'' '\''LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'\'' '\''CPPFLAGS=-D_FORTIFY_SOURCE=0'\'''
config.log:#define LIBRPZ_HAVE_ATTR 1
config.log:#define DNSRPS_LIBRPZ_PATH "librpz.so"
config.log:#define DNSRPS_LIB_OPEN 2
config.log:#define USE_DNSRPS 1
config.h:/* dnsrps $librpz_name */
config.h:#define DNSRPS_LIBRPZ_PATH "librpz.so"
config.h:/* 0=no DNSRPS 1=static link 2=dlopen() */
config.h:#define DNSRPS_LIB_OPEN 2
config.h:/* have __attribute__s used in librpz.h */
config.h:#define LIBRPZ_HAVE_ATTR 1
config.h:#define USE_DNSRPS 1
```
### Relevant logs and/or screenshots
└─> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2297Add long term server properties database2023-11-02T16:26:05ZMark AndrewsAdd long term server properties databaseAdd long term server properties database which is updated from routine traffic so that named doesn't have to relearn server characteristics.
e.g. Supports DNS COOKIEAdd long term server properties database which is updated from routine traffic so that named doesn't have to relearn server characteristics.
e.g. Supports DNS COOKIENot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2296Dns RRs size bigger than 64k , but bind is allowed only 64k , because of that...2020-11-20T10:20:02Zvenkappa eDns RRs size bigger than 64k , but bind is allowed only 64k , because of that lossing some RRs in the DNs responseMy DNS db file have 2048 answer RRs and 2048 Additional RRs, but DNS response includes only 475 Answers, that means not sending all the RRs and noticed ISC_R_NOSPACE ISSUE on bind side, I hope this is because of TCP_BUFFER_SIZE limit ...My DNS db file have 2048 answer RRs and 2048 Additional RRs, but DNS response includes only 475 Answers, that means not sending all the RRs and noticed ISC_R_NOSPACE ISSUE on bind side, I hope this is because of TCP_BUFFER_SIZE limit is 65535, so how to send all the RRs if more than 64k.https://gitlab.isc.org/isc-projects/bind9/-/issues/2295Add the ability to specify that a server supports COOKIES.2022-09-20T13:44:03ZMark AndrewsAdd the ability to specify that a server supports COOKIES.We currently learn whether a server supports cookies or not as part of the lookup process. This leaves an exposure window where a spoofed UDP response without a cookie can be accepted. Fallback to TCP if the response does not have a va...We currently learn whether a server supports cookies or not as part of the lookup process. This leaves an exposure window where a spoofed UDP response without a cookie can be accepted. Fallback to TCP if the response does not have a valid TSIG or client cookie when `require-cookie` is true.
`server <prefix> { require-cookie <bool>; };`October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2294./server.c:3881: unexpected error: when issuing rndc reload or reconfig2020-11-19T14:51:45ZKarl Wieman./server.c:3881: unexpected error: when issuing rndc reload or reconfig<!--
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
When issuing an rndc reload or reconfig command to two of my BIND instances, I receive this error: "rndc: 'reload' failed: unexpected error" The syslog logs show this: "Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: ./server.c:3881: unexpected error:"
### BIND version used
cozbdns001# /opt/named/sbin/named -V
BIND 9.11.23 (Extended Support Version) <id:4f70056>
running on Linux x86_64 3.10.0-1160.2.1.el7.x86_64 #1 SMP Mon Sep 21 21:00:09 EDT 2020
built by make with '--prefix=/opt/bind-9.11.23'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /opt/bind-9.11.23/etc/named.conf
rndc configuration: /opt/bind-9.11.23/etc/rndc.conf
DNSSEC root key: /opt/bind-9.11.23/etc/bind.keys
nsupdate session key: /opt/bind-9.11.23/var/run/named/session.key
named PID file: /opt/bind-9.11.23/var/run/named/named.pid
named lock file: /opt/bind-9.11.23/var/run/named/named.lock
### Steps to reproduce
Any rndc reload or reconfig after a successful start up causes the issue. I copied the full BIND deployment and configuration to a lab server and the issue does not occur.
### What is the current *bug* behavior?
The server does not appear to actually reload its configuration. A full restart is required.
### What is the expected *correct* behavior?
rndc reconfig and reload should succeed. Also, "Unexpected error" is a useless message that does not help identify the cause of the issue.
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.603 general: info: received control channel command 'reload'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.603 general: info: loading configuration from '/etc/named.conf'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.610 general: info: reading built-in trust anchors from file '/opt/bind-9.11.23/etc/bind.keys'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 general: info: using default UDP/IPv4 port range: [1024, 65535]
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 general: info: using default UDP/IPv6 port range: [1024, 65535]
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 network: info: no IPv6 interfaces found
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.616 general: info: sizing zone task pool based on 462 zones
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.617 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.624 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.631 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.638 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.645 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.652 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.659 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.666 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.674 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.681 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.688 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.695 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.703 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.710 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.717 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.725 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.732 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.739 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.747 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.754 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.761 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.768 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.775 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.783 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.790 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.797 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.804 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.812 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.819 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.826 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.834 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.841 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.848 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.855 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.863 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.870 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.877 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.884 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.892 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.899 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.907 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.914 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.921 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.929 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.936 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.943 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.950 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.958 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.965 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.972 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.980 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.987 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.994 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.002 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.009 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.016 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.024 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.031 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: ./server.c:3881: unexpected error:
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: unable to obtain neither an IPv4 nor an IPv6 dispatch
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.042 general: error: reloading configuration failed: unexpected error
'
Note: Ommitted many "general: info: automatic empty zone: view <DOMAIN>: XXX" messages.
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2293zone transfer tracking2020-11-19T08:13:25ZPeter Davieszone transfer tracking### Description
zone transfer tracking mechanism
### Request
This is feature request for a function that would allow one to list zone transfers that are in-progress at any one time and how long they have been running for.
Benefit...### Description
zone transfer tracking mechanism
### Request
This is feature request for a function that would allow one to list zone transfers that are in-progress at any one time and how long they have been running for.
Benefits:
- be able to determine if zone transfers are running longer than expected.
- be able to track transfers in-progress over time to monitor primary and secondary zone transfer health.
### Links / references
RT #[17310](https://support.isc.org/Ticket/Display.html?id=17310).https://gitlab.isc.org/isc-projects/bind9/-/issues/22929.16.8 can't create PID file at Centos72020-11-19T09:03:05ZDen Ivanov9.16.8 can't create PID file at Centos7<!--
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
BIND could not open '/var/opt/isc/isc-bind/run/named/named.pid' and systemd service terminates after start
### BIND version used
```
BIND 9.16.8 (Stable Release) <id:539f9f0>
running on Linux x86_64 3.10.0-1160.6.1.el7.x86_64 #1 SMP Tue Nov 17 13:59:11 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro -L/opt/isc/isc-bind/root/usr/lib64' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.16.8/sphinx/bin/sphinx-build'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/opt/isc/isc-bind/named.conf
rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
named PID file: /var/opt/isc/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/isc-bind/run/named/named.lock
```
### Steps to reproduce
systemctl start isc-bind-named.service
### What is the current *bug* behavior?
Service terminates
### What is the expected *correct* behavior?
Service must start and run
### Relevant configuration files
Doesn't matter for this case
### Relevant logs and/or screenshots
```
Nov 19 11:59:27 server named[893]: listening on IPv4 interface lo, 127.0.0.1#53
Nov 19 11:59:27 server named[893]: Could not open '/var/opt/isc/isc-bind/run/named/named.pid'.
Nov 19 11:59:27 server named[893]: Please check file and directory permissions or reconfigure the filename.
Nov 19 11:59:27 server named[893]: could not open file '/var/opt/isc/isc-bind/run/named/named.pid': Permission denied
<...skip...>
Nov 19 12:00:57 server systemd[1]: isc-bind-named.service start operation timed out. Terminating.
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.102 network: no longer listening on 127.0.0.1#53
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.139 general: shutting down
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.139 general: stopping command channel on 127.0.0.1#953
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.156 general: exiting
Nov 19 12:00:57 server systemd[1]: Failed to start isc-bind-named.service.
Nov 19 12:00:57 server systemd[1]: Unit isc-bind-named.service entered failed state.
Nov 19 12:00:57 server systemd[1]: isc-bind-named.service failed.
```
### Possible fixes
```
semanage fcontext -a -t var_run_t "/var/opt/isc/isc-bind/run"
semanage fcontext -a -t named_var_run_t "/var/opt/isc/isc-bind/run(/.*)"
restorecon -vr /var/opt/isc/isc-bind/run
```Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2291DNAME-DNAME loop generates ~17 length CNAME chain but a DNAME-CNAME loop ter...2020-11-17T23:25:16ZSiva Kesava R KakarlaDNAME-DNAME loop generates ~17 length CNAME chain but a DNAME-CNAME loop terminates early### Summary
When there is a `DNAME-DNAME` loop in the zone file, the BIND server generates 17 CNAMEs, but for a `DNAME-CNAME` chain, the BIND server stops after one iteration. The `DNAME-DNAME` loop behavior is also different from Knot ...### Summary
When there is a `DNAME-DNAME` loop in the zone file, the BIND server generates 17 CNAMEs, but for a `DNAME-CNAME` chain, the BIND server stops after one iteration. The `DNAME-DNAME` loop behavior is also different from Knot and NSD.
### BIND version used
BIND 9.11.3-1ubuntu1.13-Ubuntu (Extended Support Version) <id:a375815>
### Steps to reproduce
Consider the following zone file:
| | | |
|--------------------|-----------|----------------------------------------------------------|
| campus.edu. | 500 SOA | ns1.campus.edu. root.campus.edu. 3 86400 7200 604800 300 |
| campus.edu. | 500 NS | ns1.outside.edu. |
| d.campus.edu. | 500 DNAME | f.d.campus.edu. |
For the query `<a.f.d.campus.edu, A>`, the response returned by BIND was:
```
"opcode QUERY",
"rcode NOERROR",
"flags QR AA RA",
";QUESTION",
"a.f.d.campus.edu. IN A",
";ANSWER",
"d.campus.edu. 500 IN DNAME f.d.campus.edu.",
"a.f.d.campus.edu. 500 IN CNAME a.f.f.d.campus.edu.",
"a.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.d.campus.edu.",
"a.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
```
whereas the response from Knot and NSD was:
```
"opcode QUERY",
"rcode NOERROR",
"flags QR AA",
";QUESTION",
"a.f.d.campus.edu. IN A",
";ANSWER",
"d.campus.edu. 500 IN DNAME f.d.campus.edu.",
"a.f.d.campus.edu. 500 IN CNAME a.f.f.d.campus.edu.",
";AUTHORITY",
";ADDITIONAL"
```
**NSD logs mention -- `DNAME processing stopped due to loop, qname a.f.d.campus.edu.`**
Consider another zone file:
| | | |
|--------------------|-----------|----------------------------------------------------------|
| campus.edu. | 500 SOA | ns1.campus.edu. root.campus.edu. 3 86400 7200 604800 300 |
| campus.edu. | 500 NS | ns1.outside.edu. |
| d.campus.edu. | 500 DNAME | f.campus.edu. |
| e.f.campus.edu. | 500 CNAME | e.d.campus.edu. |
The response from BIND, NSD, and Knot was:
```
"opcode QUERY",
"rcode NOERROR",
"flags QR AA RA",
";QUESTION",
"e.d.campus.edu. IN A",
";ANSWER",
"d.campus.edu. 500 IN DNAME f.campus.edu.",
"e.d.campus.edu. 500 IN CNAME e.f.campus.edu.",
"e.f.campus.edu. 500 IN CNAME e.d.campus.edu.",
";AUTHORITY",
";ADDITIONAL"
```
### What is the current *bug* behavior?
BIND authoritative server goes on for an infinite (17) CNAME synthesis.
### What is the expected *correct* behavior?
In the `DNAME-CNAME` case, it is evident that after the second `CNAME,` the new query is the same as the original one, so the implementations stop. For the `DNAME-DNAME` case, it is harder to say which behavior (BIND or others) is the correct behavior as the zone file is not proper. I expected BIND also to stop after the first iteration in both cases.
(I looked in the repo for this issue and did not find it, so I am filing a new issue and please excuse me if it's a duplicate.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2289cache dump sometimes reports nonsense values with "stale (will be retained f...2021-04-28T09:11:11ZBrian Conrycache dump sometimes reports nonsense values with "stale (will be retained for %u more seconds)"Several customers have reported this issue, but the cause had been completely baffling.
Examples include:
```
; stale (will be retained for 4294362497 more seconds)
```
While reviewing the relevant areas of the code for other issues, I...Several customers have reported this issue, but the cause had been completely baffling.
Examples include:
```
; stale (will be retained for 4294362497 more seconds)
```
While reviewing the relevant areas of the code for other issues, I realized that the decision about whether or not to report the record as stale, and report how long it will be retained for (as modified by the recorded stale intervals), is based solely on the `STALE` flag in the header.
This is an accurate decision, but I wonder if this might lead to odd results if the record expiration is actually in the future because it has been forcibly expired due to the cache being overmem.
I've also wondered if there might be some incorrect reporting if/when the max-stale-ttl is changed after data has been added to the cache.
I will investigate both of these issues further using customer data I already have on hand, but I won't complain if it is fixed before I get to it.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2288"dig" crashes when interrupted while waiting for a TCP connection2022-04-26T13:15:52ZMichał Kępień"dig" crashes when interrupted while waiting for a TCP connectionTo reproduce, fire up a `dig` query that will not connect over TCP
before it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10 +vc
and then hit CTRL+C:
dighost.c:3232: REQUIRE((__builtin_expect(!!(((query)) != ((void *)0)), ...To reproduce, fire up a `dig` query that will not connect over TCP
before it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10 +vc
and then hit CTRL+C:
dighost.c:3232: REQUIRE((__builtin_expect(!!(((query)) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)((query)))->magic == ((('D') << 24 | ('i') << 16 | ('g') << 8 | ('q')))), 1))) failed, back trace
Looks like `arg` (which gets cast to `dig_query_t *query`) passed to
`tcp_connected()` is broken in this case.
See #2287 for the UDP counterpart of this problem.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2287"dig" crashes when interrupted while listening for UDP responses2020-12-09T10:08:46ZMichał Kępień"dig" crashes when interrupted while listening for UDP responsesTo reproduce, fire up a `dig` query that will not get a response before
it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10
and then hit CTRL+C:
dighost.c:4262: REQUIRE(isc_refcount_current(&recvcount) == 0) failed, back tr...To reproduce, fire up a `dig` query that will not get a response before
it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10
and then hit CTRL+C:
dighost.c:4262: REQUIRE(isc_refcount_current(&recvcount) == 0) failed, back trace
It looks like `current_lookup->q` is empty in `cancel_all()` and thus
the [code block which decrements `recvcount`][1] is not evaluated.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/ff2bc7891e99442df51acea1110ad599ddc6756a/bin/dig/dighost.c#L4203-4211December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)