ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-02-14T14:48:26Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1879ARM and named man page incorrect regarding -U and number of listeners2024-02-14T14:48:26ZCathy AlmondARM and named man page incorrect regarding -U and number of listenersAs verified in 9.16.3 ARM. From [Support ticket #16280](https://support.isc.org/Ticket/Display.html?id=16280)
The ARM still says (about the options for starting named):
```
-U #listeners
Use #listeners worker threads to listen for inc...As verified in 9.16.3 ARM. From [Support ticket #16280](https://support.isc.org/Ticket/Display.html?id=16280)
The ARM still says (about the options for starting named):
```
-U #listeners
Use #listeners worker threads to listen for incoming UDP packets on each address. If
not specified, named will calculate a default value based on the number of detected CPUs:
1 for 1 CPU, and the number of detected CPUs minus one for machines with more than 1
CPU. This cannot be increased to a value higher than the number of CPUs. If -n has been
set to a higher value than the number of detected CPUs, then -U may be increased as high
as that value, but no higher. On Windows, the number of UDP listeners is hardwired to 1
and this option has no effect.
```
This is in fact untrue - we're using '-n' throughout (apart from Windows), as of 9.12 and up.
E.g. from named starting up:
> ...
> 16-Apr-2020 05:51:48.172 found 24 CPUs, using 24 worker threads
> 16-Apr-2020 05:51:48.172 using 24 UDP listeners per interface
> 16-Apr-2020 05:51:48.201 using up to 21000 sockets
> ...
I expect this changed post-9.11 at some point when we changed how the legacy server sockets code works.
Please fix the ARM and man page appropriately (maybe in the next maintenance releases?)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1880Implement distcheck2023-07-25T18:46:26ZMichal NowakImplement distcheck`make distcheck` does not pass on `master` (not even with https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3527 applied):
- [x] system test fails because of read-only directories in the tarball
- [x] system test fails all over...`make distcheck` does not pass on `master` (not even with https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3527 applied):
- [x] system test fails because of read-only directories in the tarball
- [x] system test fails all over the place
- [x] `lib/dns/tests` unit tests are not being executed (https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3527#note_134700)
- [x] some unit tests fail (`file_test`)August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1881Text edits in dnssec.rst2020-06-08T10:16:03ZSuzanne GoldlustText edits in dnssec.rstVarious text edits neededVarious text edits neededJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1882Text edits in managed-keys.rst2020-06-08T10:16:07ZSuzanne GoldlustText edits in managed-keys.rstVarious text edits to managed-keys.rst section of BIND ARMVarious text edits to managed-keys.rst section of BIND ARMJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1883Text edits in pkcs11.rst2021-01-12T14:43:59ZSuzanne GoldlustText edits in pkcs11.rstVarious text edits in the pkcs11.rst section of the BIND ARMVarious text edits in the pkcs11.rst section of the BIND ARMJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1884BIND 9.11 does not apply rpz policy zone in masterfile-format map2021-10-05T12:28:45ZPetr MenšíkBIND 9.11 does not apply rpz policy zone in masterfile-format map### Summary
BIND 9.11 does not apply rpz policy zone in masterfile-format map
### BIND version used
(Paste the output of `named -V`.)
```BIND 9.11.19-RedHat-9.11.19-1.fc32 (Extended Support Version) <id:905ec64>
running on Linux x86_6...### Summary
BIND 9.11 does not apply rpz policy zone in masterfile-format map
### BIND version used
(Paste the output of `named -V`.)
```BIND 9.11.19-RedHat-9.11.19-1.fc32 (Extended Support Version) <id:905ec64>
running on Linux x86_64 5.6.0-0.rc7.git0.2.fc32.x86_64 #1 SMP Mon Mar 23 18:38:45 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--enable-openssl-hash' '--with-geoip2' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=yes' '--with-libjson' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.1.1 20200507 (Red Hat 10.1.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1d FIPS 10 Sep 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Use simple rpz.db and named.conf nad load 'rpz' zone in map format.
### What is the current *bug* behavior?
```# dig @localhost fedoraproject.org fedoraproject.org.rpz
; <<>> DiG 9.11.19-RedHat-9.11.19-1.fc32 <<>> @localhost fedoraproject.org fedoraproject.org.rpz
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9119
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 18be2058b49777947fdfe6865ecd79a9b27b1b1a8af56411 (good)
;; QUESTION SECTION:
;fedoraproject.org. IN A
;; ANSWER SECTION:
fedoraproject.org. 60 IN A 209.132.181.16
fedoraproject.org. 60 IN A 8.43.85.67
fedoraproject.org. 60 IN A 209.132.181.15
fedoraproject.org. 60 IN A 8.43.85.73
fedoraproject.org. 60 IN A 209.132.190.2
fedoraproject.org. 60 IN A 152.19.134.198
fedoraproject.org. 60 IN A 67.219.144.68
fedoraproject.org. 60 IN A 152.19.134.142
fedoraproject.org. 60 IN A 140.211.169.196
fedoraproject.org. 60 IN A 140.211.169.206
;; Query time: 2088 msec
;; SERVER: ::1#53(::1)
;; WHEN: Út kvě 26 16:18:49 EDT 2020
;; MSG SIZE rcvd: 234
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29781
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 18be2058b4977794cd3f0de85ecd79a9f12d7b774321e5af (good)
;; QUESTION SECTION:
;fedoraproject.org.rpz. IN A
;; ANSWER SECTION:
fedoraproject.org.rpz. 10800 IN CNAME .
;; AUTHORITY SECTION:
. 10787 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020052602 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Út kvě 26 16:18:49 EDT 2020
;; MSG SIZE rcvd: 166
```
### What is the expected *correct* behavior?
```# dig @localhost fedoraproject.org fedoraproject.org.rpz
; <<>> DiG 9.11.19-RedHat-9.11.19-1.fc32 <<>> @localhost fedoraproject.org fedoraproject.org.rpz
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64203
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 23e5bc47d601101770fd1cec5ecd79e445cb2ae6747f2caf (good)
;; QUESTION SECTION:
;fedoraproject.org. IN A
;; ADDITIONAL SECTION:
rpz. 10800 IN SOA rpz. rpz.invalid. 0 86400 3600 604800 10800
;; Query time: 794 msec
;; SERVER: ::1#53(::1)
;; WHEN: Út kvě 26 16:19:48 EDT 2020
;; MSG SIZE rcvd: 124
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18813
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 23e5bc47d6011017372900095ecd79e44e185e5fce555b8c (good)
;; QUESTION SECTION:
;fedoraproject.org.rpz. IN A
;; ANSWER SECTION:
fedoraproject.org.rpz. 10800 IN CNAME .
;; AUTHORITY SECTION:
. 10791 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020052602 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Út kvě 26 16:19:48 EDT 2020
;; MSG SIZE rcvd: 166
```
### 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`.)
```
# named-checkconf -p
logging {
channel "default_debug" {
file "data/named.run";
severity dynamic;
};
category "rpz" {
"default_debug";
};
};
options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
geoip-directory "/usr/share/GeoIP";
listen-on port 53 {
127.0.0.1/32;
};
listen-on-v6 port 53 {
::1/128;
};
managed-keys-directory "/var/named/dynamic";
memstatistics-file "/var/named/data/named_mem_stats.txt";
pid-file "/run/named/named.pid";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
session-keyfile "/run/named/session.key";
statistics-file "/var/named/data/named_stats.txt";
disable-algorithms "." {
"RSAMD5";
"DSA";
};
disable-ds-digests "." {
"GOST";
};
dnssec-enable yes;
dnssec-validation yes;
recursion yes;
response-policy {
zone "rpz";
};
allow-query {
"localhost";
};
};
managed-keys {
"." initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
zone "." IN {
type hint;
file "named.ca";
};
zone "rpz" IN {
type master;
file "rpz.db.raw";
masterfile-format raw;
};
zone "localhost.localdomain" IN {
type master;
file "named.localhost";
allow-update {
"none";
};
};
zone "localhost" IN {
type master;
file "named.localhost";
allow-update {
"none";
};
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.loopback";
allow-update {
"none";
};
};
zone "1.0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-update {
"none";
};
};
zone "0.in-addr.arpa" IN {
type master;
file "named.empty";
allow-update {
"none";
};
};
```
```
; rpz.db
$TTL 3H
@ IN SOA @ rpz.invalid. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS @
A 127.0.0.1
AAAA ::1
nic.cz CNAME localhost.
fedoraproject.org CNAME .
redhat.com CNAME localhost.
download.proxmox.com CNAME na.cdn.proxmox.com.
```
### Relevant logs and/or screenshots
Reported under Fedora [bug 1833251](https://bugzilla.redhat.com/show_bug.cgi?id=1833251).
### Possible fixes
Version 9.16.3 was tested and does not have such issue.https://gitlab.isc.org/isc-projects/bind9/-/issues/1885checking for libuv... checking for libuv >= 1.0.0... no configure: error: lib...2020-05-27T13:49:16ZJim DeCarochecking for libuv... checking for libuv >= 1.0.0... no configure: error: libuv not foundSystem=Solaris 11.4 x86 64 bit virtual machine on VMware. Upgrading BIND from 9.14.9 to 9.16.3. New dependency libuv--has additional dependencies: pkg-config, automake, m4, libtool, autoconf. Installed dependencies + libuv-v1.38.0. ....System=Solaris 11.4 x86 64 bit virtual machine on VMware. Upgrading BIND from 9.14.9 to 9.16.3. New dependency libuv--has additional dependencies: pkg-config, automake, m4, libtool, autoconf. Installed dependencies + libuv-v1.38.0. ./configure phase of BIND install throws the above error message. ran "find / -name libuv* -print":
/usr/local/lib/libuv.so
/usr/local/lib/libuv.la
/usr/local/lib/libuv.so.1
/usr/local/lib/libuv.a
/usr/local/lib/libuv.so.1.0.0
/usr/local/lib/pkgconfig/libuv.pc
/usr/include/sys/libuvfs_ki.h
/usr/include/libuvfs.h
/usr/lib/amd64/libuvfs.so
/usr/lib/amd64/libuvfs.so.1
I am fairly new to this so I am unsure what the issue is. It does not look like libuv binaries were installed, but I am not sure. Any help would be appreciated.https://gitlab.isc.org/isc-projects/bind9/-/issues/1886Text edits in dlz.rst2020-06-08T10:16:09ZSuzanne GoldlustText edits in dlz.rstVarious content and grammar updatesVarious content and grammar updatesJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1887Text edits in dyndb.rst2020-06-08T10:16:11ZSuzanne GoldlustText edits in dyndb.rstVarious text updates to the dyndb.rst section of the BIND ARMVarious text updates to the dyndb.rst section of the BIND ARMJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1888Text edits in catz.rst2020-06-08T12:03:13ZSuzanne GoldlustText edits in catz.rstVarious content and grammar edits to the catz.rst section of the BIND ARMVarious content and grammar edits to the catz.rst section of the BIND ARMJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/kea/-/issues/1119add dhcp4 releases to perfdhcp2021-06-22T08:47:19ZWlodzimierz Wenceladd dhcp4 releases to perfdhcpAdd a new feature to perfdhcp to generate dhcpv4 release messages.Add a new feature to perfdhcp to generate dhcpv4 release messages.kea1.9.9Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1889Text edits in security.rst2020-05-28T16:25:36ZSuzanne GoldlustText edits in security.rstVarious text edits to the security.rst section of the BIND ARMVarious text edits to the security.rst section of the BIND ARMSuzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1892Reuse nmsockets in TCP2022-12-14T09:00:17ZWitold KrecickiReuse nmsockets in TCPWe currently don't reuse isc_nmsocket_t sockets at all, destroying them after a connection is closed. That's a performance hit for TCP. We should put a semi-ready (allocated + cond/mutex initialized) objects on a stack for reuse, just li...We currently don't reuse isc_nmsocket_t sockets at all, destroying them after a connection is closed. That's a performance hit for TCP. We should put a semi-ready (allocated + cond/mutex initialized) objects on a stack for reuse, just like we do with uvreqs and handles.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1893Not destroyed mutexes and conditionals lead to memory leaks on *BSD2020-06-10T11:26:17ZWitold KrecickiNot destroyed mutexes and conditionals lead to memory leaks on *BSDWhile on Linux mutexes and conditionals are self-contained within pthread_mutex_t and pthread_cond_t, respectively, on *BSD pthread_mutex_init and pthread_cond_init allocates memory. Not destroying those mutexes lead to memory leaksWhile on Linux mutexes and conditionals are self-contained within pthread_mutex_t and pthread_cond_t, respectively, on *BSD pthread_mutex_init and pthread_cond_init allocates memory. Not destroying those mutexes lead to memory leaksJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/1894Edits to CONTRIBUTING.md2020-06-08T10:15:56ZSuzanne GoldlustEdits to CONTRIBUTING.mdContent updates to CONTRIBUTING.mdContent updates to CONTRIBUTING.mdJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1895Text edits in security.rst (take 2)2020-06-01T13:27:03ZSuzanne GoldlustText edits in security.rst (take 2)Various text edits in the security.rst section of the BIND ARM (my first attempt with this issue would not let me create a merge request)Various text edits in the security.rst section of the BIND ARM (my first attempt with this issue would not let me create a merge request)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1896spurious root queries on timeout2023-11-02T16:58:16ZEvan Huntspurious root queries on timeoutReported by Ke Li <kl3158@columbia.edu> against 9.11.18 and 9.16.1.
```
Dear BIND authors,
We have documented specific cases where BIND9 (9.11.18 and 9.16.1)
generates generate requests to root servers which we think are not very
usef...Reported by Ke Li <kl3158@columbia.edu> against 9.11.18 and 9.16.1.
```
Dear BIND authors,
We have documented specific cases where BIND9 (9.11.18 and 9.16.1)
generates generate requests to root servers which we think are not very
useful. We would like to know if it is a known behavior or if there is
an underlying design choice for these queries that we do not understand?
Below is a brief overview of what we found.
The behavior we found is that when BIND9 has TLD servers' addresses in
the cache, which authoritative for domains like "com", and BIND9 gets an
A or AAAA type request like "some.example.com" from users, it still
sends requests like "ns1.example.com" to root and root server replies
with addresses of TLD servers again. The pattern looks like this:
user asks BIND9 Query: bidder.criteo.com, Type A =
BIND9 asks TLD servers To: 192.42.93.30 (g.gtld) Query: =
bidder.criteo.com, Type A =
Get a response from TLD servers From: 192.42.93.30 (g.gtld) Query: =
bidder.criteo.com =
=
Response: NS ns23.criteo.com NS =
ns22.criteo.com NS ns25.criteo.com NS =
ns26.criteo.com NS ns27.criteo.com NS =
ns28.criteo.com. All with A-type records in =
"Additional Records". =
BIND9 asks one of the nameservers. No reply To: 74.119.119.1 (ns25.criteo.=
com) Query: =
bidder.criteo.com, Type A =
BIND9 asks another nameserver. To: 182.161.73.4 (ns28.criteo.com) Query: =
bidder.criteo.com Type A =
And at the same time, =
=
BIND9 sends requests to root =
To: 192.58.128.30 (j.root) Query: =
ns22.criteo.com Type AAAA =
To: 192.58.128.30 (j.root) Query: =
ns23.criteo.com Type AAAA =
To: 192.58.128.30 (j.root) Query: =
ns27.criteo.com Type AAAA =
To: 192.58.128.30 (j.root) Query: =
ns25.criteo.com Type AAAA =
To: 192.58.128.30 (j.root) Query: =
ns26.criteo.com Type AAAA =
To: 192.58.128.30 (j.root) Query: =
ns28.criteo.com Type AAAA =
We deployed a BIND9 v9.11.18 instance and a BIND9 v9.16.1 locally and
loaded web captured traffic by Wireshark on port 53. Then we analyzed
the data and found several about these interesting requests to root.
1. they are requesting authoritative nameservers of a subdomain or a
hostname. For "ns23.criteo.com" and "ns22.criteo.com" are authoritative
nameservers for
2. they are requesting records that are not in the last level
nameserver's response. For in the response from the TLD server to
BIND9's request on "bidder.criteo.com", there is no type record (in
"Additional Records") for nameserver "ns23.criteo.com", so BIND9 later
AAAA type request on "ns23.criteo.com" to root.
3. if BIND9 timeouts when it queries one of these nameservers, BIND9
will generate these requests to root. For example, after getting the
response from the TLD server on "bidder.criteo.com", BIND9 goes ahead
and sends a request on "bidder.criteo.com" to "ns25.criteo.com", but
there is no reply. Then BIND9 will send the request to another name
server (randomly chose) "ns28.criteo.com" and also generate requests to
root.
Therefore, we guess this kind of request are generated by timeouts when
BIND9 queries nameservers. We then tried to validate our hypothesis. We
manually created timeouts iptables to ban IPs of some nameservers and
the same behavior happened. A simple test pcap file as an example is
attached, with an explanation. Also, the configuration file of our
deployment is attached. We then validated our hypothesis on a recursive
resolver at an academic institution running BIND9 v9.11.14, found out
that around 80% A and AAAA root servers were in this pattern.
We'd appreciate it if you help us understand this behavior. We mainly
are curious about reason behind it. Is it a necessary design or is it
avoidable? We think maybe some DNS root servers would be saved if BIND9
could avoid this kind of behavior.
Thank you very much!
````Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1897max-transfer-time-* and max-transfer-idle-* broken since 9.15.62023-04-05T18:20:10ZBrian Conrymax-transfer-time-* and max-transfer-idle-* broken since 9.15.6In 53f0b6c34d3f ("convert ns_client and related objects to use netmgr"), the logic for setting a timer to enforce `max-transfer-time-out` and `max-transfer-idle-out` was removed.
In 49d53a4aa95682f9d94da4c6fa68ded66283cce9 ("use netmgr ...In 53f0b6c34d3f ("convert ns_client and related objects to use netmgr"), the logic for setting a timer to enforce `max-transfer-time-out` and `max-transfer-idle-out` was removed.
In 49d53a4aa95682f9d94da4c6fa68ded66283cce9 ("use netmgr for xfrin"), the `max-transfer-time-in` and `max-transfer-idle-in` options have met a similar destiny.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1898'.rst' files should be independent of configure option.2020-06-29T13:33:15ZMark Andrews'.rst' files should be independent of configure option.'.rst' files are being generated from doc/misc/options which has different line breaks depending upon which configure options are set as ' // not configured' differs. This impacts on the generated '.rst' files leading to churn in them. ...'.rst' files are being generated from doc/misc/options which has different line breaks depending upon which configure options are set as ' // not configured' differs. This impacts on the generated '.rst' files leading to churn in them. The '.rst' files are nominally independent of configure options.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1899TCP Accept Refactoring broke Windows2020-06-08T12:19:30ZOndřej SurýTCP Accept Refactoring broke WindowsThe !3320 that got merged to master broke TCP connections on Windows. This needs to be fixed on master (before we release next 9.17.2) and also before we merged the backport to the BIND 9.16 branch.The !3320 that got merged to master broke TCP connections on Windows. This needs to be fixed on master (before we release next 9.17.2) and also before we merged the backport to the BIND 9.16 branch.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecicki