BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2018-09-04T01:51:38Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/523Add release note on "IPv6 now required" and "old quirks removed"2018-09-04T01:51:38ZOndřej SurýAdd release note on "IPv6 now required" and "old quirks removed"BIND-9.13.3Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/524stderr log seems to be not working2018-09-03T19:40:42ZGhost Userstderr log seems to be not workingHi,
I'm trying to migrate my old systems into docker containers, so I have created the following setup:
Dockerfile:
```
FROM debian:stretch
COPY VERSION /
RUN apt-get update && apt-get -y install bind9
RUN mkdir /var/l...Hi,
I'm trying to migrate my old systems into docker containers, so I have created the following setup:
Dockerfile:
```
FROM debian:stretch
COPY VERSION /
RUN apt-get update && apt-get -y install bind9
RUN mkdir /var/log/named && chown bind:bind /var/log/named
COPY docker-entrypoint.sh /
ENTRYPOINT ["/docker-entrypoint.sh"]
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
```
docker-entrypoint.sh:
```
#!/bin/bash
set -e
cat <<EOF >> /etc/bind/named.conf.options
logging {
channel general {
file "/var/log/named/general.log" versions 5;
print-time yes;
print-category yes;
print-severity yes;
};
channel default_stderr {
stderr;
severity info;
};
category default { general; default_stderr; };
};
EOF
/etc/init.d/bind9 start
while sleep 5; do
date
done
```
I would like to redirect all the logs to the standard output, in order to see and catch it from outside, but it doesn't work whatever I try. It writes the log into the general log, but not to the stderr.
I read in another ticket that some log entries have been created before it parses the logs, but it writes nothing to the stderr, so I guess its not the case here.
Can someone show me a direction, how to solve this problem, or what am I missing?:)
ps: of course I tried it without general as well, like this:
`
category default { default_stderr; };
`
Thanks in advance!!https://gitlab.isc.org/isc-projects/bind9/-/issues/525Cleanup platform.h for stuff not exposed to the headers2019-07-01T15:12:44ZOndřej SurýCleanup platform.h for stuff not exposed to the headersThe `platform.h` header contains some defines that are actually not exposed to the outside, but used only internally. Those should be moved into `config.h`.The `platform.h` header contains some defines that are actually not exposed to the outside, but used only internally. Those should be moved into `config.h`.BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/526Include / link order needs to be adjusted when trying to override OpenSSL ins...2021-10-04T23:54:24ZMark AndrewsInclude / link order needs to be adjusted when trying to override OpenSSL instancesIf you are wanting to use a newer OpenSSL (--with-openssl=path) with named than that installed in /usr/local, /opt/local etc. the -I, -L and -R arguments need to moved before -[ILR]/{usr,opt}/local/*.
Similarly for other --with but Open...If you are wanting to use a newer OpenSSL (--with-openssl=path) with named than that installed in /usr/local, /opt/local etc. the -I, -L and -R arguments need to moved before -[ILR]/{usr,opt}/local/*.
Similarly for other --with but OpenSSL is the major culprit.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/527Master branch incorrectly reports missing thread support2018-09-04T19:06:34ZRay BellisMaster branch incorrectly reports missing thread supportrunning master branch, I see this on startup:
```
04-Sep-2018 10:11:35.955 threads support is disabled
```
It's conditional on the macro `ISC_PLATFORM_USETHREADS` which AFAIK no longer existsrunning master branch, I see this on startup:
```
04-Sep-2018 10:11:35.955 threads support is disabled
```
It's conditional on the macro `ISC_PLATFORM_USETHREADS` which AFAIK no longer existshttps://gitlab.isc.org/isc-projects/bind9/-/issues/52832bit build on windows is currently broken2018-09-06T00:03:01ZCurtis Blackburn32bit build on windows is currently broken```
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 9/4/2018 1:32:55 PM.
Project "c:\cygwin64\home\jenkins\workspace\bind9-build-win32-tmp\win32utils\bind9.sln" on...```
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 9/4/2018 1:32:55 PM.
Project "c:\cygwin64\home\jenkins\workspace\bind9-build-win32-tmp\win32utils\bind9.sln" on node 1 (Build target(s)).
c:\cygwin64\home\jenkins\workspace\bind9-build-win32-tmp\win32utils\bind9.sln.metaproj : error MSB4126: The specified solution configuration "Release|x86" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration. [c:\cygwin64\home\jenkins\workspace\bind9-build-win32-tmp\win32utils\bind9.sln]
Done Building Project "c:\cygwin64\home\jenkins\workspace\bind9-build-win32-tmp\win32utils\bind9.sln" (Build target(s)) -- FAILED.
Build FAILED.
```https://gitlab.isc.org/isc-projects/bind9/-/issues/529Negative Trust Anchors can disappear after "rndc reconfig" or "rndc reload"2018-09-06T13:03:19ZMichael McNallyNegative Trust Anchors can disappear after "rndc reconfig" or "rndc reload"<!--
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
Reported by a customer who is running BIND Supported Preview Edition 9.10.6-S3: Negative Trust Anchors (NTAs) can disappear after an "rndc reconfig" or "rndc reload"
### Steps to reproduce
We asked the customer to list their NTAs, reconfigure, and list again:
```
$ rndc nta -dump |wc -l
100
$ rndc reconfig
$ rndc nta -dump |wc -l
0
```
### What is the current *bug* behavior?
Named appears to lose track of the NTAs after "rndc reconfigure". Per the customer, also after "rndc reload"
### What is the expected *correct* behavior?
Per the ARM, NTAs should persist through their valid lifetime, even across named restarts.https://gitlab.isc.org/isc-projects/bind9/-/issues/530Slave server dose not use the source of received NOTIFY as its first choice o...2019-03-28T13:04:10Znanwn147929@alibaba-inc.comSlave server dose not use the source of received NOTIFY as its first choice of master### Description
As described in RFC 1996:
>Note:
> Because a deep server dependency graph may have multiple paths
> from the primary master to any given slave, it is possible that
> a slave will receive a NOTIFY from one ...### Description
As described in RFC 1996:
>Note:
> Because a deep server dependency graph may have multiple paths
> from the primary master to any given slave, it is possible that
> a slave will receive a NOTIFY from one of its known masters even
> though the rest of its known masters have not yet updated their
> copies of the zone. Therefore, when issuing a QUERY for the
> zone's SOA, the query should be directed at the known master who
> was the source of the NOTIFY event, and not at any of the other
> known masters. This represents a departure from [RFC1035],
> which specifies that upon expiry of the SOA REFRESH interval,
> all known masters should be queried in turn.
It is recommended to send SOA query directly to the NOTIFY source.
BIND9's source code seems to follow the rule, in function `dns_zone_notifyreceive2`:
```C
/*
* If type != T_SOA return DNS_R_NOTIMP. We don't yet support
* ROLLOVER.
*
* SOA: RFC1996
* Check that 'from' is a valid notify source, (zone->masters).
* Return DNS_R_REFUSED if not.
*
* If the notify message contains a serial number check it
* against the zones serial and return if <= current serial
*
* If a refresh check is progress, if so just record the
* fact we received a NOTIFY and from where and return.
* We will perform a new refresh check when the current one
* completes. Return ISC_R_SUCCESS.
*
* Otherwise initiate a refresh check using 'from' as the
* first address to check. Return ISC_R_SUCCESS.
*/
```
The source of NOTIFY is recorded in `zone->notifyfrom` but never used. In fact, the slave selects its master to refresh from beginning to end based on the `masters` configuration order.
CONS:
* Violates the RFC and the code design.
* If the first master is always available, its transfer load is heavy while other masters have nothing to do.
* A successful NOTIFY reception indicates that the master is available temporarily, pick it is better than pick any other unsure masters.
### Request
When issuing a QUERY for the zone's SOA, the query should be directed at the known master who was the source of the NOTIFY.
### Links / references
A patch is attached.
[diff](/uploads/d521e9286029bb41379cb53f2248c215/diff)https://gitlab.isc.org/isc-projects/bind9/-/issues/532master doesn't build on MacOS due to class of ALIGN macros2018-09-09T23:27:46ZMark Andrewsmaster doesn't build on MacOS due to class of ALIGN macrosIn file included from app.c:43:
../include/isc/util.h:265:9: error: 'ALIGN' macro redefined
[-Werror,-Wmacro-redefined]
#define ALIGN(x, a) (((x) + (a) - 1) & ~((typeof(x))(a)-1))
^
/usr/include/i386/param.h:83:9: note: pre...In file included from app.c:43:
../include/isc/util.h:265:9: error: 'ALIGN' macro redefined
[-Werror,-Wmacro-redefined]
#define ALIGN(x, a) (((x) + (a) - 1) & ~((typeof(x))(a)-1))
^
/usr/include/i386/param.h:83:9: note: previous definition is here
#define ALIGN(p) __DARWIN_ALIGN(p)https://gitlab.isc.org/isc-projects/bind9/-/issues/533Investigate the use of recvmmsg and sendmmsg to improve performance [ISC-supp...2021-06-03T16:34:40ZBrian ConryInvestigate the use of recvmmsg and sendmmsg to improve performance [ISC-support #12178]While I think I've heard that some people have looked into this some already, I couldn't find a gitlab issue for Bugs ticket 46288.
Since this was raised by a customer I've created this to make sure that the idea doesn't get dropped acc...While I think I've heard that some people have looked into this some already, I couldn't find a gitlab issue for Bugs ticket 46288.
Since this was raised by a customer I've created this to make sure that the idea doesn't get dropped accidentally.https://gitlab.isc.org/isc-projects/bind9/-/issues/534Allow only DNS64 reverse zone to be configured independently of the DNS64 clause2023-10-08T12:48:08ZMark AndrewsAllow only DNS64 reverse zone to be configured independently of the DNS64 clausedns64 currently configures both the DNS64 synthesis and a DNS64 reverse zone.
If a customer is using RFC 7050 (IPV4ONLY.ARPA) or some other mechanism to publish the NAT64 prefix but not DNS64 the reverse zone synthesis is still needed.dns64 currently configures both the DNS64 synthesis and a DNS64 reverse zone.
If a customer is using RFC 7050 (IPV4ONLY.ARPA) or some other mechanism to publish the NAT64 prefix but not DNS64 the reverse zone synthesis is still needed.https://gitlab.isc.org/isc-projects/bind9/-/issues/535named is broken on linux due to user permissions2019-09-24T14:12:11ZEvan Huntnamed is broken on linux due to user permissionsChange number 5031 (GL #525) broke named's ability to change UID for file access on linux. On ubuntu 16.04 I have a named.conf file owned by user "each" and named cannot load it, either with `sudo named` or `sudo named -ueach`. This is a...Change number 5031 (GL #525) broke named's ability to change UID for file access on linux. On ubuntu 16.04 I have a named.conf file owned by user "each" and named cannot load it, either with `sudo named` or `sudo named -ueach`. This is almost certainly due to the removal of HAVE_LINUXTHREADS code in bin/named/unix/os.c.https://gitlab.isc.org/isc-projects/bind9/-/issues/536Add a MacOS instance to CI2021-10-15T12:32:03ZMark AndrewsAdd a MacOS instance to CIWe had a build failure on MacOS committed due to MacOS not being part of CI.We had a build failure on MacOS committed due to MacOS not being part of CI.https://gitlab.isc.org/isc-projects/bind9/-/issues/537Add a CI step to test named -u2019-11-29T08:34:08ZEvan HuntAdd a CI step to test named -uIn light of #535, it seems worthwhile to add a CI step that runs as root and attempts to switch UID.
Gitlab CI does run at least one thing as root (ifconfig.sh) so this ought to be possible.
I can write the test, but I don't know how t...In light of #535, it seems worthwhile to add a CI step that runs as root and attempts to switch UID.
Gitlab CI does run at least one thing as root (ifconfig.sh) so this ought to be possible.
I can write the test, but I don't know how to make it work on the runner, so I'll assign the issue to @ondrej to begin with.Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/538max-cache-size value by default is set to maximum value of uint64_t in chroot...2020-04-16T09:56:17Znanwn147929@alibaba-inc.commax-cache-size value by default is set to maximum value of uint64_t in chroot mode<!--
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
The max-cache-size is set to the max value of uint64_t in chroot mode by default.
### Steps to reproduce
Run named in chroot mode.
### What is the current *bug* behavior?
The max-cache-size is set to the max value of uint64_t in chroot mode.
### What is the expected *correct* behavior?
By default, the max-cache-size should be set to the 90% of the physical memory size.
### Relevant configuration files
### Relevant logs and/or screenshots
Run in choot mode:
```11-Sep-2018 13:45:55.660 none:99: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)```
Run in normal mode:
```11-Sep-2018 13:50:34.153 none:100: 'max-cache-size 90%' - setting to 174419MB (out of 193799MB)```
### Possible fixes
Some configuration files might be copied to `chroot/etc/` like `localtime`, but I have no idea what configuration files should be copied.https://gitlab.isc.org/isc-projects/bind9/-/issues/539rrsetorder test not portable2018-09-11T19:56:30ZCurtis Blackburnrrsetorder test not portableopenbsd doesnt have `seq` and
solaris (IIRC) doesnt like the `$()` constructopenbsd doesnt have `seq` and
solaris (IIRC) doesnt like the `$()` constructEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/540TSIG has two consecutive spaces when MACLEN is 02018-09-27T20:43:24ZMark AndrewsTSIG has two consecutive spaces when MACLEN is 0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/541After implementing hook modules, add a way to check them with named-checkconf2018-11-04T01:35:30ZEvan HuntAfter implementing hook modules, add a way to check them with named-checkconfThe following discussion from !632 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/632#note_20464):
> In the long run, we could use a method for checking various h...The following discussion from !632 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/632#note_20464):
> In the long run, we could use a method for checking various hook module configurations.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/542Zones are not always reloaded correctly2018-09-27T02:46:55ZGhost UserZones are not always reloaded correctly### Summary
Zones are not always reloaded correcly. This does not happens for all Zones and seems unpredictable.
The zones tested are NOT dnssec signed.
### Steps to reproduce
This issue seems to be non-deteministic. In Order to repro...### Summary
Zones are not always reloaded correcly. This does not happens for all Zones and seems unpredictable.
The zones tested are NOT dnssec signed.
### Steps to reproduce
This issue seems to be non-deteministic. In Order to reproduce change same zones and let the bind master reload all zones `rndc reload`.
Sometimes one of the modified zones does not get updated on the slaves.
I was unable to reproduce this behavier while log level was increased to 9 using `rndc trace 9`.
Im using the following script as a testcase:
```
(#Add Test Data to Zones
date; for domain in example.{de,org}.{test,appr};
do ls -alh ${domain}.zone;
sed -i '/;### \[EOF\]/i *.test CNAME test00.orga.de.' ${domain}.zone;
echo ${domain};
grep '^@.*SOA' ${domain}.zone | awk "{printf \"${domain}: \"; print \$7}";
dig @resolv0 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv0 - \"; printf \"${domain}: \"; print \$7}"
dig @resolv1 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv1 - \"; printf \"${domain}: \"; print \$7}"
dig @resolv2 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv2 - \"; printf \"${domain}: \"; print \$7}"
done;
# Send Test Data out to resolvers using internal scripts to increase SOA serial, syncronize masters and reload masters using 'rndc reload'
./_mkzone -b -s ml ALL;
./_sync-and-reload > /dev/null ; # This script blocks at least for 10s after reloading bind
# Verify Testdata is available on resolvers
date; for domain in example.{de,org}.{test,appr};
do grep '^@.*SOA' ${domain}.zone | awk "{printf \"${domain}: \"; print \$7}";
dig @resolv0 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv0 - \"; printf \"${domain}: \"; print \$7}"
dig @resolv1 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv1 - \"; printf \"${domain}: \"; print \$7}"
dig @resolv2 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv2 - \"; printf \"${domain}: \"; print \$7}"
echo -n "resolv0: ";
dig @resolv0 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
echo -n "resolv1: ";
dig @resolv1 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
echo -n "resolv2: ";
dig @resolv2 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
done;
# Modify zone
date; for domain in example.{de,org}.{test,appr};
do echo ${domain};
sed -i 's/\*.test.*CNAME.*test00\.orga\.de\./*.test CNAME test01.orga.de./g' ${domain}.zone;
done;
# Send Test Data out to resolvers
./_mkzone -b -s ml ALL;
./_sync-and-reload > /dev/null;
# Check if modifications are present on resolvers
date; for domain in example.{de,org}.{test,appr};
do grep '^@.*SOA' ${domain}.zone | awk "{printf \"${domain}: \"; print \$7}";
dig @resolv0 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv0 - \"; printf \"${domain}: \"; print \$7}"
dig @resolv1 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv1 - \"; printf \"${domain}: \"; print \$7}"
dig @resolv2 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv2 - \"; printf \"${domain}: \"; print \$7}"
echo -n "resolv0: ";
dig @resolv0 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
echo -n "resolv1: ";
dig @resolv1 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
echo -n "resolv2: ";
dig @resolv2 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
done;
# Cleanup
for domain in example.{de,org}.{test,appr};
do sed -i '/^\*\.test.*CNAME.*test01\.orga\.de.*/ d' ${domain}.zone;
done;
# Send out to resolvers
./_mkzone -b -s ml ALL;
./_sync-and-reload > /dev/null;
# Check if modifications are present on resolvers
date; for domain in example.{de,org}.{test,appr};
do grep '^@.*SOA' ${domain}.zone | awk "{printf \"${domain}: \"; print \$7}";
dig @resolv0 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv0 - \"; printf \"${domain}: \"; print \$7}"
dig @resolv1 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv1 - \"; printf \"${domain}: \"; print \$7}"
dig @resolv2 ${domain} SOA | grep -v '^;' | sed '/^$/d' | awk "{printf \"resolv2 - \"; printf \"${domain}: \"; print \$7}"
echo -n "resolv0: ";
dig @resolv0 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
echo -n "resolv1: ";
dig @resolv1 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
echo -n "resolv2: ";
dig @resolv2 abc.test.${domain} | grep -v '^;' | sed '/^$/d'
done;
echo 'finished'; date;
) | less
```
### What is the current *bug* behavior?
Not all zones are loaded as expected and wrong/no notifications are send to slaves.
But may the output of my testcase tell's more then 1000 words...
```
Mon Sep 17 10:10:02 CEST 2018
-rw-r--r-- 1 root root 1.2K Sep 17 10:01 example.de.test.zone
example.de.test
example.de.test: 2018091705
resolv0 - example.de.test: 2018091704
resolv1 - example.de.test: 2018091704
resolv2 - example.de.test: 2018091704
-rw-r--r-- 1 root root 1.1K Sep 17 10:01 example.de.appr.zone
example.de.appr
example.de.appr: 2018091705
resolv0 - example.de.appr: 2018091705
resolv1 - example.de.appr: 2018091705
resolv2 - example.de.appr: 2018091705
-rw-r--r-- 1 root root 1.8K Sep 17 10:01 example.org.test.zone
example.org.test
example.org.test: 2018091705
resolv0 - example.org.test: 2018091705
resolv1 - example.org.test: 2018091705
resolv2 - example.org.test: 2018091705
-rw-r--r-- 1 root root 1.8K Sep 17 10:01 example.org.appr.zone
example.org.appr
example.org.appr: 2018091705
resolv0 - example.org.appr: 2018091705
resolv1 - example.org.appr: 2018091705
resolv2 - example.org.appr: 2018091705
Processing example.de.test.zone Zonefile
New Entry: *.test IN CNAME test00.orga.de. ;20180917-101002/ml
Processing example.org.test.zone Zonefile
New Entry: *.test IN CNAME test00.orga.de. ;20180917-101002/ml
Processing example.de.appr.zone Zonefile
New Entry: *.test IN CNAME test00.orga.de. ;20180917-101002/ml
Processing example.org.appr.zone Zonefile
New Entry: *.test IN CNAME test00.orga.de. ;20180917-101002/ml
Mon Sep 17 10:10:17 CEST 2018
example.de.test: 2018091706
resolv0 - example.de.test: 2018091706
resolv1 - example.de.test: 2018091706
resolv2 - example.de.test: 2018091706
resolv0: abc.test.example.de.test. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv1: abc.test.example.de.test. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv2: abc.test.example.de.test. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
example.de.appr: 2018091706
resolv0 - example.de.appr: 2018091706
resolv1 - example.de.appr: 2018091706
resolv2 - example.de.appr: 2018091706
resolv0: abc.test.example.de.appr. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv1: abc.test.example.de.appr. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv2: abc.test.example.de.appr. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
example.org.test: 2018091706
resolv0 - example.org.test: 2018091705
resolv1 - example.org.test: 2018091705
resolv2 - example.org.test: 2018091705
resolv0: abc.test.example.org.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
resolv1: abc.test.example.org.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
resolv2: abc.test.example.org.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
example.org.appr: 2018091706
resolv0 - example.org.appr: 2018091705
resolv1 - example.org.appr: 2018091705
resolv2 - example.org.appr: 2018091705
resolv0: abc.test.example.org.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
resolv1: abc.test.example.org.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
resolv2: abc.test.example.org.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
Mon Sep 17 10:10:17 CEST 2018
example.de.test
example.de.appr
example.org.test
example.org.appr
Processing example.de.test.zone Zonefile
Processing example.org.test.zone Zonefile
Processing example.de.appr.zone Zonefile
Processing example.org.appr.zone Zonefile
Mon Sep 17 10:10:32 CEST 2018
example.de.test: 2018091707
resolv0 - example.de.test: 2018091706
resolv1 - example.de.test: 2018091706
resolv2 - example.de.test: 2018091706
resolv0: abc.test.example.de.test. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv1: abc.test.example.de.test. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv2: abc.test.example.de.test. 3600 IN CNAME test00.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
example.de.appr: 2018091707
resolv0 - example.de.appr: 2018091707
resolv1 - example.de.appr: 2018091707
resolv2 - example.de.appr: 2018091707
resolv0: abc.test.example.de.appr. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv1: abc.test.example.de.appr. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv2: abc.test.example.de.appr. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
example.org.test: 2018091707
resolv0 - example.org.test: 2018091707
resolv1 - example.org.test: 2018091707
resolv2 - example.org.test: 2018091707
resolv0: abc.test.example.org.test. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv1: abc.test.example.org.test. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv2: abc.test.example.org.test. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
example.org.appr: 2018091707
resolv0 - example.org.appr: 2018091707
resolv1 - example.org.appr: 2018091707
resolv2 - example.org.appr: 2018091707
resolv0: abc.test.example.org.appr. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv1: abc.test.example.org.appr. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
resolv2: abc.test.example.org.appr. 3600 IN CNAME test01.orga.de.
orga.de. 60 IN SOA resolv.orga.de. hostmaster.orga.de. 2018091002 60 60 2419200 60
Processing example.de.test.zone Zonefile
Processing example.org.test.zone Zonefile
Processing example.de.appr.zone Zonefile
Processing example.org.appr.zone Zonefile
Mon Sep 17 10:10:47 CEST 2018
example.de.test: 2018091708
resolv0 - example.de.test: 2018091708
resolv1 - example.de.test: 2018091708
resolv2 - example.de.test: 2018091708
resolv0: abc.test.example.de.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
resolv1: abc.test.example.de.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
resolv2: abc.test.example.de.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
example.de.appr: 2018091708
resolv0 - example.de.appr: 2018091708
resolv1 - example.de.appr: 2018091708
resolv2 - example.de.appr: 2018091708
resolv0: abc.test.example.de.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
resolv1: abc.test.example.de.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
resolv2: abc.test.example.de.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
example.org.test: 2018091708
resolv0 - example.org.test: 2018091708
resolv1 - example.org.test: 2018091708
resolv2 - example.org.test: 2018091708
resolv0: abc.test.example.org.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
resolv1: abc.test.example.org.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
resolv2: abc.test.example.org.test. 3600 IN CNAME httpd-i06.orga.de.test.
...
example.org.appr: 2018091708
resolv0 - example.org.appr: 2018091708
resolv1 - example.org.appr: 2018091708
resolv2 - example.org.appr: 2018091708
resolv0: abc.test.example.org.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
resolv1: abc.test.example.org.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
resolv2: abc.test.example.org.appr. 3600 IN CNAME httpd-i06.orga.de.appr.
...
finished
Mon Sep 17 10:10:47 CEST 2018
```
### What is the expected *correct* behavior?
All zones should load correctly and notifications should be send after reloading bind if SOA Serial was updated.
### Relevant configuration files
```
# named -V
BIND 9.12.1-P2 <id:14b0e01>
running on Linux x86_64 4.14.43-gentoo #3 SMP Thu May 24 12:58:31 CEST 2018
built by make with '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-libtool' '--enable-full-report' '--without-readline' '--enable-linux-caps' '--disable-dnsrps' '--disable-fixed-rrset' '--disable-ipv6' '--disable-rpz-nsdname' '--disable-rpz-nsip' '--disable-seccomp' '--enable-threads' '--without-dlz-bdb' '--without-dlopen' '--without-dlz-filesystem' '--without-dlz-stub' '--without-gost' '--without-gssapi' '--without-idn' '--without-libjson' '--without-dlz-ldap' '--without-dlz-mysql' '--without-dlz-odbc' '--without-dlz-postgres' '--without-lmdb' '--without-python' '--with-ecdsa' '--with-openssl=/usr' '--without-libxml2' '--with-zlib' '--with-randomdev=/dev/random' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=nocona -O2 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'
compiled by GCC 5.4.0
compiled with OpenSSL version: OpenSSL 1.0.2n 7 Dec 2017
linked to OpenSSL version: OpenSSL 1.0.2n 7 Dec 2017
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
```
Additionally the patch provided in #435 is applied.
### Relevant logs and/or screenshots
default.log
```
17-Sep-2018 10:10:05.696 automatic empty zone: view Intranet: 10.IN-ADDR.ARPA
...
17-Sep-2018 10:10:05.836 automatic empty zone: view Localhost: EMPTY.AS112.ARPA
17-Sep-2018 10:10:05.898 zone example.de.appr/IN/Intranet: loaded serial 2018091706
17-Sep-2018 10:10:06.059 zone 69.10.in-addr.arpa/IN/Intranet: loaded serial 2018091727
17-Sep-2018 10:10:06.061 zone example.org.appr/IN/Intranet: loaded serial 2018091706
17-Sep-2018 10:10:06.063 zone example.org.test/IN/Intranet: loaded serial 2018091706
17-Sep-2018 10:10:06.065 zone example.de.test/IN/Intranet: loaded serial 2018091706
17-Sep-2018 10:10:20.681 automatic empty zone: view Intranet: 10.IN-ADDR.ARPA
...
17-Sep-2018 10:10:20.821 automatic empty zone: view Localhost: EMPTY.AS112.ARPA
17-Sep-2018 10:10:20.873 zone example.de.appr/IN/Intranet: loaded serial 2018091707
17-Sep-2018 10:10:21.008 zone 69.10.in-addr.arpa/IN/Intranet: loaded serial 2018091731
17-Sep-2018 10:10:21.029 zone example.org.appr/IN/Intranet: loaded serial 2018091707
17-Sep-2018 10:10:21.035 zone example.org.test/IN/Intranet: loaded serial 2018091707
17-Sep-2018 10:10:21.037 zone example.de.test/IN/Intranet: loaded serial 2018091707
17-Sep-2018 10:10:35.679 automatic empty zone: view Intranet: 10.IN-ADDR.ARPA
...
17-Sep-2018 10:10:35.815 automatic empty zone: view Localhost: EMPTY.AS112.ARPA
17-Sep-2018 10:10:35.871 zone example.de.appr/IN/Intranet: loaded serial 2018091708
17-Sep-2018 10:10:35.968 zone 69.10.in-addr.arpa/IN/Intranet: loaded serial 2018091735
17-Sep-2018 10:10:36.010 zone example.org.appr/IN/Intranet: loaded serial 2018091708
17-Sep-2018 10:10:36.027 zone example.org.test/IN/Intranet: loaded serial 2018091708
17-Sep-2018 10:10:36.034 zone example.de.test/IN/Intranet: loaded serial 2018091708
```
general.log
```
17-Sep-2018 10:10:05.662 received control channel command 'reload'
17-Sep-2018 10:10:05.663 loading configuration from '/etc/bind/named.conf'
17-Sep-2018 10:10:05.688 reading built-in trust anchors from file '/etc/bind/bind.keys'
17-Sep-2018 10:10:05.689 using default UDP/IPv4 port range: [32768, 60999]
17-Sep-2018 10:10:05.690 using default UDP/IPv6 port range: [32768, 60999]
17-Sep-2018 10:10:05.691 sizing zone task pool based on 184 zones
17-Sep-2018 10:10:05.838 configuring command channel from '/etc/bind/rndc.key'
17-Sep-2018 10:10:05.844 reloading configuration succeeded
...
17-Sep-2018 10:10:05.851 reloading zones succeeded
17-Sep-2018 10:10:05.881 managed-keys-zone/Resolver: Key 19036 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:05.882 managed-keys-zone/Resolver: Key 20326 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:05.897 master/intranet/example.de.appr.zone:7: using RFC1035 TTL semantics
17-Sep-2018 10:10:05.898 managed-keys-zone/Intranet: Key 19036 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:05.899 managed-keys-zone/Intranet: Key 20326 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:05.904 all zones loaded
...
17-Sep-2018 10:10:06.060 master/intranet/example.org.appr.zone:12: using RFC1035 TTL semantics
17-Sep-2018 10:10:06.062 master/intranet/example.org.test.zone:12: using RFC1035 TTL semantics
17-Sep-2018 10:10:06.064 master/intranet/example.de.test.zone:8: using RFC1035 TTL semantics
...
17-Sep-2018 10:10:20.661 received control channel command 'reload'
17-Sep-2018 10:10:20.661 loading configuration from '/etc/bind/named.conf'
17-Sep-2018 10:10:20.673 reading built-in trust anchors from file '/etc/bind/bind.keys'
17-Sep-2018 10:10:20.674 using default UDP/IPv4 port range: [32768, 60999]
17-Sep-2018 10:10:20.675 using default UDP/IPv6 port range: [32768, 60999]
17-Sep-2018 10:10:20.676 sizing zone task pool based on 184 zones
17-Sep-2018 10:10:20.823 configuring command channel from '/etc/bind/rndc.key'
17-Sep-2018 10:10:20.831 reloading configuration succeeded
17-Sep-2018 10:10:20.834 reloading zones succeeded
17-Sep-2018 10:10:20.860 managed-keys-zone/Resolver: Key 19036 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:20.861 managed-keys-zone/Resolver: Key 20326 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:20.867 managed-keys-zone/Localhost: Key 19036 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:20.867 managed-keys-zone/Localhost: Key 20326 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:20.873 master/intranet/example.de.appr.zone:7: using RFC1035 TTL semantics
17-Sep-2018 10:10:20.876 master/intranet/69.10.in-addr.arpa.zone:4: using RFC1035 TTL semantics
17-Sep-2018 10:10:20.877 managed-keys-zone/Intranet: Key 19036 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:20.877 managed-keys-zone/Intranet: Key 20326 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:20.880 all zones loaded
...
17-Sep-2018 10:10:20.882 running
...
17-Sep-2018 10:10:21.029 master/intranet/example.org.appr.zone:12: using RFC1035 TTL semantics
...
17-Sep-2018 10:10:21.035 master/intranet/example.org.test.zone:12: using RFC1035 TTL semantics
17-Sep-2018 10:10:21.036 master/intranet/example.de.test.zone:8: using RFC1035 TTL semantics
...
17-Sep-2018 10:10:28.801 received control channel command 'stats'
17-Sep-2018 10:10:28.803 dumpstats complete
17-Sep-2018 10:10:35.658 received control channel command 'reload'
17-Sep-2018 10:10:35.659 loading configuration from '/etc/bind/named.conf'
17-Sep-2018 10:10:35.670 reading built-in trust anchors from file '/etc/bind/bind.keys'
17-Sep-2018 10:10:35.671 using default UDP/IPv4 port range: [32768, 60999]
17-Sep-2018 10:10:35.672 using default UDP/IPv6 port range: [32768, 60999]
17-Sep-2018 10:10:35.673 sizing zone task pool based on 184 zones
17-Sep-2018 10:10:35.818 configuring command channel from '/etc/bind/rndc.key'
17-Sep-2018 10:10:35.824 reloading configuration succeeded
...
17-Sep-2018 10:10:35.832 reloading zones succeeded
17-Sep-2018 10:10:35.857 managed-keys-zone/Resolver: Key 19036 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:35.857 managed-keys-zone/Resolver: Key 20326 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:35.859 managed-keys-zone/Internet: Key 19036 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:35.859 managed-keys-zone/Internet: Key 20326 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:35.870 master/intranet/example.de.appr.zone:7: using RFC1035 TTL semantics
17-Sep-2018 10:10:35.873 master/intranet/69.10.in-addr.arpa.zone:4: using RFC1035 TTL semantics
17-Sep-2018 10:10:35.875 managed-keys-zone/Intranet: Key 19036 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:35.875 managed-keys-zone/Intranet: Key 20326 for zone . is now trusted (acceptance timer complete)
17-Sep-2018 10:10:35.877 all zones loaded
...
17-Sep-2018 10:10:35.880 running
...
17-Sep-2018 10:10:36.009 master/intranet/example.org.appr.zone:12: using RFC1035 TTL semantics
...
17-Sep-2018 10:10:36.027 master/intranet/example.org.test.zone:12: using RFC1035 TTL semantics
...
17-Sep-2018 10:10:36.034 master/intranet/example.de.test.zone:8: using RFC1035 TTL semantics
...
17-Sep-2018 10:11:28.883 received control channel command 'stats'
17-Sep-2018 10:11:28.886 dumpstats complete
```
notify.log
```
17-Sep-2018 10:10:05.845 zone example.de.test/IN/Intranet: sending notifies (serial 2018091705)
17-Sep-2018 10:10:05.900 zone example.de.appr/IN/Intranet: sending notifies (serial 2018091706)
17-Sep-2018 10:10:10.844 zone example.de.test/IN/Intranet: sending notifies (serial 2018091706)
...
17-Sep-2018 10:10:20.833 zone example.org.test/IN/Intranet: sending notifies (serial 2018091706)
17-Sep-2018 10:10:20.874 zone example.de.appr/IN/Intranet: sending notifies (serial 2018091707)
17-Sep-2018 10:10:21.033 zone example.org.appr/IN/Intranet: sending notifies (serial 2018091707)
...
17-Sep-2018 10:10:25.833 zone example.org.test/IN/Intranet: sending notifies (serial 2018091707)
17-Sep-2018 10:10:35.825 zone example.de.test/IN/Intranet: sending notifies (serial 2018091707)
17-Sep-2018 10:10:35.871 zone example.de.appr/IN/Intranet: sending notifies (serial 2018091708)
17-Sep-2018 10:10:36.025 zone example.org.appr/IN/Intranet: sending notifies (serial 2018091708)
...
17-Sep-2018 10:10:36.035 zone example.org.test/IN/Intranet: sending notifies (serial 2018091708)
...
17-Sep-2018 10:10:40.824 zone example.de.test/IN/Intranet: sending notifies (serial 2018091708)
...
```
queries.log
```
17-Sep-2018 10:10:05.868 client @0x7f8fc80a1680 resolv0#52008 (example.de.test): view Intranet: query: example.de.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:05.871 client @0x7f8fc024f440 resolv0#48559 (example.de.test): view Intranet: query: example.de.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:06.346 client @0x7f8fc80a1680 resolv2#38233 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:06.347 client @0x7f8fc80a1680 resolv1#42489 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:06.348 client @0x7f8fc0031b80 resolv2#60837 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:06.349 client @0x7f8fc80b0260 resolv1#33043 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:06.366 client @0x7f8fc80a1680 resolv0#44368 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:06.368 client @0x7f8fc80c5400 resolv0#43809 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:06.847 client @0x7f8fc80a1680 resolv2#55911 (example.de.test): view Intranet: query: example.de.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:06.847 client @0x7f8fc80a1680 resolv1#51169 (example.de.test): view Intranet: query: example.de.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:06.848 client @0x7f8fc8b54970 resolv2#46401 (example.de.test): view Intranet: query: example.de.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:06.849 client @0x7f8fc02a2d10 resolv1#57663 (example.de.test): view Intranet: query: example.de.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:10.847 client @0x7f8fc80a1680 resolv0#48220 (example.de.test): view Intranet: query: example.de.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:10.850 client @0x7f8fc012bb20 resolv0#40879 (example.de.test): view Intranet: query: example.de.test IN IXFR -T (dns-master)
...
17-Sep-2018 10:10:21.345 client @0x7f8fc80a1680 resolv0#38546 (example.org.test): view Intranet: query: example.org.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:21.347 client @0x7f8fc012bb20 resolv0#60875 (example.org.test): view Intranet: query: example.org.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:21.833 client @0x7f8fc80a1680 resolv2#59250 (example.org.test): view Intranet: query: example.org.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:21.834 client @0x7f8fc80a1680 resolv2#59250 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:21.834 client @0x7f8fc80a1680 resolv0#41826 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:21.835 client @0x7f8fc80a1680 resolv1#50104 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:21.836 client @0x7f8fc024f440 resolv2#56189 (example.org.test): view Intranet: query: example.org.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:21.836 client @0x7f8fc80a1680 resolv1#50104 (example.org.test): view Intranet: query: example.org.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:21.837 client @0x7f8fc0031b80 resolv2#48861 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:21.839 client @0x7f8fc02a2d10 resolv0#55647 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:21.842 client @0x7f8fc80c5400 resolv1#36417 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:21.845 client @0x7f8fc8b54970 resolv1#39411 (example.org.test): view Intranet: query: example.org.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:22.333 client @0x7f8fc80a1680 resolv1#47624 (example.org.appr): view Intranet: query: example.org.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:22.334 client @0x7f8fc80a1680 resolv2#34020 (example.org.appr): view Intranet: query: example.org.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:22.334 client @0x7f8fc80a1680 resolv0#33682 (example.org.appr): view Intranet: query: example.org.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:22.335 client @0x7f8fc012bb20 resolv2#46021 (example.org.appr): view Intranet: query: example.org.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:22.336 client @0x7f8fc012caa0 resolv1#52295 (example.org.appr): view Intranet: query: example.org.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:22.337 client @0x7f8fc024f440 resolv0#34597 (example.org.appr): view Intranet: query: example.org.appr IN IXFR -T (dns-master)
...
17-Sep-2018 10:10:35.847 client @0x7f8fc80a1680 resolv0#43807 (example.de.test): view Intranet: query: example.de.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:35.850 client @0x7f8fc012bb20 resolv0#55427 (example.de.test): view Intranet: query: example.de.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:36.326 client @0x7f8fc80a1680 resolv1#43964 (example.de.test): view Intranet: query: example.de.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:36.327 client @0x7f8fc80a1680 resolv2#37612 (example.de.test): view Intranet: query: example.de.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:36.328 client @0x7f8fc012caa0 resolv1#48525 (example.de.test): view Intranet: query: example.de.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:36.328 client @0x7f8fc80c5400 resolv2#47429 (example.de.test): view Intranet: query: example.de.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:36.345 client @0x7f8fc80a1680 resolv0#44838 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:36.346 client @0x7f8fc02a2d10 resolv0#35717 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:36.825 client @0x7f8fc80a1680 resolv0#59509 (example.org.appr): view Intranet: query: example.org.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:36.826 client @0x7f8fc80a1680 resolv1#45594 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:36.827 client @0x7f8fc80a1680 resolv1#45594 (example.org.appr): view Intranet: query: example.org.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:36.827 client @0x7f8fc016fdb0 resolv0#50985 (example.org.appr): view Intranet: query: example.org.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:36.828 client @0x7f8fc80a1680 resolv2#58307 (example.de.appr): view Intranet: query: example.de.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:36.828 client @0x7f8fc8b54970 resolv1#50357 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:36.829 client @0x7f8fc80a1680 resolv2#58307 (example.org.appr): view Intranet: query: example.org.appr IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:36.830 client @0x7f8fc0031b80 resolv1#47617 (example.org.appr): view Intranet: query: example.org.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:36.831 client @0x7f8fc012bb20 resolv2#52591 (example.de.appr): view Intranet: query: example.de.appr IN IXFR -T (dns-master)
17-Sep-2018 10:10:36.831 client @0x7f8fc012caa0 resolv2#48193 (example.org.appr): view Intranet: query: example.org.appr IN IXFR -T (dns-master)
...
17-Sep-2018 10:10:37.826 client @0x7f8fc80a1680 resolv2#60210 (example.org.test): view Intranet: query: example.org.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:37.827 client @0x7f8fc80a1680 resolv1#41721 (example.org.test): view Intranet: query: example.org.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:37.827 client @0x7f8fc80a1680 resolv0#44213 (example.org.test): view Intranet: query: example.org.test IN SOA -E(0) (dns-master)
...
17-Sep-2018 10:10:37.828 client @0x7f8fc01ebdd0 resolv2#32927 (example.org.test): view Intranet: query: example.org.test IN IXFR -T (dns-master)
17-Sep-2018 10:10:37.829 client @0x7f8fc0031b80 resolv1#45227 (example.org.test): view Intranet: query: example.org.test IN IXFR -T (dns-master)
...
17-Sep-2018 10:10:37.832 client @0x7f8fc024f440 resolv0#37261 (example.org.test): view Intranet: query: example.org.test IN IXFR -T (dns-master)
...
17-Sep-2018 10:10:40.826 client @0x7f8fc80a1680 resolv0#43072 (example.de.test): view Intranet: query: example.de.test IN SOA -E(0) (dns-master)
17-Sep-2018 10:10:40.828 client @0x7f8fc016fdb0 resolv0#47343 (example.de.test): view Intranet: query: example.de.test IN IXFR -T (dns-master)
```
xfer-out.log
```
17-Sep-2018 10:10:05.872 client @0x7f8fc024f440 resolv0#48559 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR started (serial 2018091705)
17-Sep-2018 10:10:05.875 client @0x7f8fc024f440 resolv0#48559 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:06.349 client @0x7f8fc0031b80 resolv2#60837 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091706)
17-Sep-2018 10:10:06.350 client @0x7f8fc0031b80 resolv2#60837 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:06.350 client @0x7f8fc80b0260 resolv1#33043 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091706)
17-Sep-2018 10:10:06.351 client @0x7f8fc80b0260 resolv1#33043 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:06.368 client @0x7f8fc80c5400 resolv0#43809 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091706)
17-Sep-2018 10:10:06.369 client @0x7f8fc80c5400 resolv0#43809 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:06.850 client @0x7f8fc8b54970 resolv2#46401 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR started (serial 2018091706)
17-Sep-2018 10:10:06.850 client @0x7f8fc02a2d10 resolv1#57663 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR started (serial 2018091706)
17-Sep-2018 10:10:06.851 client @0x7f8fc8b54970 resolv2#46401 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:06.851 client @0x7f8fc02a2d10 resolv1#57663 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:10.850 client @0x7f8fc012bb20 resolv0#40879 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR started (serial 2018091706)
17-Sep-2018 10:10:10.851 client @0x7f8fc012bb20 resolv0#40879 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR ended
...
17-Sep-2018 10:10:21.348 client @0x7f8fc012bb20 resolv0#60875 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:21.348 client @0x7f8fc012bb20 resolv0#60875 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:21.837 client @0x7f8fc024f440 resolv2#56189 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:21.838 client @0x7f8fc024f440 resolv2#56189 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:21.839 client @0x7f8fc0031b80 resolv2#48861 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:21.840 client @0x7f8fc0031b80 resolv2#48861 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:21.841 client @0x7f8fc02a2d10 resolv0#55647 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:21.846 client @0x7f8fc80c5400 resolv1#36417 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:21.847 client @0x7f8fc8b54970 resolv1#39411 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:21.849 client @0x7f8fc02a2d10 resolv0#55647 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:21.852 client @0x7f8fc80c5400 resolv1#36417 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:21.853 client @0x7f8fc8b54970 resolv1#39411 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:22.336 client @0x7f8fc012bb20 resolv2#46021 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:22.336 client @0x7f8fc012caa0 resolv1#52295 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:22.337 client @0x7f8fc012bb20 resolv2#46021 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:22.337 client @0x7f8fc012caa0 resolv1#52295 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:22.338 client @0x7f8fc024f440 resolv0#34597 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:22.338 client @0x7f8fc024f440 resolv0#34597 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR ended
...
17-Sep-2018 10:10:35.851 client @0x7f8fc012bb20 resolv0#55427 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR started (serial 2018091707)
17-Sep-2018 10:10:35.853 client @0x7f8fc012bb20 resolv0#55427 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:36.329 client @0x7f8fc012caa0 resolv1#48525 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:36.329 client @0x7f8fc80c5400 resolv2#47429 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:36.330 client @0x7f8fc012caa0 resolv1#48525 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:36.330 client @0x7f8fc80c5400 resolv2#47429 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:36.347 client @0x7f8fc02a2d10 resolv0#35717 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:36.347 client @0x7f8fc02a2d10 resolv0#35717 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:36.828 client @0x7f8fc016fdb0 resolv0#50985 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:36.829 client @0x7f8fc016fdb0 resolv0#50985 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:36.829 client @0x7f8fc8b54970 resolv1#50357 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:36.830 client @0x7f8fc8b54970 resolv1#50357 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:36.831 client @0x7f8fc0031b80 resolv1#47617 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:36.832 client @0x7f8fc012bb20 resolv2#52591 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:36.832 client @0x7f8fc012caa0 resolv2#48193 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:36.833 client @0x7f8fc0031b80 resolv1#47617 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:36.833 client @0x7f8fc012bb20 resolv2#52591 (example.de.appr): view Intranet: transfer of 'example.de.appr/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:36.833 client @0x7f8fc012caa0 resolv2#48193 (example.org.appr): view Intranet: transfer of 'example.org.appr/IN': AXFR-style IXFR ended
...
17-Sep-2018 10:10:37.829 client @0x7f8fc01ebdd0 resolv2#32927 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:37.830 client @0x7f8fc01ebdd0 resolv2#32927 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR ended
17-Sep-2018 10:10:37.830 client @0x7f8fc0031b80 resolv1#45227 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:37.831 client @0x7f8fc0031b80 resolv1#45227 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR ended
...
17-Sep-2018 10:10:37.833 client @0x7f8fc024f440 resolv0#37261 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:37.834 client @0x7f8fc024f440 resolv0#37261 (example.org.test): view Intranet: transfer of 'example.org.test/IN': AXFR-style IXFR ended
...
17-Sep-2018 10:10:40.829 client @0x7f8fc016fdb0 resolv0#47343 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR started (serial 2018091708)
17-Sep-2018 10:10:40.829 client @0x7f8fc016fdb0 resolv0#47343 (example.de.test): view Intranet: transfer of 'example.de.test/IN': AXFR-style IXFR ended
```
Please let me know if I can provide you with further information.
### Possible fixes
As mentioned above it seems possible to enable debug logging, however this seems no solution to meMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/543Windows builds failing for master2018-09-26T07:44:04ZCurtis BlackburnWindows builds failing for masterRelease and Debug builds, both 32bit and 64bit, have the same issue
64bit:
```
(Link target) ->
libisc.def : error LNK2001: unresolved external symbol isc_string_strlcat [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2...Release and Debug builds, both 32bit and 64bit, have the same issue
64bit:
```
(Link target) ->
libisc.def : error LNK2001: unresolved external symbol isc_string_strlcat [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
libisc.def : error LNK2001: unresolved external symbol isc_string_strlcpy [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
.\Debug\libisc.lib : fatal error LNK1120: 2 unresolved externals [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
49 Warning(s)
3 Error(s)
```
last successful build was at 3949450fbd03e61edc665d0858acd1943e7a50c0, first failing build was at e860375d4ff1bb995800060524cdcf16067d141dhttps://gitlab.isc.org/isc-projects/bind9/-/issues/544IRS_GETNAMEINFO_BUFLEN_T detection differs depending on architecture2018-11-08T16:50:40ZPetr MenšíkIRS_GETNAMEINFO_BUFLEN_T detection differs depending on architectureIn braches v9_11 and v9_12, IRS_GETNAMEINFO_BUFLEN_T detection in configure generates different result on the same code. This causes multilib issues. It does not allow installation of the headers both for i686 and x86_64 on the same mach...In braches v9_11 and v9_12, IRS_GETNAMEINFO_BUFLEN_T detection in configure generates different result on the same code. This causes multilib issues. It does not allow installation of the headers both for i686 and x86_64 on the same machine for example.
Our issue on Fedora with glibc glibc-2.27 is with getnameinfo signature:
```c
int getnameinfo(const struct sockaddr *addr, socklen_t addrlen,
char *host, socklen_t hostlen,
char *serv, socklen_t servlen, int flags);
```
This signature is not detected directly, but only detected as fallback. This causes the issue, because on 32-bit architectures, socklen_t is compatible with size_t, but on 64-bit architectures it is not. On 32-bit architecture, size_t is detected for IRS_GETNAMEINFO_BUFLEN_T, because it matches first.
```c
int getnameinfo(const struct sockaddr *, socklen_t, char *,
size_t, char *, size_t, int);
```
On 64-bit architecture, it has to use the fallback socklen_t.
Suggested fix is to test socklen_t types with int flags before trying size_t. The [change back from unsigned int](https://marc.info/?l=netbsd-tech-net&m=102208795729161) seems to be pretty old. I am aware this is already fixed in 9.13 and master.https://gitlab.isc.org/isc-projects/bind9/-/issues/545add strlcat and strlcpy libisc.def.in2018-09-20T04:54:20ZMark Andrewsadd strlcat and strlcpy libisc.def.inMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/546mtype should be dns_ssumatchtype_t2018-09-20T06:13:54ZMark Andrewsmtype should be dns_ssumatchtype_tMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/547Initial implementation of modules doesn't support multiple instances2018-11-01T17:37:56ZEvan HuntInitial implementation of modules doesn't support multiple instancesThe following discussion from !632 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/632#note_21178): (+1 comment)
> As for commit 882a62c61877dbbf8d964ca3be8147c700...The following discussion from !632 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/632#note_21178): (+1 comment)
> As for commit 882a62c61877dbbf8d964ca3be8147c700c2d0fa, I am afraid it does not solve another high-level issue that has only occurred to me just now: it is impossible to use two instances of a given hook module in separate views, which kind of renders the concept of per-view hook tables bogus :(
>
> I would consider reverting 882a62c61877dbbf8d964ca3be8147c700c2d0fa and moving to a more complex model that would solve both issues. An example would be:
>
> * track modules currently in use using a server-wide list; each element in that list would be a reference-counted structure representing a single shared object mapped using `dlopen()` (that can be released once its reference count drops to 0),
> * introduce hook instances (hey, remember b7a25260e13fe4b0d0913610c6cd679da1c56552? ;)), i.e. make every `hook` statement present in a configuration grab a reference to the module structure from the previous bullet point and make sure it acts independently from any other `hook` statements,
> * use instance-specific configuration and data tables in modules,
> * keep per-view lists of hook instances currently registered in that view's hook table.
>
> I know this hurts, but I do not think we can defend the current approach in the long run due to its very limited flexibility.
>
> Perhaps we should consider implementing this in a follow-up MR rather than right now. In any case, I think we should address this before making a release with hooks available.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/548Hook module interface can be simplified after dropping support for statically...2018-12-06T18:45:03ZMichał KępieńHook module interface can be simplified after dropping support for statically linking namedThe following discussion from !632 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/632#note_20452): (+5 comments)
> On Linux, if we enforced `--with-libtool` (whic...The following discussion from !632 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/632#note_20452): (+5 comments)
> On Linux, if we enforced `--with-libtool` (which will soon be the case anyway due to Automake), the shared libraries loaded during `named` startup would be used for resolving symbols in modules loaded using `dlopen()` and thus the following would not be needed:
>
> * passing function pointers to `query_done()`, `query_recurse()`, log contexts, etc. through a `struct ns_hookctx`,
> * storing a function pointer to `ns_hooktable_free()` in `struct dns_view`,
> * the `struct cfg_rep` change from 822dc8be48ef4ad1a43d44242150438e602eeafb.
>
> We could even go a step further and drop the use of `${LIBS}` for building modules.
>
> Are there platforms on which shared objects loaded using `dlopen()` are unable to look up symbols in other shared objects mapped into the same address space before them?https://gitlab.isc.org/isc-projects/bind9/-/issues/549Query timeout from time to time2018-09-25T02:33:11Znanwn147929@alibaba-inc.comQuery timeout from time to time<!--
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
Under the pressure of about 7000 QPS, query named timeout from time to time.
### Steps to reproduce
Normal use, with recursion yes.
### What is the current *bug* behavior?
Query timeout and error log detected.
### What is the expected *correct* behavior?
Query not timeout.
### 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
```
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error:
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error:
21-Sep-2018 17:10:08.465 client: client @0x13c44bf0 10.31.238.187#33201 (dogadventuresnw.com): error sending response: invalid file
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error:
21-Sep-2018 17:10:08.465 client: client @0x7f2ed8380110 192.168.59.44#46221 (175.200.159.115.in-addr.arpa): error sending response: invalid file
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error:
21-Sep-2018 17:10:08.465 client: client @0x7f2f7a164550 10.31.238.187#43355 (tryxrock.com): error sending response: invalid file
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error:
21-Sep-2018 17:10:08.465 client: client @0x7f2ad1450180 10.172.222.35#54629 (78.152.202.220.in-addr.arpa): error sending response: invalid file
21-Sep-2018 17:10:08.465 client: client @0x65af7a0 10.29.179.104#45331 (api.shodan.io): error sending response: invalid file
21-Sep-2018 17:10:08.465 client: client @0x7f2d1148f5d0 10.31.238.187#35671 (yourdigitalasset.com): error sending response: invalid file
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error:
21-Sep-2018 17:10:08.465 client: client @0x7f2c0ad6eb40 10.31.238.187#33462 (koiponddrumfilter.com): error sending response: invalid file
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error:
21-Sep-2018 17:10:08.465 client: client @0x3822cd30 10.31.238.187#37933 (briglina.ch): error sending response: invalid file
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error:
21-Sep-2018 17:10:08.465 client: client @0x7f2df17a5080 10.31.238.187#48161 (tryxrock.com): error sending response: invalid file
21-Sep-2018 17:10:08.465 general: socket.c:2128: unexpected error
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/551[ISC-support #13429] Improve named's ability to run suid and/or with setcap2021-02-03T23:48:10ZCathy Almond[ISC-support #13429] Improve named's ability to run suid and/or with setcap### Description
named's behaviour when started suid (as opposed to launched by a user with root privileges) can't be relied upon to work consistently. It may work when named is single-threaded, but fail to open the server sockets if na...### Description
named's behaviour when started suid (as opposed to launched by a user with root privileges) can't be relied upon to work consistently. It may work when named is single-threaded, but fail to open the server sockets if named is running multi-threaded.
### Request
There have been several threads on this topic over the years. named was not coded to take into account all the variants of privileges and capabilities, and adding in the different implementations for multithreaded support and the need to manage privs across multiple threads/processes has made it difficult to control BIND from secure appliances or utilities such as systemd.
Please could we consider the above problems (and see the links/references below for further material) when we next visit how named handles capabilities and privilege dropping code.
If not all of the 'expected' variants on uid/privs will work, then a document explaining what will and won't work, and precisely why, would be much appreciated, to complement any best practices advice that we also offer.
### Links / references
References:
https://gitlab.isc.org/isc-projects/bind9/issues/321
https://lists.isc.org/pipermail/bind-users/2015-September/095758.html
https://lists.isc.org/pipermail/bind-users/2018-January/099437.html
https://support.isc.org/Ticket/Display.html?id=11942
https://support.isc.org/Ticket/Display.html?id=11470BIND 9.17 BackburnerOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/552Query logging format and making less-disruptive changes2019-11-01T10:15:18ZCathy AlmondQuery logging format and making less-disruptive changesThis is a follow-up on https://bugs.isc.org/Ticket/Display.html?id=44606
The following change in BIND 9.11.0 caused many people's querylog parsing scripts to break, moreso because the new logging wasn't added at the end of the layout (a...This is a follow-up on https://bugs.isc.org/Ticket/Display.html?id=44606
The following change in BIND 9.11.0 caused many people's querylog parsing scripts to break, moreso because the new logging wasn't added at the end of the layout (although it may anyway have broken some parsers):
> 4471. [cleanup] Render client/query logging format consistent for
> ease of log file parsing. (Note that this affects
> "querylog" format: there is now an additional field
> indicating the client object address.) [RT #43238]
A new question has been asked - what are we going to do next, and, having already added it (and forced many people to change their scripts aready) will we change the position of the client @0xptr tag, or leave it where it is, going forwards?
https://groups.google.com/forum/#!topic/comp.protocols.dns.bind/6p8SwGEiC2M
I think we should not move it - what's done is done, and too many people have now upgraded to BIND 9.11 and updated their logfile parsing scripts. Can we confirm our plans please.https://gitlab.isc.org/isc-projects/bind9/-/issues/553socket.c:2171: unexpected error2019-03-22T12:15:53ZGhost Usersocket.c:2171: unexpected errorDescription of problem:
Getting stuff like this in logs since the upgrade to 9.11.4-P2 from 9.11.2:
```
24-Sep-2018 00:32:13.012 general: error: socket.c:2171: unexpected error:
24-Sep-2018 00:32:13.013 general: error: internal_send: <...Description of problem:
Getting stuff like this in logs since the upgrade to 9.11.4-P2 from 9.11.2:
```
24-Sep-2018 00:32:13.012 general: error: socket.c:2171: unexpected error:
24-Sep-2018 00:32:13.013 general: error: internal_send: <client_ip>#49478: Invalid argument
```
I cannot reproduce the bug by a client request, but others can, as reported from another user:
https://bugzilla.redhat.com/show_bug.cgi?id=1571059
I git bisected the problem to first bad commit:
[5e375f8b5249320509609ebda71504c99397e2eb] Use completely static-sized buffers
Trial and error lead to this patch which solved the problem for me:
[socket.c.diff](/uploads/beb4d7e45f55068bd2575ad0c0de8b3b/socket.c.diff)
No more unexpected error log entries
Im running SunOS 5.11.3 on x86-64Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/554RFC 7901 CHAIN Query Requests in DNS2018-09-24T15:42:30ZVicky Riskvicky@isc.orgRFC 7901 CHAIN Query Requests in DNS### Description
APNIC would like to see us support RFC 7901. Specifically, the desired application is for using DANE for pinning the CA certificate.
### Request
Implement RFC 7901 in BIND, for TCP or UDP connections with valid cookies...### Description
APNIC would like to see us support RFC 7901. Specifically, the desired application is for using DANE for pinning the CA certificate.
### Request
Implement RFC 7901 in BIND, for TCP or UDP connections with valid cookies only. Note that this is experimental, although it is an RFC.
### Links / references
https://tools.ietf.org/html/rfc7901https://gitlab.isc.org/isc-projects/bind9/-/issues/555IDN support in host cannot be disabled2018-10-24T19:40:27ZPetr MenšíkIDN support in host cannot be disabled<!--
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
IDN support in host cannot be disabled by parameter or environment.
### Steps to reproduce
- build bind --with-libidn2
- man host, search for IDN.
- IDN_DISABLE=1 host háčkyčárky.cz
### What is the current *bug* behavior?
IDN is not disabled, name is decoded and result is decoded as well.
### What is the expected *correct* behavior?
IDN library is not used and name is passed to resolver as it was passed to command line.
### Possible fixes
Proposed in merge request !800https://gitlab.isc.org/isc-projects/bind9/-/issues/556Race condition in timer creation2018-09-27T19:59:31ZOndřej SurýRace condition in timer creationOriginally reported here: https://github.com/isc-projects/bind9/pull/2
```
A crash happened with the following call trace:
(gdb) thread 4
[Switching to thread 4 (LWP 1827)]
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lo...Originally reported here: https://github.com/isc-projects/bind9/pull/2
```
A crash happened with the following call trace:
(gdb) thread 4
[Switching to thread 4 (LWP 1827)]
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:371
371 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
(gdb) bt
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:371
#1 0x00007f792dfe61f4 in __pthread_mutex_unlock_usercnt (mutex=mutex@entry=0x7f792f045028, decr=decr@entry=1) at pthread_mutex_unlock.c:55
#2 0x00007f792dfe62aa in __GI___pthread_mutex_unlock (mutex=mutex@entry=0x7f792f045028) at pthread_mutex_unlock.c:324
#3 0x00007f792e234f3e in isc__timer_create (manager0=0x7f792f045010, type=, expires=, interval=, task=,
action=, arg=0x55a04c063a50, timerp=0x55a04c063a88) at ../../../bind-9.10.3-P3/lib/isc/timer.c:485
#4 0x000055a04ac16610 in add_timeout (when=0x7ffea6082f90, where=0x7ffea6082fa0, what=0x0, ref=0xffffffff, unref=0x7f792f045028) at ../../dhcp-4.3.4/common/dispatch.c:354
#5 0x000055a04ac01cf1 in send_discover (cpp=0x55a04c063db0) at ../../dhcp-4.3.4/client/dhclient.c:2315
#6 0x000055a04abf8ac8 in main (argc=, argv=) at ../../dhcp-4.3.4/client/dhclient.c:795
(gdb) thread 1
[Switching to thread 1 (LWP 1828)]
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1 0x00007f792dc713fa in __GI_abort () at abort.c:89
#2 0x00007f792e20c7af in isc_assertion_failed (file=file@entry=0x7f792e252b60 "../../../bind-9.10.3-P3/lib/isc/timer.c", line=line@entry=1163,
type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7f792e2531f0 "timerp != ((void *)0) && ((*timerp) != ((void *)0) && (*timerp)->magic == (('A') << 24 | ('t') << 16 | ('m') << 8 | ('r')))")
at ../../../bind-9.10.3-P3/lib/isc/assertions.c:59
#3 0x00007f792e2358c1 in isc_timer_detach (timerp=timerp@entry=0x55a04c063a88) at ../../../bind-9.10.3-P3/lib/isc/timer.c:1163
#4 0x000055a04ac1625b in isclib_timer_callback (taskp=, eventp=0x7f792f04e130) at ../../dhcp-4.3.4/common/dispatch.c:179
#5 0x00007f792e22f64c in dispatch (manager=0x7f792f042010) at ../../../bind-9.10.3-P3/lib/isc/task.c:1130
#6 run (uap=0x7f792f042010) at ../../../bind-9.10.3-P3/lib/isc/task.c:1302
#7 0x00007f792dfe2464 in start_thread (arg=0x7f792d1d3700) at pthread_create.c:456
#8 0x00007f792dd24cef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
(gdb) print *(struct isc_timer **) 0x55a04c063a88
$15 = (struct isc_timer *) 0x0
```
The race condition is the timer elapses before isc__timer_create() returns the pointer to the caller.
Assigning the return pointer before enabling the timer will fix it.BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/557Bind 9 update in CentOS (/var/named ownership problem)2018-09-26T09:24:34ZGhost UserBind 9 update in CentOS (/var/named ownership problem)Hello everyone,
There is a problem when updating the bind-9 package in CentOS Linux, specially grandstanding when the Master/Slave replication is setup(leads to out of sync).
After updating the package, the owner of the folder "/var/name...Hello everyone,
There is a problem when updating the bind-9 package in CentOS Linux, specially grandstanding when the Master/Slave replication is setup(leads to out of sync).
After updating the package, the owner of the folder "/var/named' changed to the "root" account, while the owner of service process(named) is "named" account; So we must change the owner of this folder to "named" account MANUALLY.
I think this can be handled when the installation package is build.
Best Hopes
Khodadad Nejadkoorkihttps://gitlab.isc.org/isc-projects/bind9/-/issues/558nsupdate leaks memory when using GSS-TSIG and receiving SIGTERM at a "right" ...2018-11-14T19:39:10ZTomas Hozzansupdate leaks memory when using GSS-TSIG and receiving SIGTERM at a "right" time### Summary
I'm reporting https://bugs.isc.org/SelfService/Display.html?id=46044 here, because it seems that bugs.isc.org is not getting any attention.
While running tests for sssd project, which runs nsupdate on the background, we...### Summary
I'm reporting https://bugs.isc.org/SelfService/Display.html?id=46044 here, because it seems that bugs.isc.org is not getting any attention.
While running tests for sssd project, which runs nsupdate on the background, we discovered a bug in nsupdate itself. During the test, sssd runs nsupdate with GSSAPI as a child process. However sssd fails to perform some operation and sends SIGTERM to all of its child processes, including nsupdate.
The problem is, that if nsupdate receives SIGTERM exactly after returning from recvgss() function, but before receiving a response from the server, it terminates the event loop and eventually ends up in cleanup() function, which however does not clean up "tmpzonename" and "restart_master" variables, allocated in recvsoa(). These are freed only in update_completed(). When the memory context is destroyed in cleanup(), nsupdate crashes, because these two variables were never freed.
### Steps to reproduce
I created a reproducer using gdb, which sends SIGTERM to nsupdate right before exiting recvgss() function. nsupdate then crashes on different places, because of a race conditions when shutting down the application. Sometimes it is because the memory was not freed, sometimes it is because some structures are tried to be freed twice.
The reproducer requires GDB > 7.5, a DNS server with allowed zone updates and using GSSAPI with nsupdate (and having all the prerequisites like krb ticket and so on...).
```
[root@vm-058-217 ~]# cat nsupdate.cmd
update add bumblebee10.test.example.com. 3600 IN A 192.168.1.1
send
[root@vm-058-217 ~]# cat nsupdate_reproducer.gdb
# set breakpoint at the end of recvsoa() function
break ddebug if $_streq(format, "Out of recvgss")
handle SIGTERM nostop
# run nsupdate
run -g nsupdate.cmd
# send a SIGTERM to nsupdate, causing it do end immediately
# we have to do it from shell, because gdb is too slow with sending the signal
shell kill -s SIGTERM $(pidof nsupdate) && sleep 1 && exit
continue
```
The reproducer does not work 100%, but it makes nsupdate crash with some error most of the time. I successfully reproduced the issue with bind 9.11.1 and seeing changes in git, it does not seem to be fixed yet. (this was relevant at the end of 2017)
### What is the current *bug* behavior?
nsupdate sometimes crashes while processing SIGTERM signal.
### What is the expected *correct* behavior?
should exit correctly
### Relevant configuration files
n/a
### Relevant logs and/or screenshots
crash #1 (on Fedora 26 with bind 9.11.1)
-------------------------------------------------------------------
```
[root@qeos-186 ~]# gdb --command=nsupdate_reproducer.gdb nsupdate
GNU gdb (GDB) Fedora 8.0-24.fc26
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from nsupdate...Reading symbols from /usr/lib/debug/usr/bin/nsupdate.debug...done.
done.
Breakpoint 1 at 0x4ee0: file ./nsupdate.c, line 366.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff4142700 (LWP 16820)]
[New Thread 0x7ffff3941700 (LWP 16821)]
[New Thread 0x7ffff3140700 (LWP 16822)]
[Switching to Thread 0x7ffff3140700 (LWP 16822)]
Thread 4 "nsupdate" hit Breakpoint 1, ddebug (format=0x555555560164 "Out of recvgss") at ./nsupdate.c:366
366 ddebug(const char *format, ...) {
Thread 1 "nsupdate" received signal SIGTERM, Terminated.
[Thread 0x7ffff3140700 (LWP 16822) exited]
[Thread 0x7ffff4142700 (LWP 16820) exited]
[Thread 0x7ffff3941700 (LWP 16821) exited]
Failing assertion due to probable leaked memory in context 0x555555764030 ("") (stats[18].gets == 1).
mem.c:1072: INSIST(ctx->stats[i].gets == 0U) failed, back trace
#0 0x7ffff70fdd27 in ??
#1 0x7ffff70fdc7a in ??
#2 0x7ffff7110f5c in ??
#3 0x7ffff71111e5 in ??
#4 0x7ffff7114e55 in ??
#5 0x555555558b70 in ??
#6 0x7ffff4c2a50a in ??
#7 0x555555558d4a in ??
Thread 1 "nsupdate" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff7fe0800 (LWP 16816)]
0x00007ffff4c4069b in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install GeoIP-1.6.11-1.fc26.x86_64 glibc-2.25-10.fc26.x86_64 gssproxy-0.7.0-9.fc26.x86_64 keyutils-libs-1.5.10-1.fc26.x86_64 krb5-libs-1.15.1-28.fc26.x86_64 libcap-2.25-5.fc26.x86_64 libcom_err-1.43.4-2.fc26.x86_64 libgcc-7.1.1-3.fc26.x86_64 libselinux-2.6-7.fc26.x86_64 libxml2-2.9.4-2.fc26.x86_64 openssl-libs-1.1.0f-7.fc26.x86_64 pcre-8.41-1.fc26.x86_64 xz-libs-5.2.3-2.fc26.x86_64 zlib-1.2.11-2.fc26.x86_64
(gdb) bt
#0 0x00007ffff4c4069b in raise () from /lib64/libc.so.6
#1 0x00007ffff4c424a0 in abort () from /lib64/libc.so.6
#2 0x00007ffff70fdc7f in isc_assertion_failed (file=file@entry=0x7ffff7149708 "mem.c", line=line@entry=1072, type=type@entry=isc_assertiontype_insist,
cond=cond@entry=0x7ffff71497ed "ctx->stats[i].gets == 0U") at assertions.c:50
#3 0x00007ffff7110f5c in destroy (ctx=ctx@entry=0x555555764030) at mem.c:1072
#4 0x00007ffff71111e5 in isc__mem_destroy (ctxp=0x555555763a68 <gmctx>) at mem.c:1225
#5 0x00007ffff7114e55 in isc_mem_destroy (mctxp=0x555555763a68 <gmctx>) at mem.c:2752
#6 0x0000555555558b70 in cleanup () at ./nsupdate.c:3200
#7 main (argc=3, argv=0x7fffffffe318) at ./nsupdate.c:3252
```
crash #2 (on RHEL-7 with bind 9.9.4)
-------------------------------------------------------------
```
[root@vm-058-217 ~]# gdb --command=nsupdate_reproducer.gdb nsupdate
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-103.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/nsupdate...Reading symbols from /usr/lib/debug/usr/bin/nsupdate.debug...done.
done.
Breakpoint 1 at 0x404f20: file ./nsupdate.c, line 344.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff3e08700 (LWP 23095)]
[New Thread 0x7ffff3607700 (LWP 23096)]
[New Thread 0x7ffff2e06700 (LWP 23097)]
[Switching to Thread 0x7ffff2e06700 (LWP 23097)]
Breakpoint 1, ddebug (format=format@entry=0x40bb12 "Out of recvgss") at ./nsupdate.c:344
344 ddebug(const char *format, ...) {
Program received signal SIGTERM, Terminated.
request.c:249: REQUIRE((((requestmgr) != ((void *)0)) && (((const isc__magic_t *)(requestmgr))->magic == ((('R') << 24 | ('q') << 16 | ('u') << 8 | ('M')))))) failed, back trace
#0 0x7ffff6f61287 in ??
#1 0x7ffff6f611da in ??
#2 0x7ffff78ec097 in ??
#3 0x408a1b in ??
#4 0x408e95 in ??
#5 0x7ffff6f840c6 in ??
#6 0x7ffff5d67dc5 in ??
#7 0x7ffff4de07ad in ??
Program received signal SIGABRT, Aborted.
0x00007ffff4d1e1d7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-161.el7.x86_64 gssproxy-0.7.0-5.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-10.el7.x86_64 libattr-2.4.46-12.el7.x86_64 libcap-2.22-8.el7.x86_64 libcom_err-1.42.9-9.el7.x86_64 libgcc-4.8.5-11.el7.x86_64 libselinux-2.5-8.el7.x86_64 openssl-libs-1.0.2k-1.el7.x86_64 pcre-8.32-17.el7.x86_64 xz-libs-5.2.2-1.el7.x86_64
(gdb) bt
#0 0x00007ffff4d1e1d7 in raise () from /lib64/libc.so.6
#1 0x00007ffff4d1f8c8 in abort () from /lib64/libc.so.6
#2 0x00007ffff6f611df in isc_assertion_failed (file=file@entry=0x7ffff7988ac6 "request.c", line=line@entry=249, type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7ffff79890d0 "(((requestmgr) != ((void *)0)) && (((const isc__magic_t *)(requestmgr))->magic == ((('R') << 24 | ('q') << 16 | ('u') << 8 | ('M')))))")
at assertions.c:58
#3 0x00007ffff78ec097 in dns_requestmgr_shutdown (requestmgr=0x0) at request.c:249
#4 0x0000000000408a1b in maybeshutdown () at ./nsupdate.c:761
#5 0x0000000000408e95 in getinput (task=<optimized out>, event=<optimized out>) at ./nsupdate.c:2929
#6 0x00007ffff6f840c6 in dispatch (manager=0x7ffff7fb1010) at task.c:1116
#7 run (uap=0x7ffff7fb1010) at task.c:1286
#8 0x00007ffff5d67dc5 in start_thread () from /lib64/libpthread.so.0
#9 0x00007ffff4de07ad in clone () from /lib64/libc.so.6
```
crash #3 (on RHEL-7 with bind 9.9.4)
-----------------------------------------------------------------------
```
[root@vm-058-217 ~]# gdb --command=nsupdate_reproducer.gdb nsupdate
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-103.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/nsupdate...Reading symbols from /usr/lib/debug/usr/bin/nsupdate.debug...done.
done.
Breakpoint 1 at 0x404f20: file ./nsupdate.c, line 344.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff3e08700 (LWP 22986)]
[New Thread 0x7ffff3607700 (LWP 22987)]
[New Thread 0x7ffff2e06700 (LWP 22988)]
[Switching to Thread 0x7ffff2e06700 (LWP 22988)]
Breakpoint 1, ddebug (format=format@entry=0x40bb12 "Out of recvgss") at ./nsupdate.c:344
344 ddebug(const char *format, ...) {
Program received signal SIGTERM, Terminated.
tsig.c:2016: REQUIRE(*ringp != ((void *)0)) failed, back trace
#0 0x7ffff6f61287 in ??
#1 0x7ffff6f611da in ??
#2 0x7ffff79163a9 in ??
#3 0x404aac in ??
#4 0x7ffff4d0ab35 in ??
#5 0x404da3 in ??
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff7fe3840 (LWP 22982)]
0x00007ffff4d1e1d7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-161.el7.x86_64 gssproxy-0.7.0-5.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-10.el7.x86_64 libattr-2.4.46-12.el7.x86_64 libcap-2.22-8.el7.x86_64 libcom_err-1.42.9-9.el7.x86_64 libgcc-4.8.5-11.el7.x86_64 libselinux-2.5-8.el7.x86_64 openssl-libs-1.0.2k-1.el7.x86_64 pcre-8.32-17.el7.x86_64 xz-libs-5.2.2-1.el7.x86_64
(gdb) bt
#0 0x00007ffff4d1e1d7 in raise () from /lib64/libc.so.6
#1 0x00007ffff4d1f8c8 in abort () from /lib64/libc.so.6
#2 0x00007ffff6f611df in isc_assertion_failed (file=file@entry=0x7ffff79906b0 "tsig.c", line=line@entry=2016, type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7ffff79908da "*ringp != ((void *)0)") at assertions.c:58
#3 0x00007ffff79163a9 in dns_tsigkeyring_detach (ringp=ringp@entry=0x60ed80 <gssring>) at tsig.c:2016
#4 0x0000000000404aac in cleanup () at ./nsupdate.c:2880
#5 main (argc=3, argv=0x7fffffffe3a8) at ./nsupdate.c:2971
```
### Possible fixes
While the memory leak, which caused the crash in this case, can be fixed easily, I was able to reproduce other crashes because of the same race condition at the shutdown. Thus a "complete" fix is not trivial due to the complexity of the shutdown sequence in nsupdate.
WIP fix is attached to Red Hat bug https://bugzilla.redhat.com/show_bug.cgi?id=1300636, but it probably won't fit the git master HEAD...Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/559Add support for ESNI (Encrypted Server Name Indication for TLS 1.3)2019-08-19T14:12:13ZleonAdd support for ESNI (Encrypted Server Name Indication for TLS 1.3)RFC not yet ratified, still want to request support for it:
https://tools.ietf.org/html/draft-rescorla-tls-esni-00#section-4 (see Section 4)RFC not yet ratified, still want to request support for it:
https://tools.ietf.org/html/draft-rescorla-tls-esni-00#section-4 (see Section 4)https://gitlab.isc.org/isc-projects/bind9/-/issues/560dnssec-keymgr doesn't work correctly with "."2019-01-24T20:51:06ZEvan Huntdnssec-keymgr doesn't work correctly with "."When you run `dnssec-keymgr` with a given zone name the first time, it generates a KSK/ZSK set for that zone. Run it again for the same zone name, it should detect the existing keys and apply the key management policy to them, which in m...When you run `dnssec-keymgr` with a given zone name the first time, it generates a KSK/ZSK set for that zone. Run it again for the same zone name, it should detect the existing keys and apply the key management policy to them, which in most cases means it won't do anything at all.
However, when you run `dnssec-keymgr .` multiple times, it generates a new keys for the root zone every single time. I haven't had time to figure out why it's doing this, but it's wrong.
(I'm not really expecting them to start using `dnssec-keymgr` to maintain the root keys, so it isn't the most urgent problem, but we should look into it anyway.)https://gitlab.isc.org/isc-projects/bind9/-/issues/562Chaosnet A records comparison bug2018-09-28T07:50:22ZGhost UserChaosnet A records comparison bug<!--
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
This is a bug in code I helped write in 2005, which got some finishing touches by marka@isc.org. It adds support for Chaosnet A records. It was filed as ISC-Bugs #14695 at the time. With the recently increased interest in Chaosnet, e.g for emulated systems, the code is used more than ever before and I would appreciate if the bug was fixed - I include a suggested patch towards the end. If you are not familiar with the format or how to make a working Chaosnet zone config, see the included sketches, have a look at https://its.victor.se/wiki/chaos-dns, or email me.
The bug:
1. When a CH-class zone file specifies more than one CH-class A record for a host (e.g. a router), in the same address domain written in the same case, only the last one is used.
2. If the first two bytes of the address domains are in different case, both are used, even if they have the same numeric address part and thus represent the same address.
### Steps to reproduce
Create a CH-class zone file (see above) with a single host, with two A records, e.g.
```
bar.foo. A CH-ADDR.NET. 4242
A CH-ADDR.NET. 4711
```
Load the zone and examine the A record of foo with e.g.
```
host -t ch -t a bar.foo.
```
Observe that only one A record is listed.
Now change the zone file so the second A record is
```
A ch-ADDR.NET. 4711
```
Reload the zone, and examine the A record again. Note that both records are listed.
Further, change the second A record to
```
A CH-addr.NET. 4711
```
reload, observe that again only one record is listed.
Now, change the second A record to
```
A ch-ADDR.NET. 4242
```
reload, and observe two A records with the same meaning - one in the domain CH-ADDR.NET and one in ch-ADDR.NET.
### What is the current *bug* behavior?
See above. The result is that as a workaround, Chaosnet zone files must use different case for (the first two bytes of the) address domains for hosts with multiple addresses, such as routers. Duplicated A records are not filtered when they represent the same address.
### What is the expected *correct* behavior?
Regardless of the case, A records representing different addresses should be kept, while A records representing the same address should be filtered (only one copy should be kept).
### Relevant configuration files
named.conf snippet (note you need to create a view for IN class data too, see https://its.victor.se/wiki/chaos-dns):
```
view "chaos" CH {
zone "foo" ch {
type master;
file "foo.zone";
};
};
```
file foo.zone
```
$ORIGIN foo.
$TTL 3600
; whatever works in your case
@ SOA isc.org. bugs.isc.org. (
2018092701 10800 3600 604800 3600)
NS isc.org.
; comment out lines as appropriate for testing
Bar A CH-ADDR.NET. 3412
A ch-ADDR.NET. 3412
A CH-ADDR.NET. 3413
```
### Relevant logs and/or screenshots
### Possible fixes
The bug is in lib/dns/rdata/ch_3/a_1.c line 177 (in the current version), see https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/dns/rdata/ch_3/a_1.c#L177.
The function `compare_ch_a` which compares two chaosnet A records is wrong, comparing the wrong parts of the data, resulting in the behaviour explained above.
The fix:
Change
```
order = memcmp(rdata1->data, rdata2->data, 2);
```
which compares the first two bytes of the address domains, to
```
order = memcmp(region1.base, region2.base, 2);
```
which compares the "next" two bytes of the record data (indexes were updated around line 171 using isc_region_consume). (If you want to be ultra-defensive, check the regionX.length, but I guess the rdata has already been validated.)
The bug is probably caused by cut-and-paste + reordering from generic/mx_15.c.https://gitlab.isc.org/isc-projects/bind9/-/issues/563Look to see if we can detect referral loops without impacting on valid referr...2021-10-04T13:17:39ZMark AndrewsLook to see if we can detect referral loops without impacting on valid referral chains.Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/564Mirror zone configuration tweaks and cleanups2018-10-24T18:51:39ZMichał KępieńMirror zone configuration tweaks and cleanupsVarious discussions around mirror zones which happened after they were initially implemented (see #342, #375/!475, [Twitter poll](https://twitter.com/ISCdotORG/status/1007711763121356800)) indicate that certain aspects of mirror zone con...Various discussions around mirror zones which happened after they were initially implemented (see #342, #375/!475, [Twitter poll](https://twitter.com/ISCdotORG/status/1007711763121356800)) indicate that certain aspects of mirror zone configuration could use some tweaks:
* `type secondary; mirror yes;` should be replaced with `type mirror;`
* it should be clearly documented that:
* mirror zones are supposed to *replace* the configuration example provided by [RFC 7706](https://tools.ietf.org/html/rfc7706#appendix-B.1) rather than *augment* it,
* mirror zones only work the intended way if recursion is available in the view they are configured in,
* by default, outgoing transfers of mirror zones are disabled.
Furthermore:
* the list of valid mirror zone options should be trimmed down,
* NOTIFY configuration for mirror zones is a bit too hacky and could use some love,
* we currently do not test whether mirror zones can be added and removed dynamically (using `rndc`).
The above concerns need to be addressed before we release BIND 9.14 and since configuration changes are involved, BIND 9.13.4 would be the more appropriate target.BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/565Regular ARM builds on gitlab2022-05-11T12:45:44ZVicky Riskvicky@isc.orgRegular ARM builds on gitlab### Description
We publish the ARM with each release. In between releases, we update the ARM in Gitlab, but it isn't easy for a non-developer to browse the updates. I don't know if the docs are built with the CI job in Gitlab, but if th...### Description
We publish the ARM with each release. In between releases, we update the ARM in Gitlab, but it isn't easy for a non-developer to browse the updates. I don't know if the docs are built with the CI job in Gitlab, but if they are, or could be, can we expose the latest build somehow?
### Request
Since we are continually re-building BIND anyway for CI, if it is not too much work, I would like to be able to have a link (e.g. on the home page of the gitlab wiki) for the **current** development documentation (e.g. for 9.11.next, for 9.13.next). This enables people to see what changes are coming.
### Links / referencesMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/566mem.c - fprintf Compiler Warning2018-10-03T21:08:20ZThomas Jachmem.c - fprintf Compiler WarningCommit 93e8ba1b502dbb7ae41fb5a22c09bcec06786d25 causes the following compiler warning on Windows (x86/x64):
lib\isc\mem.c(2238): warning C4477: 'fprintf' : format string '%d' requires an argument of type 'int', but variadic argument 3 h...Commit 93e8ba1b502dbb7ae41fb5a22c09bcec06786d25 causes the following compiler warning on Windows (x86/x64):
lib\isc\mem.c(2238): warning C4477: 'fprintf' : format string '%d' requires an argument of type 'int', but variadic argument 3 has type 'LONGLONG'
Replacing
```PRIdFAST32```
with
```PRIu64```
in lib\isc\mem.c (lines 2238 and 2330) resolves it.https://gitlab.isc.org/isc-projects/bind9/-/issues/567building with nativepkcs11 and without dlopen results in a linker failure2021-09-15T16:15:06ZCurtis Blackburnbuilding with nativepkcs11 and without dlopen results in a linker failure```
./configure --with-pkcs11=/usr/include/softhsm/ --enable-native-pkcs11=yes --with-dlopen=no --enable-developer
```
I think this should result in a configure error, and I am not sure about the interactions of dlopen with everything el...```
./configure --with-pkcs11=/usr/include/softhsm/ --enable-native-pkcs11=yes --with-dlopen=no --enable-developer
```
I think this should result in a configure error, and I am not sure about the interactions of dlopen with everything else.
the error reported after make is ran is:
```
/usr/bin/ld: ../../isc/libisc.a(pk11_api.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
```https://gitlab.isc.org/isc-projects/bind9/-/issues/568the chain system test is missing a delegation.2018-10-04T02:45:01ZMark Andrewsthe chain system test is missing a delegation.https://gitlab.isc.org/isc-projects/bind9/-/issues/569zero system test failed to set ret=0 and send output to /dev/null2018-10-03T05:36:57ZMark Andrewszero system test failed to set ret=0 and send output to /dev/nullMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/570Extend dnstap option to support update messages2018-10-03T16:32:38ZGreg RabilExtend dnstap option to support update messages### Description
The 'dnstap' option currently supports messages for client, resolver, auth, forwarder, and all. It is desirable to also capture dynamic DNS update messages via dnstap output. Although update messages are technically a ...### Description
The 'dnstap' option currently supports messages for client, resolver, auth, forwarder, and all. It is desirable to also capture dynamic DNS update messages via dnstap output. Although update messages are technically a sub-type of query messages via the opcode, it is preferable to categorize them as their own type with respect to the dnstap output. This would allow a dnstap option configuration grammar of:
`dnstap { ( all | auth | client | forwarder | resolver | update ) [ ( query | response ) ]; ... };`
### Request
See the attached 'git diff' for the modifications to the BIND v9_11 branch to support this extension to the dnstap option.
### Links / references
[extend-dnstap-option-to-support-update-messages.txt](/uploads/c15fc719011932f0e5707e79a56e97ef/extend-dnstap-option-to-support-update-messages.txt)https://gitlab.isc.org/isc-projects/bind9/-/issues/571Use PRIuFAST32 instead of PRIdFAST322018-10-03T04:37:25ZMark AndrewsUse PRIuFAST32 instead of PRIdFAST32https://gitlab.isc.org/isc-projects/bind9/-/issues/572Improve accuracy of query error logging2018-10-08T11:01:44ZMichał KępieńImprove accuracy of query error loggingThere are two issues related to query error logging that bug me:
1. Until BIND 9.11 (inclusive), when something goes wrong while recursing for an answer to a query, [the `default:` branch of a `switch` statement in `query_gotanswer()`]...There are two issues related to query error logging that bug me:
1. Until BIND 9.11 (inclusive), when something goes wrong while recursing for an answer to a query, [the `default:` branch of a `switch` statement in `query_gotanswer()`][1] generates a SERVFAIL response. When serve-stale was implemented in BIND 9.12, it was done in a way which causes that `default:` branch to only [set a flag (`want_stale`) in the query context][2] for such queries, effectively moving the `QUERY_ERROR()` call for such queries [to `query_done()`][3] (and making `query_done()` call itself recursively, which hinders readability). This may be a source of confusion[^1] as the "query failed" log messages now point at a line in `query_done()` which appears to have something to do with serve-stale (`if (qctx->want_stale)`) even if the latter is not enabled.
2. Apparently we are setting `qctx->result` to `DNS_R_SERVFAIL` for a lot of different failure modes:
```sh
$ sed -n 's|.*\(QUERY_ERROR([^)]*);\)$|\1|p;' lib/ns/query.c | sort | uniq -c | sort
2 QUERY_ERROR(qctx, DNS_R_DROP);
2 QUERY_ERROR(qctx, DNS_R_REFUSED);
4 QUERY_ERROR(qctx, result);
19 QUERY_ERROR(qctx, DNS_R_SERVFAIL);
```
In some situations, this really is the only sensible thing to do (e.g. when the root key sentinel mechanism overrides the RCODE or when the SERVFAIL cache is hit) but in most others, doing this feels like replacing potentially useful diagnostic information with a rather less useful "oops, something went wrong" type of message:
```
client @0x7fa62c0403b0 ::1#52563 (servfail.nl): query failed (SERVFAIL) for servfail.nl/IN/A at query.c:10681
```
While in some cases the root cause of failed queries is indicated by the preceding log messages, troubleshooting others requires recompiling BIND with `--enable-querytrace`, which is not always a viable option for the user.
I think we can improve `named`'s behavior in this regard. Note that the response message's RCODE is derived from `qctx->result` using `dns_result_torcode()`, which handles a number of possible `isc_result_t` values and returns SERVFAIL for anything not explicitly listed. If we used `QUERY_ERROR(qctx, result);` instead of `QUERY_ERROR(qctx, DNS_R_SERVFAIL);` where possible, the specific error could be logged by `query_error()` and the response's RCODE would still be SERVFAIL. The win here would be that some light could be shed on the less obvious query errors just by bumping the debug level using `rndc trace` (or enabling query logging) rather than recompiling with `--enable-querytrace`.
[^1]: see e.g. https://lists.isc.org/pipermail/bind-users/2018-September/100868.html, though the issue caught me by surprise a couple of times as well while debugging
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/c635b3175620ea085a8d2402afd446dfd95422bd/bin/named/query.c#L8571-8580
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/7b49de3a79e6597d42f8c3a69e55c8b01e47324d/lib/ns/query.c#L6675-6679
[3]: https://gitlab.isc.org/isc-projects/bind9/blob/7b49de3a79e6597d42f8c3a69e55c8b01e47324d/lib/ns/query.c#L10644BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/5739.11.5rc1 statschannel test sometimes failing on ubuntu 18.042021-10-04T13:18:24ZCurtis Blackburn9.11.5rc1 statschannel test sometimes failing on ubuntu 18.04in 9.11.5rc1, on ubuntu 18.04, the statschannel test sometimes fails.
Testing 9.11.4-P2 on the same machine, I was unable to replicate the failure at all.
the failure seems to be rooted in the first check.
traffic.expect.1 (file incl...in 9.11.5rc1, on ubuntu 18.04, the statschannel test sometimes fails.
Testing 9.11.4-P2 on the same machine, I was unable to replicate the failure at all.
the failure seems to be rooted in the first check.
traffic.expect.1 (file included in tarball):
```
tcp request-size 16-31: 1
tcp response-size 64-79: 1
```
traffic.out.x1 (file generated by the test):
```
tcp request-size 16-31: 1
tcp response-size 16-31: 1
```
sample failure output:
```
S:statschannel:Wed Oct 3 12:10:33 PDT 2018
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTRANGE:12100 - 12199
I:statschannel:JSON tests require JSON library; skipping
I:statschannel:fetching traffic size data (1)
I:statschannel:... using xml
traffic.out.x1 traffic.expect.1 differ: byte 45, line 2
I:statschannel:failed
I:statschannel:fetching traffic size data after small UDP query (2)
I:statschannel:... using xml
traffic.out.x2 traffic.expect.2 differ: byte 45, line 2
I:statschannel:failed
I:statschannel:fetching traffic size data after large UDP query (4)
I:statschannel:... using xml
traffic.out.x4 traffic.expect.4 differ: byte 45, line 2
I:statschannel:failed
I:statschannel:fetching traffic size data after small TCP query (5)
I:statschannel:... using xml
traffic.out.x5 traffic.expect.5 differ: byte 100, line 4
I:statschannel:failed
I:statschannel:fetching traffic size data after large TCP query (6)
I:statschannel:... using xml
traffic.out.x6 traffic.expect.6 differ: byte 100, line 4
I:statschannel:failed
I:statschannel:checking consistency between named.stats and xml/json (7)
I:statschannel:checking consistency between regular and compressed output (8)
I:statschannel:checking if compressed output is really compressed (9)
I:statschannel:exit status: 5
R:statschannel:FAIL
E:statschannel:Wed Oct 3 12:10:36 PDT 2018
```https://gitlab.isc.org/isc-projects/bind9/-/issues/574BIND 9.13.4 Release Checklist2018-11-22T14:28:48ZVicky Riskvicky@isc.orgBIND 9.13.4 Release Checklist## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generatio...## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generation
- [x] Change software version and library versions in configure.in
- [x] Update CHANGES
- [x] Ensure the release notes are correct for this release
- [x] Ensure the metainformation is correct for this release
- [x] Make sure the tests are passing
- [x] Create a tag (name vX_Y_Z[-alphatag], content BIND X.Y.Z[-alphatag], signed with a developer's GPG key): git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z
- [x] Push the changes and tag
- [x] Create the tarball
- [x] Create the Windows zips
- [x] Ask QA to sanity check the tarball and zips
- [x] Request the signature on the tarballs
- [x] Make tarballs and signatures available to download
- [ ] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
- [ ] Update DEB and RPM packages
## Support
- [x] Inform support to upload to the web site (nice to give them a heads-up in advance)
- Write release e-mail to bind9-announce, bind-users in case of a major release
- Update tickets in case of waiting support customers
## Marketing
- [ ] Inform marketing to announce the release
- Post short note to Twitter
- Update http://en.wikipedia.org/wiki/BIND (mktg)
- Blog post if a major releaseBIND-9.13.42018-10-10https://gitlab.isc.org/isc-projects/bind9/-/issues/575BIND 9.12.3 Release Checklist2018-10-22T13:59:54ZVicky Riskvicky@isc.orgBIND 9.12.3 Release Checklist## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generatio...## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generation
- [x] Change software version and library versions in configure.in
- [x] Update CHANGES
- [x] Ensure the release notes are correct for this release
- [x] Ensure the metainformation is correct for this release
- [x] Make sure the tests are passing
- [x] Create a tag (name vX_Y_Z[-alphatag], content BIND X.Y.Z[-alphatag], signed with a developer's GPG key): git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z
- [x] Push the changes and tag
- [x] Create the tarball
- [x] Create the Windows zips
- [x] Ask QA to sanity check the tarball and zips
- [x] Request the signature on the tarballs
- [x] Make tarballs and signatures available to download
- [x] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
- [x] Update DEB and RPM packages
## Support
- [x] Inform support to upload to the web site (nice to give them a heads-up in advance)
- Write release e-mail to bind9-announce, bind-users in case of a major release
- Update tickets in case of waiting support customers
## Marketing
- [x] Inform marketing to announce the release
- Post short note to Twitter
- Update http://en.wikipedia.org/wiki/BIND (mktg)BIND-9.12.3https://gitlab.isc.org/isc-projects/bind9/-/issues/576BIND 9.11.5 Release Checklist2018-10-22T13:59:58ZVicky Riskvicky@isc.orgBIND 9.11.5 Release Checklist## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generatio...## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generation
- [x] Change software version and library versions in configure.in
- [x] Update CHANGES
- [x] Ensure the release notes are correct for this release
- [x] Ensure the metainformation is correct for this release
- [x] Make sure the tests are passing
- [x] Create a tag (name vX_Y_Z[-alphatag], content BIND X.Y.Z[-alphatag], signed with a developer's GPG key): git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z
- [x] Push the changes and tag
- [x] Create the tarball
- [x] Create the Windows zips
- [x] Ask QA to sanity check the tarball and zips
- [x] Request the signature on the tarballs
- [x] Make tarballs and signatures available to download
- [x] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
- [x] Update DEB and RPM packages
## Support
- [x] Inform support to upload to the web site (nice to give them a heads-up in advance)
- Write release e-mail to bind9-announce, bind-users in case of a major release
- Update tickets in case of waiting support customers
## Marketing
- [x] Inform marketing to announce the release
- Post short note to Twitter
- Update http://en.wikipedia.org/wiki/BIND (mktg)BIND-9.11.5https://gitlab.isc.org/isc-projects/bind9/-/issues/577BIND 9.11.5-S1 Release Checklist2018-11-08T15:18:27ZVicky Riskvicky@isc.orgBIND 9.11.5-S1 Release Checklist## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generatio...## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generation
- [x] Change software version and library versions in configure.in
- [x] Update CHANGES
- [x] Ensure the release notes are correct for this release
- [x] Ensure the metainformation is correct for this release
- [x] Make sure the tests are passing
- [x] Create a tag (name vX_Y_Z[-alphatag], content BIND X.Y.Z[-alphatag], signed with a developer's GPG key): git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z
- [x] Push the changes and tag
- [x] Create the tarball
---- (not) Create the Windows zips
- [x] Ask QA to sanity check the tarball and zips
- [x] Request the signature on the tarballs
- [x] Make tarballs and signatures available to download
## Support
- [x] Inform support (nice to give them a heads-up in advance)
- Update tickets to deliver to support customersBIND-9.11.5-S1https://gitlab.isc.org/isc-projects/bind9/-/issues/578Make the chained delegations in reclimit behave like they would in a regular ...2018-10-04T03:18:59ZMark AndrewsMake the chained delegations in reclimit behave like they would in a regular name server.The reclimit fixes from !548 need to be back ported further than 548 will be backported.The reclimit fixes from !548 need to be back ported further than 548 will be backported.https://gitlab.isc.org/isc-projects/bind9/-/issues/579EdDSA support does not work with the final version of OpenSSL 1.1.12018-10-04T10:54:04ZMichał KępieńEdDSA support does not work with the final version of OpenSSL 1.1.1The `eddsa` system test consistently fails on any platform with OpenSSL 1.1.1 installed:
```
S:eddsa:Thu Oct 4 11:24:57 CEST 2018
T:eddsa:1:A
A:eddsa:System test eddsa
I:eddsa:PORTRANGE:5300 - 5399
dnssec-signzone: warning: EVP_DigestS...The `eddsa` system test consistently fails on any platform with OpenSSL 1.1.1 installed:
```
S:eddsa:Thu Oct 4 11:24:57 CEST 2018
T:eddsa:1:A
A:eddsa:System test eddsa
I:eddsa:PORTRANGE:5300 - 5399
dnssec-signzone: warning: EVP_DigestSignInit failed (failure)
dnssec-signzone: fatal: dnskey './ED25519/30149' failed to sign data: failure
dnssec-signzone: warning: EVP_DigestSignInit failed (failure)
dnssec-signzone: fatal: dnskey 'example.com/ED25519/3613' failed to sign data: failure
I:checking that positive validation works (0)
I:failed
I:checking that test vectors match (1)
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
I:failed
I:exit status: 2
R:eddsa:FAIL
E:eddsa:Thu Oct 4 11:24:59 CEST 2018
```
Since this [includes current Debian sid][1], the `eddsa` system test should first be disabled so that CI pipelines can pass and then BIND's EdDSA code should be fixed to work with the final version of OpenSSL 1.1.1.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/63060BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/580rndc dumpdb -all does not dump ECS cache info in Supported Preview Edition2019-01-03T06:17:35ZMichael McNallyrndc dumpdb -all does not dump ECS cache info in Supported Preview Edition<!--
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
Per a customer report, in BIND 9 Supported Preview Edition (9.11.4-S1) "rndc dumpdb -all" does not properly dump ECS cache info (it should call the routines used for rndc dumpdb -ecscache but apparently does not.)
### BIND version used
BIND 9 Supported Preview Edition 9.11.4-S1Joey SalazarJoey Salazarhttps://gitlab.isc.org/isc-projects/bind9/-/issues/581rndc usage info does not properly list -ecscache option in BIND 9 Supported P...2018-11-21T07:37:46ZMichael McNallyrndc usage info does not properly list -ecscache option in BIND 9 Supported Preview Edition<!--
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
"rndc" without arguments gives usage information, but does not list the -ecscache option which is specific to Supported Preview Edition
### BIND version used
BIND 9 Supported Preview Edition 9.11.4-S1Joey SalazarJoey Salazarhttps://gitlab.isc.org/isc-projects/bind9/-/issues/582Feature request: allow port numbers for server-names or server-addresses2021-03-04T09:56:41ZMichael McNallyFeature request: allow port numbers for server-names or server-addressesWe received this request from a support customer:
### Request
I have a zone set up like this:
```
zone "ednstest.example.com" {
type static-stub;
server-names {
"srvr1-foo02.example.com";
"srvr2-foo02.exam...We received this request from a support customer:
### Request
I have a zone set up like this:
```
zone "ednstest.example.com" {
type static-stub;
server-names {
"srvr1-foo02.example.com";
"srvr2-foo02.example.com";
};
};
```
The owner of the zone asked me to test with his development server on port 8600, but there does not seem to be a way to specify a port number with this construction.
BIND already allows port number specifications in the "masters" and "forwarders" clauses, can it be allowed here too?
### Links / references
From support ticket https://support.isc.org/Ticket/Display.html?id=13620https://gitlab.isc.org/isc-projects/bind9/-/issues/583Regression: Forward queries with forward only is no longer working2018-10-29T19:31:03ZGhost UserRegression: Forward queries with forward only is no longer working### Summary
Running the latest bind version (9.13.3) forwarding queries with the `forward only` option is no longer working.
Basically I have a split horizon DNS, using multiple bind instances running on multiple hosts. But I was able ...### Summary
Running the latest bind version (9.13.3) forwarding queries with the `forward only` option is no longer working.
Basically I have a split horizon DNS, using multiple bind instances running on multiple hosts. But I was able to identify the culprit to be the resolver, which was configured to forward queries for specific zones to an internal authoritative server, while answering all other queries the usual way.
This used to work fine with `9.13.1`, but when upgrading to `9.13.2`, this no longer works. It is still broken in `9.13.3`.
### BIND version used
Broken version (`9.13.2`):
```
BIND 9.13.2 (Development Release) <id:4f6ef2f>
running on Linux x86_64 4.14.72-1-lts #1 SMP Wed Sep 26 12:31:03 CEST 2018
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-ipv6' '--enable-filter-aaaa' '--enable-fixed-rrset' '--enable-seccomp' '--enable-full-report' '--with-python=/usr/bin/python' '--with-geoip' '--with-idn' '--with-openssl' '--with-libjson' '--with-libxml2' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 8.2.1 20180831
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
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
threads support is enabled
```
Last version that used to work (`9.13.1`):
```
BIND 9.13.1 (Development Release) <id:5b71025>
running on Linux x86_64 4.14.72-1-lts #1 SMP Wed Sep 26 12:31:03 CEST 2018
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-ipv6' '--enable-filter-aaaa' '--enable-fixed-rrset' '--enable-seccomp' '--enable-full-report' '--with-python=/usr/bin/python' '--with-geoip' '--with-idn' '--with-openssl' '--with-libjson' '--with-libxml2' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 8.2.1 20180831
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
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
threads support is enabled
```
### Steps to reproduce
- Configure bind in a way where queries for a particular zone are forwarded to a dedicated authoritative nameserver. Use the `forward only` option for this. I'm attaching my `named.conf` further down below in this bug report.
- Issue an query to the forwarded zone
- Bind will return with a `SERVFAIL`
### What is the current *bug* behavior?
Any queries for the `babioch.de` zone are answered with `SERVFAIL`, for instance:
```
dig @10.24.0.1 mail.babioch.de
; <<>> DiG 9.13.2 <<>> @10.24.0.1 mail.babioch.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10792
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d4edf146ddd092808c7e71535bb8bbfc46eaa07e7d222dfe (good)
;; QUESTION SECTION:
;mail.babioch.de. IN A
;; Query time: 18 msec
;; SERVER: 10.24.0.1#53(10.24.0.1)
;; WHEN: Sa Okt 06 15:43:24 CEST 2018
;; MSG SIZE rcvd: 72
```
### What is the expected *correct* behavior?
Queries for the `babioch.de` zone are correctly answered:
```
dig @10.24.0.1 mail.babioch.de
; <<>> DiG 9.13.1 <<>> @10.24.0.1 mail.babioch.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59672
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ce6833cdc8a7f26af62c368d5bb8bc443c63c9ba62ea9a7d (good)
;; QUESTION SECTION:
;mail.babioch.de. IN A
;; ANSWER SECTION:
mail.babioch.de. 300 IN A 10.24.0.20
;; Query time: 1 msec
;; SERVER: 10.24.0.1#53(10.24.0.1)
;; WHEN: Sa Okt 06 15:44:36 CEST 2018
;; MSG SIZE rcvd: 88
```
### Relevant configuration files
The stripped down version of my configuration, which still will trigger this regression, looks like this:
```
options {
listen-on port 53 { 127.0.0.1; 10.24.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
pid-file "/run/named/named.pid";
recursion yes;
allow-query { localhost; 10.24.0.0/16; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.zone";
zone "babioch.de" IN {
type forward;
forward only;
forwarders { 10.24.0.10; };
};
```
### Relevant logs and/or screenshots
The query log contains this:
```
Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670 127.0.0.1#51022 (mail.babioch.de): query: mail.babioch.de IN A +E(0)K (127.0.0.1)
Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670 127.0.0.1#51022 (mail.babioch.de): query failed (SERVFAIL) for mail.babioch.de/IN/A at query.c:10672
```
### Possible fixes
The line in question is handling stale answers [1]. I'm not entirely sure how this applies to my use-case, since nothing should be stale here.
Interestingly enough I can get it working, when I'm removing the
"forward only" directive from my configuration. This looks like this:
I was able to work around this with commenting out the `forward only` option, effectively falling back to `forward first`. This works in my case, but there might be setups, where this is not an option.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/v9_13_3/lib/ns/query.c#L10672BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/584dig treats -4/-6/-m after -q argument as an option but not a domain name2023-07-10T16:05:40ZGhost Userdig treats -4/-6/-m after -q argument as an option but not a domain name### Summary
According to `man dig`, the argument after `-q` should always be treated as domain name:
```
-q name
The domain name to query. This is useful to distinguish the name
from other arguments.
```
However, I noticed that...### Summary
According to `man dig`, the argument after `-q` should always be treated as domain name:
```
-q name
The domain name to query. This is useful to distinguish the name
from other arguments.
```
However, I noticed that if `name` starts with `-4`, `-6` or `-m`, it will be treated as arguments, like this:
```
$ dig -q -64
dig: only one of -4 and -6 allowed
```
While other hyphen-starting name works well (I manually add A record for `-test` on our DNS server):
```
$ dig +short -q -test
1.2.3.4
```
(Domain name starting with hyphen is not legal in RFC1034. But most DNS server/client softwares indeed support it.)
### BIND version used
```
$ dig -v
DiG 9.13.3
```https://gitlab.isc.org/isc-projects/bind9/-/issues/585dnssec-coverage fails with TypeError for KSK with a Deletion date set2018-11-30T00:16:22ZGhost Userdnssec-coverage fails with TypeError for KSK with a Deletion date set### Summary
dnssec-coverage fails with a TypeError for a KSK for which a Deletion date set. It doesn't, when only ZSKs with a deletion date are used. But even if a KSK with a deletion date is present for the zone, it fails even with the...### Summary
dnssec-coverage fails with a TypeError for a KSK for which a Deletion date set. It doesn't, when only ZSKs with a deletion date are used. But even if a KSK with a deletion date is present for the zone, it fails even with the option -z to restrict it to ZSKs.
### BIND version used
BIND 9.11.4-P2-3~bpo9+1-Debian (Extended Support Version) <id:7107deb>
### Steps to reproduce
1. Create a KSK for a zone.
2. Create a second KSK for a key rollover event in the future for this zone.
3. Set the inactivation and deletion times of the first KSK accordingly.
4. Run dnssec-coverage
that means:
1. dnssec-keygen -f KSK -a 8 -b 2048 example.com
2. dnssec-keygen -P +20d -A +40d -f KSK -a 8 -b 2048 example.com
3. dnssec-settime -I ACTIVATIONTIME-KSK1 -D +40d KSK2.key
4. dnssec-coverage (either with -z, with -k or without is does occur)
### What is the current *bug* behavior?
Setting a deletion date in 40 days:
```
dnssec-settime -D +40d *40099.key
./Kexample.com.+008+40099.key
./Kexample.com.+008+40099.private
```
Then dnssec-coverage fails with a "TypeError: underable types: int() < NoneType()"
```
dnssec-coverage -k<br>
WARNING: Maximum TTL value was not specified. Using 1 week<br>
(604800 seconds); re-run with the -m option to get more<br>
accurate results.<br>
PHASE 1--Loading keys to check for internal timing problems<br>
Traceback (most recent call last):<br>
File "/usr/sbin/dnssec-coverage", line 27, in <module><br>
isc.coverage.main()<br>
File "/usr/lib/python3/dist-packages/isc/coverage.py", line 261, in main<br>
key.check_postpub(output)<br>
File "/usr/lib/python3/dist-packages/isc/dnskey.py", line 477, in check_postpub<br>
if d - i < timespan:<br>
TypeError: unorderable types: int() < NoneType()
```
### What is the expected *correct* behavior?
No errors found.
### Possible fixes
The error occurs in file "/usr/lib/python3/dist-packages/isc/dnskey.py", line 477, in check_postpub
if d - i < timespan:
but stems from the fact that timespan is of type NoneType and stems therefore most likely from before in line 453:
if timespan = None:
timespan = self.ttl
and is already there of type NoneType. Though, it is unclear to me, why.https://gitlab.isc.org/isc-projects/bind9/-/issues/586dns_rdatatype_{to,from}text are not consistent for "reserved" types2019-04-25T15:54:36ZCathy Almonddns_rdatatype_{to,from}text are not consistent for "reserved" types### Summary
As reported by a customer: https://support.isc.org/Ticket/Display.html?id=13627
I've just noticed this inconsistency: dns_rdatatype_totext() dumps "well-known" mnemonics for "reserved" types such as "EID" for 31; dns_rdatat...### Summary
As reported by a customer: https://support.isc.org/Ticket/Display.html?id=13627
I've just noticed this inconsistency: dns_rdatatype_totext() dumps "well-known" mnemonics for "reserved" types such as "EID" for 31; dns_rdatatyep_fromtext() refuses to recognize these mnemonics. Also, RRs of these types can be loaded into a zone unless the type mnemonic is used to represent it, e.g:
eid TYPE31 \# 4 01020304
As a result of these, some awkward things can happen. For example, you can sign a zone containing these records, but the resulting zone file uses the mnemonic for them and RRSIG/NSEC[3]:
eid.example.com. 3600 IN EID \# 4 ( 01020304 )
3600 RRSIG EID 5 3 3600 (
20181107145744 20181008145744 47451 exam...
Cb8N+aFXgFu2s2ef5EfmvXZj05M= )
3600 NSEC foo.example.com. EID RRSIG NSEC
So the signed zone can't be loaded:
8-Oct-2018 09:16:34.910 sigs/example.zone.signed:87: unknown RR type 'EID'
08-Oct-2018 09:16:34.910 zone example.com/IN: loading from master file sigs/example.zone.signed failed: not implemented
08-Oct-2018 09:16:34.910 zone example.com/IN: not loaded due to errors.
I suspect a similar issue can happen for a secondary zone if the zone file is saved in the "text" format.
These are certainly minor corner cases and probably no one cares in practice. But especially if so, I'd rather suggest making it more consistent (by, dumping TYPEnnn form and/or even refusing to load these types of RRs like the case of type 0) than making such a subtle failure mode happen.
Perhaps a bit more interesting case is DDNS update. Any client that is allowed to add, e.g., 'eid.example.com. 3600 IN TYPE31 \# 4 01020304', can make the entire zone unloadable once the zone content is dumped to a file (I've confirmed this with 9.11.3-S2). This is probably considered a case of someone shooting their own foot, but given that the zone administrator and the owner of the update client can be different, you may probably rather want to prevent it from happening.Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/587statistics-channels /xml/v2 is removed but still documented2018-11-13T19:07:18ZPetr Menšíkstatistics-channels /xml/v2 is removed but still documented<!--
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
ARM contains documentation of statistics-channels format of /xml/v2. But code does not allow such format anymore. Only /xml/v3 and /json/v1 are supported in code.
### BIND version used
BIND 9.11.4-RedHat-9.11.4-2.fc27
It seems present also in devel version
### Steps to reproduce
grep '/v2' -r doc
doc/arm/Bv9ARM.ch05.html: <a class="link" href="http://127.0.0.1:8888/xml/v2" target="_top">http://127.0.0.1:8888/xml/v2</a> for version 2
doc/arm/Bv9ARM-book.xml: <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v2">http://127.0.0.1:8888/xml/v2</link> for version 2
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
Documents statistics format that cannot be configured.
### What is the expected *correct* behavior?
Do not mention format that is not available.
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/588build failure related to libtool on NetBSD2020-11-11T07:53:00ZHåvard Eidnesbuild failure related to libtool on NetBSD<!--
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
Configured with
./configure --with-libxml2=yes --with-tuning=large --with-libtool
run on NetBSD/amd64 7.1_STABLE, BIND fails to build.
### BIND version used
```
BIND 9.12.2-P2 <id:b2bf278>
running on NetBSD amd64 7.1_STABLE NetBSD 7.1_STABLE (GENERIC) #0: Mon Feb 5 12:42:24 CET 2018 he@xxxxxxxx:/usr/obj/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--with-libtool'
compiled by GCC 4.8.4
compiled with OpenSSL version: OpenSSL 1.0.1t 3 May 2016
linked to OpenSSL version: OpenSSL 1.0.1t 3 May 2016
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.3
threads support is enabled
```
### Steps to reproduce
Try to build BIND after configuring.
Watch it fail with libtool-related issues in either
bin/tests/system/dyndb/driver/
or
bin/tests/system/dlzexternal/
### What is the current *bug* behavior?
Out of the box, this happens:
```
CLEANED=`echo "../../../../../lib/dns/libdns.la -lgssapi ../../../../../lib/isc/libisc.la -lcrypto -lgssapi ../../../../../lib/dns/libdns.la -lgssapi ../../../../../lib/isc/libisc.la -lcrypto -lpthread -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lxml2 -L/usr/lib -lz -L/usr/lib -llzma -L/usr/lib -lm" | sed -e s/-Wl,//g`; /bin/sh /usr/local/src/bind-9.12.2-P2/libtool --mode=link --tag=CC ld -Bshareable -x -o sample.so db.lo driver.lo instance.lo lock.lo log.lo syncptr.lo zone.lo ${CLEANED}
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/pkg/lib -L/usr/lib ../../../../../lib/dns/.libs/libdns.so /usr/local/src/bind-9.12.2-P2/lib/isc/.libs/libisc.so -lgssapi ../../../../../lib/isc/.libs/libisc.so -lcrypto -lpthread /usr/pkg/lib/libxml2.so -lz -llzma -lm -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib
ld: unrecognized option '-Wl,-rpath'
ld: use the --help option for usage information
*** Error code 1
Stop.
make[5]: stopped in /usr/local/src/bind-9.12.2-P2/bin/tests/system/dyndb/driver
```
It appears that libtool adds the "-Wl,-rpath" entries, as if it was talking to the C compiler instead of 'ld'.
So I patched configure.in to use "${CC}" and "-shared -Wl,-x" as SO_LD and SO_LDFLAGS respectively for NetBSD.
This is however not sufficient -- the person coding the Makefile.in in the above mentioned directories
is apparently somewhere half-way between actually using libtool and doing the linking "by hand".
### What is the expected *correct* behavior?
The build should complete...
The combined diff file attached here acheives that (but the required renaming of the shared library
objects may require other code to adapt). Libtool insists that things it should link into a library
must start with "lib" and end in ".la", and adding "-rpath somedir" automagically triggers the creation
of a shared library object.
### Relevant configuration files
This is not a run-time issue, so no relevant config files.
### Relevant logs and/or screenshots
None, above the excerpt above.
### Possible fixes
Diff attached.
[diff](/uploads/c45b33d7dedb52d5544c53c27284f174/diff)
Oh, yes, and the SO_STRIP construct looks extremely sketchy;
it only processes the arguments given to libtool, not the arguments
libtool as a result might emit, such as "-Wl,-rpath,/dir"...
It looks like a bad band-aid which should be removed.https://gitlab.isc.org/isc-projects/bind9/-/issues/589some unexpected errors occur, responding to IPv4 clients on NetBSD2019-09-26T09:19:05ZHåvard Eidnessome unexpected errors occur, responding to IPv4 clients on NetBSD<!--
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 keeps logging (not super-high frequency, but enough to worry):
```
Oct 11 20:16:44 nn named[478]: socket.c:2170: unexpected error:
Oct 11 20:16:44 nn named[478]: internal_send: 62.212.64.122#47249: Invalid argument
Oct 11 20:16:44 nn named[478]: client @0x7f7fec9de000 62.212.64.122#47249 (smtp.hedmark.org): error sending response: invalid file
...
Oct 11 20:16:51 nn named[478]: socket.c:2170: unexpected error:
Oct 11 20:16:51 nn named[478]: internal_send: 109.247.114.11#33800: Invalid argument
Oct 11 20:16:51 nn named[478]: client @0x7f7fec9ee000 109.247.114.11#33800 (gbubwsavujj.hedmark.org): error sending response: invalid file
Oct 11 20:16:51 nn named[478]: socket.c:2170: unexpected error:
Oct 11 20:16:51 nn named[478]: internal_send: 109.247.114.11#33617: Invalid argument
Oct 11 20:16:51 nn named[478]: client @0x7f7fec8ce000 109.247.114.11#33617 (sdtwslh.hedmark.org): error sending response: invalid file
```
I suspect the corresponding messages gets lost.
### BIND version used
```
BIND 9.12.2-P2 <id:b2bf278>
running on NetBSD amd64 7.1_STABLE NetBSD 7.1_STABLE (GENERIC) #0: Mon Feb 5 12:42:24 CET 2018 he@xxxxxx:/usr/obj/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--with-libtool'
compiled by GCC 4.8.4
compiled with OpenSSL version: OpenSSL 1.0.1t 3 May 2016
linked to OpenSSL version: OpenSSL 1.0.1t 3 May 2016
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.3
threads support is enabled
```
### Steps to reproduce
Run a publishing instance of BIND on NetBSD,
deployed in a dual-stack IPv4/IPv6 environment.
Watch the log, observe these occur from time to time.
Our name server provides slave service for many others,
and serves a little more than 3500 zones, and receives
around 3-400 qps.
### What is the current *bug* behavior?
Some packets are in all probability being lost on the way out of the BIND name server.
Doing some system call tracing reveals:
```
478 5 named CALL sendmsg(0x202,0x7f7ff07f8e80,0)
478 5 named MISC msghdr: [name=0x7f7feca05098, namelen=16, iov=0x7f7ff07f8ef0, iovlen=1, control=0x7f7ff07f8ff0, controllen=24, flags=4000000]
478 5 named MISC mbsoname: [74.125.46.12]
478 5 named MISC mbcontrol: [len=20, level=41, type=42]
478 5 named RET sendmsg -1 errno 22 Invalid argument
```
The important points here are:
* The response is being sent to an IPv4 destination
* The "control message" is for level=41 == IPPROTO_IPV6
* The "control type" is type=42 == IPV6_USE_MIN_MTU
Knowing that NetBSD insists on separate sockets for IPv4 and IPv6,
it will in all probability balk at this, and this is the probable
cause for returning EINVAL and dropping the packet.
Now, `lib/isc/unix/socket.c`'s `build_msghdr_send()` only adds the
IPV6_USE_MIN_MTU if it is a UDP socket and
`((dev->attributes & ISC_SOCKEVENTATTR_USEMINMTU) != 0)` holds true.
In turn, the `ISC_SOCKEVENTATTR_USEMINMTU` is set in `lib/ns/client.c`
under this condition: `(!TCP_CLIENT(client) && r.length > 1432)`.
You will notice the conspicuous absence of testing for what protocol
family this socket actually belongs to, and this therefore probably
causes all UDP responses larger than 1432 to IPv4 destinations to be
dropped.
### What is the expected *correct* behavior?
IPv4 UDP response packets above size 1432 should not be dropped.
...by avoiding setting IPv6-only-relevant options in IPv4 sockets.
### Relevant configuration files
This isn't dependent on configuration.
### Relevant logs and/or screenshots
Excerpt of log found above.
### Possible fixes
The check for the appropriate protocol family appear to be possible
to do in `lib/isc/unix/socket.c`:
```
--- lib/isc/unix/socket.c.orig 2018-09-04 03:50:19.000000000 +0000
+++ lib/isc/unix/socket.c
@@ -1572,7 +1572,8 @@ build_msghdr_send(isc__socket_t *sock, c
#if defined(IPV6_USE_MIN_MTU)
if ((sock->type == isc_sockettype_udp) &&
- ((dev->attributes & ISC_SOCKEVENTATTR_USEMINMTU) != 0))
+ ((dev->attributes & ISC_SOCKEVENTATTR_USEMINMTU) != 0) &&
+ (sock->pf == AF_INET6))
{
int use_min_mtu = 1; /* -1, 0, 1 */
```
Perhaps suitably adorned with ifdefs for those kind of systems
which do not need this additional test (Linux?).https://gitlab.isc.org/isc-projects/bind9/-/issues/590[Win32] sample-gai.c should call WSAStartup()2019-01-15T05:26:33ZGhost User[Win32] sample-gai.c should call WSAStartup()I fail to get the `lib/sample/sample-gai.c` to work on Windows since `WSAStartup()` wasn't called anywhere AFAICS.
The replacement function `getaddrinfo()` calls `getservbyname()` (not replaced). This call fails due to a missing `WSASt...I fail to get the `lib/sample/sample-gai.c` to work on Windows since `WSAStartup()` wasn't called anywhere AFAICS.
The replacement function `getaddrinfo()` calls `getservbyname()` (not replaced). This call fails due to a missing `WSAStartup()`.
An easy fix would simply be:
```diff
--- a/lib/samples/sample-gai.c 2018-06-07 17:54:40
+++ a/lib/samples/sample-gai.c 2018-10-12 03:39:26
@@ -62,6 +62,17 @@
int
main(int argc, char *argv[]) {
+#ifdef _WIN32
+ WORD wVersionRequested = MAKEWORD(2, 2);
+ WSADATA wsaData;
+ int err = WSAStartup(wVersionRequested, &wsaData);
+
+ if (err != 0) {
+ fprintf(stderr, "WSAStartup() failed: %d\n", err);
+ return (1);
+ }
+#endif
+
if (argc < 2)
exit(1);
@@ -69,5 +80,8 @@
do_gai(AF_INET6, argv[1]);
do_gai(AF_UNSPEC, argv[1]);
+#ifdef _WIN32
+ WSACleanup();
+#endif
return (0);
}
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/591Add per keyid managed keys validation success counters.2021-10-04T13:19:03ZMark AndrewsAdd per keyid managed keys validation success counters.This will allow administrators to see which keys/sig pairs are successful.This will allow administrators to see which keys/sig pairs are successful.https://gitlab.isc.org/isc-projects/bind9/-/issues/592Bind 9.12.2 P2 with Openssl Issue -- prng not seeded Issue -- Not started bind2018-10-26T04:22:24ZGhost UserBind 9.12.2 P2 with Openssl Issue -- prng not seeded Issue -- Not started bind<!--
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
(Summarize the bug encountered concisely.)
### BIND version used
(Paste the output of `named -V`.)
### Steps to reproduce
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
(What actually happens.)
### What is the expected *correct* behavior?
(What you should see instead.)
### 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
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/593Follow-up from "WIP: Miscellaneous style fixes - implicit casts to bool and u...2018-10-13T05:36:44ZOndřej SurýFollow-up from "WIP: Miscellaneous style fixes - implicit casts to bool and uninitialized variables fixes"The following discussion from !851 should be addressed:
- [ ] @ondrej commented on a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/851#note_24017): (+3 comments)
> This makes me little bit worried about the...The following discussion from !851 should be addressed:
- [ ] @ondrej commented on a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/851#note_24017): (+3 comments)
> This makes me little bit worried about the tests we have. No test has caught this, so we should probably make an issue from this, so there's a test.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/594Update Contribution Guide Link2018-11-08T16:43:20ZThomas JachUpdate Contribution Guide LinkThe ```Contribution guide``` link at https://gitlab.isc.org/isc-projects/bind9 certainly should point to ```CONTRIBUTING.md``` instead of ```CONTRIBUTING```.The ```Contribution guide``` link at https://gitlab.isc.org/isc-projects/bind9 certainly should point to ```CONTRIBUTING.md``` instead of ```CONTRIBUTING```.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/595Exceeding transfers-per-ns quota aborts zone refresh2023-11-02T16:32:27ZGhost UserExceeding transfers-per-ns quota aborts zone refresh### Summary
A zone transfer abandoned because the selected master host's `transfers-per-ns` quota is reached cancels the whole refresh activity for the zone even when alternative master hosts are configured and below quota.
This causes...### Summary
A zone transfer abandoned because the selected master host's `transfers-per-ns` quota is reached cancels the whole refresh activity for the zone even when alternative master hosts are configured and below quota.
This causes updates to be unnecessarily delayed; another refresh will not occur until the zone's refresh timer expires or another NOTIFY message is received.
The effect of this is that just one slow master host effectively torpedoes overall zone-transfer latency even when lots of other master servers are available to use. A slow master which holds its zone transfer sessions open longer than usual causing it to reach its quota kills off the refresh activities for all zones that it's named's currently preferred master for.
### Steps to reproduce
Use the likes of `tc` on a slave host to slow TCP sessions to its first-listed master host to the point where the number of concurrent TCP transfer sessions exceeds the `transfers-per-ns` limit. Observe that slave hosts abort refresh activities for zones due to `transfers-per-ns` quota without trying the other master hosts.
### What is the current *bug* behavior?
Exceeding the `transfers-per-ns` quota for one master aborts the refresh activity for the zone, not just the transfer from the over-quota master.
### What is the expected *correct* behavior?
If there are other masters for the zone, they are below their own `transfers-per-ns` quota, and the global `transfers-in` quota is not exceeded, the alternative masters should be used.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/596Option to eliminate cross-zone glue in authoritative server responses2021-10-04T13:22:09ZCathy AlmondOption to eliminate cross-zone glue in authoritative server responses### Description
BIND in all currently-supported versions will return any cross-zone or out-of zone glue that it happens to have in its possession in its referral responses to clients.
There are three scenarios when it might do this:
...### Description
BIND in all currently-supported versions will return any cross-zone or out-of zone glue that it happens to have in its possession in its referral responses to clients.
There are three scenarios when it might do this:
a) The zone administrators added the out-of-zone glue to the zone when adding a delegation NS RRset and associated A/AAAA RRs. This out-of-zone glue is loaded by BIND anyway, isn't returned if queried-for directly (obviously - the server isn't auth for the zone), but it will be returned as glue in referrals to delegated zones whose out-of-zone RRs "need" it.
b) The authoritative server is serving multiple zones (e.g. Verisign serve both .com and .net) and thus quite often the cross-zone glue is available authoritatively.
c) The authoritative server is delegating e.g. bar.com and foo.com where some of foo.com's servers are in the bar.com domain and are also authoritative for bar.com, therefore are included (legitimately) as bar.com's glue.
There are situations where returning out-of-zone glue is undesirable (see references below).
The scenario a) can be mitigated by the zone administrator manually (remove the out-of-zone glue from the zone).
Scenarios b) and c) are currently unavoidable - named returns the out of zone glue regardless.
### Request
In its simplest form, just stop adding out-of-zone glue to referral query responses for delegated subdomains.
There is a more complex discussion however. The DNS RFCs currently don't forbid the following scenario:
```
foo.com.au. IN NS ns1.bar.com.
bar.com.au. IN NS ns1.foo.com.
ns1.foo.com. IN A 1.2.3.4
ns1.bar.com. IN A 1.2.3.5
```
Because each of the delegated subdomains is dependent on the other one, the glue is required. And that's just a very simple delegation dependency chain - it's possible to make more complicated ones.
So either we need a mechanism for signalling (on a per zone basis) that out-of-zone glue if available should be served. Or, we need to clarify whether or not this scenarios is permissible in the DNS (RFC update - feed the camel..?)
References:
https://support.isc.org/Ticket/Display.html?id=13434
https://indico.dns-oarc.net/event/29/contributions/660/attachments/630/1013/2018-10-OARC-Verisign-TLDs.pdf
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/598Wishlist: statistics for DNS-over-TCP and TLS2024-02-29T16:01:45ZTony FinchWishlist: statistics for DNS-over-TCP and TLSA couple of suggestions:
1. For DNS-over-TLS using a proxy, it would be nice to have separate statistics counters from queries that came from the proxy. When the TLS proxy is running on the same server, it would be enough to have sepa...A couple of suggestions:
1. For DNS-over-TLS using a proxy, it would be nice to have separate statistics counters from queries that came from the proxy. When the TLS proxy is running on the same server, it would be enough to have separate counters when the client address is in the interface list that BIND keeps track of. Is this generally useful enough to be worthwhile?
2. For DNS-over-TCP (and by implication, DNS-over-TLS) it would be helpful to have some guide to setting TCP idle timeouts. Two things would help:
* include the connection age in the query log - useful for later analysis, but no good if query logging needs to be left off
* keep an overall histogram of connection age - I don't know of any smaller summary statistics that would be useful, because the distribution of queries is very skewedBIND 9.19.xAydın MercanAydın Mercanhttps://gitlab.isc.org/isc-projects/bind9/-/issues/599assertion error in isc__timer_create(): task != ((void *)0)2018-11-13T13:25:12ZAndreas Hasenackandreas@canonical.comassertion error in isc__timer_create(): task != ((void *)0)<!--
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
The command `host -t soa local.` crashed with an assertion error:
`#2 0x00007fe590c645ef in isc_assertion_failed (file=file@entry=0x7fe590cb769c "../../../lib/isc/timer.c", line=line@entry=392, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7fe590cb0103 "task != ((void *)0)") at ../../../lib/isc/assertions.c:52`
Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1797926
### BIND version used
1:9.11.4+dfsg-3ubuntu5 in Ubuntu Cosmic 18.10 (https://launchpad.net/ubuntu/+source/bind9/1:9.11.4+dfsg-3ubuntu5)
### Steps to reproduce
Unknown, but reporter indicated it was after his computer came back from sleep.
### What is the current *bug* behavior?
The `host` command failed with an assertion error.
### What is the expected *correct* behavior?
The `host` command should produce a result, or timeout and fail gracefully.
### Relevant logs and/or screenshots
Backtrace:
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
[Error: raise.c was not found in source tree]
#1 0x00007fe590a44535 in __GI_abort () at abort.c:79
[Error: abort.c was not found in source tree]
#2 0x00007fe590c645ef in isc_assertion_failed (file=file@entry=0x7fe590cb769c "../../../lib/isc/timer.c", line=line@entry=392, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7fe590cb0103 "task != ((void *)0)") at ../../../lib/isc/assertions.c:52
47: void
48: isc_assertion_failed(const char *file, int line, isc_assertiontype_t type,
49: const char *cond)
50: {
51: isc_assertion_failed_cb(file, line, type, cond);
52: abort();
53: /* NOTREACHED */
54: }
55:
56: /*% Set callback. */
57: void
#3 0x00007fe590c9245a in isc__timer_create (manager0=0x7fe58d741010, type=<optimized out>, expires=<optimized out>, interval=<optimized out>, task=0x0, action=0x55bcf1af75c0 <connect_timeout>, arg=0x7fe58d74e018, timerp=0x7fe58d74e288) at ../../../lib/isc/timer.c:457
452: timer->index = 0;
453: result = isc_mutex_init(&timer->lock);
454: if (result != ISC_R_SUCCESS) {
455: isc_task_detach(&timer->task);
456: isc_mem_put(manager->mctx, timer, sizeof(*timer));
457: return (result);
458: }
459: ISC_LINK_INIT(timer, link);
460: timer->common.impmagic = TIMER_MAGIC;
461: timer->common.magic = ISCAPI_TIMER_MAGIC;
462: timer->common.methods = (isc_timermethods_t *)&timermethods;
#4 0x000055bcf1aef75a in bringup_timer (query=0x7fe58d74e018, default_timeout=<optimized out>) at ../../../bin/dig/dighost.c:2949
2944: }
2945: debug("have local timeout of %d", local_timeout);
2946: isc_interval_set(&l->interval, local_timeout, 0);
2947: if (query->timer != NULL)
2948: isc_timer_detach(&query->timer);
2949: result = isc_timer_create(timermgr, isc_timertype_once, NULL,
2950: &l->interval, global_task, connect_timeout,
2951: query, &query->timer);
2952: check_result(result, "isc_timer_create");
2953: }
2954:
#5 0x000055bcf1af6e22 in send_udp (query=0x7fe58d74e018) at ../../../bin/dig/dighost.c:3135
3130: dig_query_t *next;
3131:
3132: debug("send_udp(%p)", query);
3133:
3134: l = query->lookup;
3135: bringup_timer(query, UDP_TIMEOUT);
3136: l->current_query = query;
3137: debug("working on lookup %p, query %p", query->lookup, query);
3138: if (!query->recv_made) {
3139: /* XXX Check the sense of this, need assertion? */
3140: query->waiting_connect = ISC_FALSE;
#6 0x000055bcf1af76c5 in connect_timeout (task=<optimized out>, event=<optimized out>) at ../../../bin/dig/dighost.c:3265
3260:
3261: if (l->retries > 1) {
3262: if (!l->tcp_mode) {
3263: l->retries--;
3264: debug("resending UDP request to first server");
3265: send_udp(ISC_LIST_HEAD(l->q));
3266: } else {
3267: debug("making new TCP request, %d tries left",
3268: l->retries);
3269: l->retries--;
3270: requeue_lookup(l, ISC_TRUE);
#7 0x00007fe590c8c439 in dispatch (manager=0x7fe58d73f010) at ../../../lib/isc/task.c:1141
1136: ISC_MSGSET_TASK,
1137: ISC_MSG_EXECUTE,
1138: "execute action"));
1139: if (event->ev_action != NULL) {
1140: UNLOCK(&task->lock);
1141: (event->ev_action)(
1142: (isc_task_t *)task,
1143: event);
1144: LOCK(&task->lock);
1145: }
1146: dispatch_count++;
#8 run (uap=0x7fe58d73f010) at ../../../lib/isc/task.c:1313
1308: isc__taskmgr_t *manager = uap;
1309:
1310: XTHREADTRACE(isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
1311: ISC_MSG_STARTING, "starting"));
1312:
1313: dispatch(manager);
1314:
1315: XTHREADTRACE(isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
1316: ISC_MSG_EXITING, "exiting"));
1317:
1318: #ifdef OPENSSL_LEAKS
#9 0x00007fe590c14164 in start_thread (arg=<optimized out>) at pthread_create.c:486
[Error: pthread_create.c was not found in source tree]
#10 0x00007fe590b3cdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
[Error: clone.S was not found in source tree]
```
The `host` call that triggered the assertion was most likely the same one from issue https://gitlab.isc.org/isc-projects/bind9/issues/520BIND 9.13.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/600bind9 stopped working in different Debian releases - DNSSEC errors2018-10-17T15:38:58ZGhost Userbind9 stopped working in different Debian releases - DNSSEC errors<!--
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
In three days Bind9 stopped working on many our Debian server /version, 7, 8).
Please note that they are dmz firewalls or mail servers, not specific dns servers so all server have 53 tcp/udp closed to world.
The logs shows many many us:
##named[23725]: error (broken trust chain) resolving
##validating @0x7f0fcc341860: it DS: bad cache hit (./DNSKEY)
##named[23725]: validating @0x7f0fc40420d0: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.
The only solution to start bind9 was add theese in named.conf.option
dnssec-validation no;
dnssec-enable no;
### BIND version used
Debian7:
BIND 9.8.4-rpz2+rl005.12-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
using libxml2 version: 2.8.0
Debian8:
BIND 9.8.4-rpz2+rl005.12-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
using libxml2 version: 2.8.0
### Steps to reproduce
We do not know how reproduce.
We removed yesterday the options dnssec-validation no; dnssec-enable no;
and the problem did not return.
### What is the current *bug* behavior?
(What actually happens.)
### What is the expected *correct* behavior?
(What you should see instead.)
### Relevant configuration files
'options {
directory "/var/cache/bind";
forwarders {
xxx.xxx.xxx.xxx;
xxx.xxx.xxx.xxx;
};
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { none; };
};'
### Relevant logs and/or screenshots
'Oct 17 08:31:01 mail9 named[23725]: validating @0x7f0fcc3d0780: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.'
'Oct 17 08:31:01 mail9 named[23725]: error (no valid KEY) resolving './DNSKEY/IN': 198.41.0.4#53'
'Oct 17 08:31:01 mail9 named[23725]: validating @0x7f0fc403e980: . DNSKEY: unable to find a DNSKEY which verifies the DNSKEY' ''RRset and also matches a trusted key for '.''
'Oct 17 08:31:01 mail9 named[23725]: validating @0x7f0fc403e980: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.'
'Oct 17 08:31:01 mail9 named[23725]: error (no valid KEY) resolving './DNSKEY/IN': 199.7.83.42#53'
'Oct 17 08:31:01 mail9 named[23725]: validating @0x7f0fcc3d0780: . DNSKEY: unable to find a DNSKEY which verifies the DNSKEY ''RRset and also matches a trusted key for '.'
'Oct 17 08:31:01 mail9 named[23725]: validating @0x7f0fcc3d0780: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.'
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/601Build option --with-python should default to yes2018-11-23T11:58:05ZAnand BuddhdevBuild option --with-python should default to yesWhen building BIND on a minimal build system (where there's no python or python-ply), the "dnssec-keymgr" utility does not get built or installed. However, this tool is rather important. I wasn't even aware of it, and it took a long whil...When building BIND on a minimal build system (where there's no python or python-ply), the "dnssec-keymgr" utility does not get built or installed. However, this tool is rather important. I wasn't even aware of it, and it took a long while to figure out why it wasn't being built.
I feel that newer versions of BIND should default to yes for --with-python. This will ensure that dnssec-keymgr gets built and installed by default. This should be fine on most modern Linux distributions because they should meet the minimum requirements.
There are a small number of common distributions out there, such as CentOS 6, which ship with Python 2.6. When building for them, one can use --without-python.
By the way, I discussed this with Mark Andrews at RIPE 77, and he agreed with my suggestion.https://gitlab.isc.org/isc-projects/bind9/-/issues/602Serve-stale implementation broke cache database RRset statistics2020-08-26T21:24:35ZMichał KępieńServe-stale implementation broke cache database RRset statisticsServe-stale implementation (see commit df50751585b64f72d93ad665abf0f485c8941a3b, [RT #44790][1]) changed the definition of a "stale" rdataset header:
* in BIND 9.11 and earlier, a "stale" rdataset header is one that is more than `RBTDB...Serve-stale implementation (see commit df50751585b64f72d93ad665abf0f485c8941a3b, [RT #44790][1]) changed the definition of a "stale" rdataset header:
* in BIND 9.11 and earlier, a "stale" rdataset header is one that is more than `RBTDB_VIRTUAL` (a hard-coded value of 300) seconds past its TTL-based expiry time and thus is eligible for opportunistic cleanup,
* in BIND 9.12 and later, rdataset headers of the above type are known as "ancient"; meanwhile, a "stale" rdataset header is one which is past its TTL-based expiry time but *not* yet eligible for cleanup; a "stale" header becomes an "ancient" header once `max-stale-ttl + RBTDB_VIRTUAL` seconds pass since its TTL-based expiry time.
The BIND statistics system has been able to track "stale" rdataset headers (according to the BIND 9.11 definition) since commit 80fa3ef8517ff046a72c4cb1e785f30c9ef9ee75 (see [RT #29514][2]). In the outputs of various statistics channels, such RRsets were prefixed with a `#` character.
Serve-stale implementation in BIND 9.12 introduced the following problems:
* As a corollary of the definition change described above, RRsets previously presented using the `#` prefix are no longer the same type of RRsets as before.
* The arrays holding statistics counters were not adjusted to account for the definition change, which means BIND stopped keeping track of "ancient" rdataset header counts altogether (such headers are processed and freed correctly but they do not affect statistics).
* Functions responsible for dumping statistics to various channels were not extended as no new `DNS_RDATASTATSTYPE_ATTR_*` macro was added, etc.
* Certain code comments were not updated to match the new nomenclature, which is guaranteed to cause quite a bit of confusion for new BIND developers.
* The rule for updating counters when an rdataset header is marked as "stale" (according the BIND 9.11 definition; the rule is: first decrement the number of "non-stale" records of given type, then increment the number of "stale" records of given type) no longer holds up: depending on query patterns, an rdataset header may either go through the entire "active" → "stale" → "ancient" cycle or go straight from "active" to "ancient". In other words, current rdataset header state needs to be consulted in order to determine which counters should be touched.
* No statistics counters are updated when an rdataset header is marked as "stale" (according to the BIND 9.12 definition).
Given all of the above issues and the fact that the default value of `max-stale-ttl` is non-zero, I would dare to say that cache database RRset statistics are more or less useless in BIND 9.12 and later.
[1]: https://bugs.isc.org/Ticket/Display.html?id=44790
[2]: https://bugs.isc.org/Ticket/Display.html?id=29514BIND 9.15.3https://gitlab.isc.org/isc-projects/bind9/-/issues/603CentOS 7 isc-bind package should not contain /var/run/named2018-10-18T13:04:42ZAnand BuddhdevCentOS 7 isc-bind package should not contain /var/run/namedI had a look at the isc-bind package you're providing, and I have some feedback for improvement.
The package is shipping with /var/run/named, named:named, and mode 0770. However, /var/run on CentOS 7 is a tmpfs, and all data in there is...I had a look at the isc-bind package you're providing, and I have some feedback for improvement.
The package is shipping with /var/run/named, named:named, and mode 0770. However, /var/run on CentOS 7 is a tmpfs, and all data in there is lost at reboot.
I do notice also that the package is correctly shipping with /usr/lib/tmpfiles.d/named.conf, which creates a rundir for BIND at boot. However, this tmpfiles snippet creates /run/named with mode 0755. So after a reboot, if an operator runs "rpm -V isc-bind", rpm will complain that the permissions on /var/run/named have changed.
I recommend that you NOT package and ship /var/run/named in the RPM. Instead, add this to the %post section of the package:
systemd-tmpfiles --create named.conf &> /dev/null || :
When installing the isc-bind on a system for the first time, this will create /run/named (and allow named to be run immediately), and also make sure it's present on subsequent boots.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/604Get rid of isc_socket_{recv,sendto}v{,2} functions from dig2018-11-08T16:42:11ZWitold KrecickiGet rid of isc_socket_{recv,sendto}v{,2} functions from digDig (dighost.c) is the only place we're using iovec-like versions of socket_recv/send functions, we should get rid of those as that'd simplify the codebase.Dig (dighost.c) is the only place we're using iovec-like versions of socket_recv/send functions, we should get rid of those as that'd simplify the codebase.https://gitlab.isc.org/isc-projects/bind9/-/issues/605Add SipHash24 and synchronize the Cookie algorithm with other vendors2019-07-22T12:15:37ZOndřej SurýAdd SipHash24 and synchronize the Cookie algorithm with other vendorsBIND 9.15.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/606Improve ARM DNSSEC Documentation - add DNSSEC GUIDE to appendix2021-01-11T07:32:20ZVicky Riskvicky@isc.orgImprove ARM DNSSEC Documentation - add DNSSEC GUIDE to appendixAnand B did a presentation on his assessment of signing systems for the RIPE 77 mtg n Amsterdam, and he reported that the DNSSEC section of the BIND ARM is out of date, and in particular, it does not mention the DNSSEC-keymgr utility. (t...Anand B did a presentation on his assessment of signing systems for the RIPE 77 mtg n Amsterdam, and he reported that the DNSSEC section of the BIND ARM is out of date, and in particular, it does not mention the DNSSEC-keymgr utility. (that utility is covered in a manpage though).
We should review and spiff up the DNSSEC section.
Anand also commented that the documentation on DNSSEC on the ISC web site was out of date - that is probably the DNSSEC Guide, that we outsourced and haven't been updating. We should discuss whether it would be better to remove it or just mark it as 'somewhat out of date'.
ref: https://ripe77.ripe.net/archives/video/2290/January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/607windows builds are failing for master2018-10-19T08:04:38ZCurtis Blackburnwindows builds are failing for masterRelevant snip of log:
```
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(126): error C2039: 'methods': is not a member of 'isc_appctx' [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-...Relevant snip of log:
```
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(126): error C2039: 'methods': is not a member of 'isc_appctx' [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\include\isc\app.h(106): note: see declaration of 'isc_appctx'
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(126): error C2065: 'appmethods': undeclared identifier [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(126): error C2224: left of '.methods' must have struct/union type [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(256): error C2065: 'ISC_TRUE': undeclared identifier [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(258): error C2065: 'ISC_FALSE': undeclared identifier [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(371): error C2039: 'methods': is not a member of 'isc_appctx' [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\include\isc\app.h(106): note: see declaration of 'isc_appctx'
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(371): error C2065: 'appmethods': undeclared identifier [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(371): error C2224: left of '.methods' must have struct/union type [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\app.c(425): fatal error C1083: Cannot open include file: '../app_api.c': No such file or directory [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\isc\win32\libisc.vcxproj]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/608Add option to apply dns64 rules to address being used for lookups.2023-10-13T07:17:20ZMark AndrewsAdd option to apply dns64 rules to address being used for lookups.This is for a named instance that is behind a IPv6-only link w/o 464XLAT.
DNS lookups to IPv4 addresses need to be mapped to IPv6 lookups using dns64 rules just like any other application that is using NAT64/DNS64 to provide IPv4AAS.This is for a named instance that is behind a IPv6-only link w/o 464XLAT.
DNS lookups to IPv4 addresses need to be mapped to IPv6 lookups using dns64 rules just like any other application that is using NAT64/DNS64 to provide IPv4AAS.November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/609Address memory leak on error2018-10-25T02:13:28ZMark AndrewsAddress memory leak on error```
*** CID 1440371: Resource leaks (RESOURCE_LEAK)
/lib/isc/pool.c: 145 in isc_pool_expand()
139
140 /* Populate the new entries */
141 for (i = pool->count; i < count; i++) {
142 result = pool->init(&newpool->...```
*** CID 1440371: Resource leaks (RESOURCE_LEAK)
/lib/isc/pool.c: 145 in isc_pool_expand()
139
140 /* Populate the new entries */
141 for (i = pool->count; i < count; i++) {
142 result = pool->init(&newpool->pool[i], pool->initarg);
143 if (result != ISC_R_SUCCESS) {
144 isc_pool_destroy(&pool);
CID 1440371: Resource leaks (RESOURCE_LEAK)
Variable "newpool" going out of scope leaks the storage it points to.
145 return (result);
146 }
147 }
148
149 isc_pool_destroy(&pool);
150 pool = newpool;
```
Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/610Address memory leak on error2018-10-24T00:52:00ZMark AndrewsAddress memory leak on error```
*** CID 1440370: Resource leaks (RESOURCE_LEAK)
/lib/dns/dst_api.c: 805 in dst_key_fromgssapi()
799 }
800
801 key->keydata.gssctx = gssctx;
802 *keyp = key;
803 result = ISC_R_SUCCESS;
804 out:
CID 1...```
*** CID 1440370: Resource leaks (RESOURCE_LEAK)
/lib/dns/dst_api.c: 805 in dst_key_fromgssapi()
799 }
800
801 key->keydata.gssctx = gssctx;
802 *keyp = key;
803 result = ISC_R_SUCCESS;
804 out:
CID 1440370: Resource leaks (RESOURCE_LEAK)
Variable "key" going out of scope leaks the storage it points to.
805 return result;
806 }
807
808 isc_result_t
809 dst_key_buildinternal(const dns_name_t *name, unsigned int alg,
810 unsigned int bits, unsigned int flags,
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/612Problems compiling on arm processor2018-10-23T07:46:35ZGhost UserProblems compiling on arm processor### Summary
Compiling on arm processor stops with error message
### BIND version used
Latest version running:
```
$ named -V
BIND 9.13.3-dev (Development Release) <id:760182271e>
running on Linux armv7l 4.14.70-v7+ #1144 S...### Summary
Compiling on arm processor stops with error message
### BIND version used
Latest version running:
```
$ named -V
BIND 9.13.3-dev (Development Release) <id:760182271e>
running on Linux armv7l 4.14.70-v7+ #1144 SMP Tue Sep 18 17:34:46 BST 2018
built by make with '--enable-getifaddrs' '--with-python' '--with-libxml2' '--disable-linux-caps'
compiled by GCC 6.3.0 20170516
compiled with OpenSSL version: OpenSSL 1.1.0f 25 May 2017
linked to OpenSSL version: OpenSSL 1.1.0f 25 May 2017
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with zlib version: 1.2.8
linked to zlib version: 1.2.8
threads support is enabled
```
### Steps to reproduce
Try to compile on arm processor (raspberry pi).
### What is the current *bug* behavior?
Compilations stops with error message:
```
gcc -I.../git/bind9 -I../.. -I./unix/include -I./pthreads/include -I./include -I./include -I.../git/bind9/lib/dns/include -I../../lib/dns/include -I/usr/include -g -O2 -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 -c rwlock.c
/tmp/cc92tnx7.s: Assembler messages:
/tmp/cc92tnx7.s:671: Error: selected processor does not support `yield' in ARM mode
Makefile:273: recipe for target 'rwlock.o' failed
make[2]: *** [rwlock.o] Error 1
make[2]: Leaving directory '.../git/bind9/lib/isc'
Makefile:82: recipe for target 'subdirs' failed
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory '.../git/bind9/lib'
Makefile:89: recipe for target 'subdirs' failed
make: *** [subdirs] Error 1
```
### Possible fixes
My guess is that the following commit introduced or modified isc_rwlock_lock()
```
$ git diff 376bea8b40bbf64954 lib/isc/rwlock.c
diff --git a/lib/isc/rwlock.c b/lib/isc/rwlock.c
index 622cd7d276..91482e6c64 100644
--- a/lib/isc/rwlock.c
+++ b/lib/isc/rwlock.c
@@ -41,6 +41,25 @@
#define RWLOCK_MAX_ADAPTIVE_COUNT 100
#endif
+#if defined(_MSC_VER)
+# include <intrin.h>
+# define isc_rwlock_pause() YieldProcessor()
+#elif defined(__x86_64__) || defined(__i386__)
+# include <immintrin.h>
+# define isc_rwlock_pause() _mm_pause()
+#elif defined(__ia64__)
+# define isc_rwlock_pause() __asm__ __volatile__ ("hint @pause")
+#elif defined(__arm__)
+# define isc_rwlock_pause() __asm__ __volatile__ ("yield")
+#elif defined(__sparc) || defined(__sparc__)
+# define plasma_spin_pause() __asm__ __volatile__ ("pause")
+#elif defined(__ppc__) || defined(_ARCH_PPC) || \
+ defined(_ARCH_PWR) || defined(_ARCH_PWR2) || defined(_POWER)
+# define isc_rwlock_pause() __asm__ volatile ("or 27,27,27")
+#else
+# define isc_rwlock_pause()
+#endif
+
static isc_result_t
isc__rwlock_lock(isc_rwlock_t *rwl, isc_rwlocktype_t type);
@@ -350,9 +369,7 @@ isc_rwlock_lock(isc_rwlock_t *rwl, isc_rwlocktype_t
type) {
result = isc__rwlock_lock(rwl, type);
break;
}
-#ifdef ISC_PLATFORM_BUSYWAITNOP
- ISC_PLATFORM_BUSYWAITNOP;
-#endif
+ isc_rwlock_pause();
} while (isc_rwlock_trylock(rwl, type) != ISC_R_SUCCESS);
```https://gitlab.isc.org/isc-projects/bind9/-/issues/613Add option for min-cache2018-11-14T17:51:35ZOndřej SurýAdd option for min-cacheAt least Debian and Ubuntu carry additional patch to add min-cache-ttl and min-ncache-ttl. It seems like reasonable thing to add.At least Debian and Ubuntu carry additional patch to add min-cache-ttl and min-ncache-ttl. It seems like reasonable thing to add.BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/614Better handling of unrealistic values given to max-cache-size2024-03-01T10:04:57ZCathy AlmondBetter handling of unrealistic values given to max-cache-sizeAs reported to ISC:
> When max-cache-size was set to 2M, and QPS was over 10k, the memory being used by cache couldn't be limited as expected. But if it was set to 50M, then everything looked fine.
This is unsurprising. max-cache-siz...As reported to ISC:
> When max-cache-size was set to 2M, and QPS was over 10k, the memory being used by cache couldn't be limited as expected. But if it was set to 50M, then everything looked fine.
This is unsurprising. max-cache-size being reached is a signal to named that it needs to deploy more 'assertive' cache cleaning methods but nevertheless named may not be able to clean up as quickly as new client queries are causing named to consume more cache memory, simply by handling the recursive activity needed to get the answers to the client.
Client queries will not fail because max-cache-size is exceeded - they will only fail if more memory is requested but isn't available from the host system.
Meanwhile, named will be running around trying to free up cache memory all of the time - and potentially failing to do so because there aren't any/many cache entries not actively being used, which therefore can't be freed yet.
The architecture of the operation of named as a recursive/forwarding server, is that RRs are obtained from other DNS servers, placed into cache, and then the client-facing server code uses those (newly, or previously obtained) cache entries to construct the query response to the client(s).
Therefore at least some cache memory is needed for named to be able to serve recursive clients at all - and the higher the QPS, the more "work in progress" cache space that is needed, even if newly cached entries are being discarded immediately after use.
That's the bare-bones way of looking at it.
A caching server that doesn't cache very much at all is going to have to talk to other DNS servers all the time to get answers for clients - generally this is suboptimal (putting it mildly!) for performance and throughput - although there may be some obscure corner cases where it's desirable to operate like this.
---
Perhaps we should:
1. Set a minimum for max-cache-size
2. Document realistic operational values (and why we recommend those)
3. Document how named manages max-cache-size during operation
4. Have named fail to start if max-cache-size is set too small (as determined by the operational/configured environment)https://gitlab.isc.org/isc-projects/bind9/-/issues/615tcp-clients mostly ineffective2019-04-25T15:43:19ZBrian Conrytcp-clients mostly ineffectiveNote that this is largely a copy/paste from an update on the customer ticket. I didn't feel like trying to explain it again only using slightly different words.
My theory has borne fruit and I have empirically confirmed how it is
that ...Note that this is largely a copy/paste from an update on the customer ticket. I didn't feel like trying to explain it again only using slightly different words.
My theory has borne fruit and I have empirically confirmed how it is
that 'tcp-clients' is mostly ineffective, and also a plausible
explanation for why it hasn't been noticed before now.
I've previously described how 'tcp-clients' is a hard quota, but that
named will go ahead and service a request that is over the quota. This
is the first part of the problem.
After a client's work is completed it is then scrubbed of various bits
of information, detached from the quota if it was attached, and then
returned to the pool of available clients and the accept_list.
Note that the last part happens the same whether the client was counted
in the quota or not.
Further, since there isn't any counting done of clients that are
handling over-quota requests, there's also no way of knowing when they
exist and so whenever a client that was counted is returned the quota
count is decreased.
Thus the situation is:
* the quota only affects the creation of replacement clients for the
accept_list, it does not control the number of clients that can be on
that list.
* the server starts off with the ability to go over quota by 1
* each time the quota count reaches the maximum value it increases the
server's capacity to go over quota by 1 because there is a client
replacement at that point
* each time a client counted in the quota finishes its work the quota
count is decreased. if the quota was at max and there are pending
connections to accept() this will cause the server's over-quota
capacity to immediately increase by 1
In order to verify this I created a patch (attached, note that it is a
superset of the patches provided previously) that adds a second TCP
quota, but this one is configured differently.
The original tcpquota is configured to be "hard". This means that it
has a max that cannot be exceeded.
The new one is configured to be "soft" with no absolute max but a soft
limit that is kept in synch with the regular quota's max. This soft
limit doesn't prevent new clients from being counted, but I do use it in
logging.
I added client logging in two places. The first is immediately after
the isc_quota_attach in client_newconn and the other is immediately
before the isc_quota_detach in exit_check (also in client.c).
The logging statement in client_newconn also includes the text
translation of the result code from the isc_quota_attach called on the
original (hard) quota.
The logging statement in exit_check also includes whether or not the
client is attached (i.e. counted) in the "hard" quota.
Both statements include the "used" and "max" from the hard quota and the
"used" and "soft" from the soft quota (should be the same as the hard
quota max).
I found that the best way to test and demonstrate this was with a script
that maintained a set number of outstanding connections - this allowed
me to throttle it so that I didn't exhaust resources while also
maintaining the pressure to make the server bounce against the limit
imposed by 'tcp-clients' as often as possible. The script is attached
as mkload.pl - all 37 lines of it.
It seems that the rate of growth in uncounted clients is related to the
'tcp-clients' setting (more is faster) and that the upper limit is
likely to be the lower of what can get through the network and the
number of available file descriptors.https://gitlab.isc.org/isc-projects/bind9/-/issues/616Internet Explorer Issues After GitLab Update2018-10-23T17:23:14ZThomas JachInternet Explorer Issues After GitLab UpdateAfter the latest GitLab update, Internet Explorer can no longer be used to view comments and other items on the BIND project site. Apparently, almost any JavaScript-based feature is broken.After the latest GitLab update, Internet Explorer can no longer be used to view comments and other items on the BIND project site. Apparently, almost any JavaScript-based feature is broken.https://gitlab.isc.org/isc-projects/bind9/-/issues/617If RRL is configured the "require-server-cookie yes;" is ignored.2018-11-05T23:18:38ZMichael McNallyIf RRL is configured the "require-server-cookie yes;" is ignored.David Beck of Men and Mice reported the following via e-mail to security-officer:
### Summary
If RRL is configured the "require-server-cookie yes;" is ignored.
### BIND Version used
```
% named -V
BIND 9.12.2 <id:3631aeb>
running on Li...David Beck of Men and Mice reported the following via e-mail to security-officer:
### Summary
If RRL is configured the "require-server-cookie yes;" is ignored.
### BIND Version used
```
% named -V
BIND 9.12.2 <id:3631aeb>
running on Linux x86_64 4.11.12-100.fc24.x86_64 #1 SMP Fri Jul 21 17:35:20 UTC 2017
built by make with '--sysconfdir=/etc/namedb'
compiled by GCC 8.2.0
compiled with OpenSSL version: OpenSSL 1.1.0h 27 Mar 2018
linked to OpenSSL version: OpenSSL 1.1.0h 27 Mar 2018
threads support is enabled
```
### Steps to reproduce
1. Use this very reduced configuration:
```
options {
directory "/etc/namedb"; require-server-cookie yes; rate-limit {};
};
zone "zoneXX.dnslab.org" { type master; file "zoneXX.dnslab.org"; };
```
Note that the empty rate-limit {} stanza with only defaults isn't the issue. I originally had responses-per-second, ipv4-prefix-length, and slip statements. I removed them one-by-one get to the core of the problem.
3. Have a valid zone file: zoneXX.dnslab.org
4. Start named
5. Query:
```
dig +norec @::1 zonexx.dnslab.org soa +nobadcookie
```
The response is NOERROR with the SOA being properly returned in the ANSWER section.
This is the bug. The response code should be BADCOOKIE.
### What is the expected *correct* behavior?
1. Remove or comment out: rate-limit {};
2. Load the new configuration.
3. Repeat the same query as above.
The response will be BADCOOKIE, which is correct.
### Relevant configuration files
See above.
### Relevant logs and/or screenshots
Running 'named -g' I saw nothing of use in the logs.
### Possible fixes
No idea.https://gitlab.isc.org/isc-projects/bind9/-/issues/618Review all system tests that disable qname minimization2018-10-25T08:33:08ZWitold KrecickiReview all system tests that disable qname minimizationSome tests need qname minimization to be disabled to work, those need to be reviewed and fixed.Some tests need qname minimization to be disabled to work, those need to be reviewed and fixed.https://gitlab.isc.org/isc-projects/bind9/-/issues/619Implement ATMA2018-10-25T05:40:18ZMark AndrewsImplement ATMAThe specification for ATMA is now available.
http://www.broadband-forum.org/ftp/pub/approved-specs/af-dans-0152.000.pdfThe specification for ATMA is now available.
http://www.broadband-forum.org/ftp/pub/approved-specs/af-dans-0152.000.pdfMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/620CMOCKA conversions2018-11-15T05:19:01ZEvan HuntCMOCKA conversionsConversion of existing ATF unit tests to CMOCKA framework.Conversion of existing ATF unit tests to CMOCKA framework.BIND-9.13.4Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/621Fix unit and system tests when run on FIPS enabled system2021-06-17T09:41:19ZOndřej SurýFix unit and system tests when run on FIPS enabled systemAs we now detect the algorithm support in the runtime, the `PK11_MD5_DISABLE` was removed, and the unit and system tests needs to be modified to detect enabled FIPS mode and act accordingly.As we now detect the algorithm support in the runtime, the `PK11_MD5_DISABLE` was removed, and the unit and system tests needs to be modified to detect enabled FIPS mode and act accordingly.BIND 9.17 BackburnerOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/622BIND should accept trust anchors / keys in DS format too, not just DNSKEY2021-05-11T13:17:24ZRay BellisBIND should accept trust anchors / keys in DS format too, not just DNSKEYper title.
This would simplify use for those registries that would prefer to only receive DS records from their delegated children.
Also, the ICANN root trust anchor is mostly only distributed in DS format.per title.
This would simplify use for those registries that would prefer to only receive DS records from their delegated children.
Also, the ICANN root trust anchor is mostly only distributed in DS format.BIND 9.15.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/623RPZ logging to include QCLASS and QTYPE2019-02-01T01:50:49ZGhost UserRPZ logging to include QCLASS and QTYPE### Description
RPZ logging does not log QCLASS or QTYPE, whereas query logging does.
This information is very useful for analysis of rpz behaviour.
### Request
The additional fields qclass and qtype at the end of the log file - e.g.
...### Description
RPZ logging does not log QCLASS or QTYPE, whereas query logging does.
This information is very useful for analysis of rpz behaviour.
### Request
The additional fields qclass and qtype at the end of the log file - e.g.
instead of
24-Oct-2018 17:54:52.032 rpz: info: client @0x7f990085b070 213.248.248.83#38933 (www.example.net): rpz QNAME Local-Data rewrite www.example.net via www.example.net.rpz101.example.com
24-Oct-2018 18:02:56.143 rpz: info: client @0x7f310884c1b0 213.248.248.83#52403 (www.example.net): rpz QNAME Local-Data rewrite www.example.net via www.example.net.rpz101.example.com **IN A**
I have attached a potential patch idea - but it doesn't handle IP range entries.
### Links / references
[]([0001-Addition-of-QCLASS-and-QTYPE-to-rpz-logging-as-for-q.patch](/uploads/79a2c08e74280fb3bad82802d1d6e864/0001-Addition-of-QCLASS-and-QTYPE-to-rpz-logging-as-for-q.patch))BIND 9.11.6Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/624lib/dns/dnstap_test:totext does not work well with SoftHSM PKCS112018-10-29T05:25:06ZPetr Menšíklib/dns/dnstap_test:totext does not work well with SoftHSM PKCS11<!--
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
dnstap unit test is failing in pkcs11 variant
### BIND version used
9.11.5
### Steps to reproduce
- ./configure --with-pkcs11 --with-native-pkcs11 --enable-dnstap --with-atf
- make -j4
- cd lib/dns/tests
- export TZ="CET"
- kyua debug dnstap_test:totext
### What is the current *bug* behavior?
Time read from dnstap does not match, because I have different timezone. It produces 96 fails. That is because in case of PKCS11 variant, SoftHSM uses localtime_r at initialization. Normal version is first initialized on the first line.
### What is the expected *correct* behavior?
Environment variable is set before initialization of dns library. Makes no difference.
### Relevant configuration files
none
### Relevant logs and/or screenshots
# from gdb
break localtime_r
backtrace
```
#0 __localtime_r (t=t@entry=0x7fffffffad58, tp=tp@entry=0x7fffffffad70) at localtime.c:29
#1 0x00007ffff48a65d0 in __GI___vsyslog_chk (pri=<optimized out>, flag=1, fmt=0x7ffff3ab87ea "%s%s",
ap=ap@entry=0x7fffffffae50) at ../misc/syslog.c:199
#2 0x00007ffff48a6bcf in __syslog_chk (pri=pri@entry=3, flag=flag@entry=1, fmt=fmt@entry=0x7ffff3ab87ea "%s%s")
at ../misc/syslog.c:129
#3 0x00007ffff3a80988 in syslog (__fmt=0x7ffff3ab87ea "%s%s", __pri=3) at /usr/include/bits/syslog.h:31
#4 softHSMLog (loglevel=loglevel@entry=3,
functionName=functionName@entry=0x7ffff3abb3d7 <File::File(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, bool, bool, bool)::__func__> "File", fileName=fileName@entry=0x7ffff3abbc0e "File.cpp",
lineNo=lineNo@entry=93, format=format@entry=0x7ffff3abb368 "Could not open the file (%s): %s") at log.cpp:102
#5 0x00007ffff3aa343f in File::File (this=0x7fffffffb340, inPath=..., forRead=<optimized out>,
forWrite=<optimized out>, create=<optimized out>, truncate=<optimized out>) at File.cpp:93
#6 0x00007ffff3aa4ed0 in Generation::commit (this=this@entry=0x5555557942b0) at Generation.cpp:144
#7 0x00007ffff3aa5096 in Generation::Generation (this=0x5555557942b0, inPath=..., inIsToken=<optimized out>)
at Generation.cpp:248
#8 0x00007ffff3aa5114 in Generation::create (
path="/var/lib/softhsm/tokens//fd04e9e9-bd75-2da1-0e70-82540070b451/generation", isToken=isToken@entry=true)
at Generation.cpp:40
#9 0x00007ffff3aa8b9b in OSToken::OSToken (this=0x55555575c560, inTokenPath=...) at OSToken.cpp:59
#10 0x00007ffff3aaa38f in OSToken::accessToken (basePath=..., tokenDir=...) at OSToken.cpp:134
#11 0x00007ffff3aa107f in ObjectStore::ObjectStore (this=0x55555575c6c0, inStorePath=...) at ObjectStore.cpp:70
#12 0x00007ffff3a5a9f5 in SoftHSM::C_Initialize (this=0x55555575d610, pInitArgs=<optimized out>) at SoftHSM.cpp:496
#13 0x00007ffff3a42034 in C_Initialize (pInitArgs=0x7ffff799b1e0 <pk11_init_args>) at main.cpp:133
#14 0x00007ffff7735474 in pk11_initialize (mctx=mctx@entry=0x55555575e710, engine=engine@entry=0x0)
at ../../../lib/isc-pkcs11/pk11.c:209
#15 0x00007ffff7b50022 in dst_lib_init2 (mctx=0x55555575e710, ectx=0x7ffff7f77010, engine=engine@entry=0x0,
eflags=eflags@entry=4) at ../../../lib/dns-pkcs11/dst_api.c:199
#16 0x00007ffff7b50219 in dst_lib_init (mctx=<optimized out>, ectx=<optimized out>, eflags=eflags@entry=4)
at ../../../lib/dns-pkcs11/dst_api.c:149
#17 0x00005555555583f2 in dns_test_begin (logfile=0x0, start_managers=<optimized out>)
at ../../../../lib/dns-pkcs11/tests/dnstest.c:125
#18 0x0000555555556f92 in atfu_totext_body (tc=<optimized out>) at ../../../../lib/dns-pkcs11/tests/dnstap_test.c:300
#19 0x00007ffff4ec0c69 in atf_tc_run (tc=0x55555575b0c0 <atfu_totext_tc>, resfile=<optimized out>) at atf-c/tc.c:1012
#20 0x00007ffff4ec1a55 in atf_tp_run (tp=tp@entry=0x7fffffffdac0, tcname=<optimized out>, resfile=<optimized out>)
at atf-c/tp.c:205
#21 0x00007ffff4ec68e4 in run_tc (exitcode=<synthetic pointer>, p=0x7fffffffdae0, tp=0x7fffffffdac0)
at atf-c/detail/tp_main.c:509
#22 controlled_main (exitcode=<synthetic pointer>, add_tcs_hook=0x5555555576c0 <atfu_tp_add_tcs>, argv=<optimized out>,
argc=<optimized out>) at atf-c/detail/tp_main.c:579
---Type <return> to continue, or q <return> to quit---
#23 atf_tp_main (argc=<optimized out>, argv=<optimized out>, add_tcs_hook=0x5555555576c0 <atfu_tp_add_tcs>)
at atf-c/detail/tp_main.c:609
#24 0x00007ffff47d7fea in __libc_start_main (main=0x555555556e30 <main>, argc=2, argv=0x7fffffffdc68,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdc58)
at ../csu/libc-start.c:308
```
```
$ kyua debug dnstap_test:totext
*** Check failed: ../../../../lib/dns-pkcs11/tests/dnstap_test.c:346: (char *) isc_buffer_base(b) != s (03-Feb-2017 23:47:16.000 SQ 10.53.0.1:2112 -> 10.53.0.2:2112 UDP 40b www.isc.org/IN/A != 03-Feb-2017 15:47:16.000 SQ 10.53.0.1:2112 -> 10.53.0.2:2112 UDP 40b www.isc.org/IN/A)
*** Check failed: ../../../../lib/dns-pkcs11/tests/dnstap_test.c:346: (char *) isc_buffer_base(b) != s (04-Feb-2017 00:47:16.830 SQ 10.53.0.1:2112 -> 10.53.0.2:2112 UDP 40b www.isc.org/IN/A != 03-Feb-2017 16:47:16.830 SQ 10.53.0.1:2112 -> 10.53.0.2:2112 UDP 40b www.isc.org/IN/A)
...
*** Check failed: ../../../../lib/dns-pkcs11/tests/dnstap_test.c:346: (char *) isc_buffer_base(b) != s (04-Feb-2017 01:47:16.000 TR 10.53.0.1:2112 <- 10.53.0.2:2112 TCP 287b www.isc.org/IN/A != 03-Feb-2017 17:47:16.000 TR 10.53.0.1:2112 <- 10.53.0.2:2112 TCP 287b www.isc.org/IN/A)
*** Check failed: ../../../../lib/dns-pkcs11/tests/dnstap_test.c:346: (char *) isc_buffer_base(b) != s (04-Feb-2017 00:47:16.830 TR 10.53.0.1:2112 <- 10.53.0.2:2112 TCP 287b www.isc.org/IN/A != 03-Feb-2017 16:47:16.830 TR 10.53.0.1:2112 <- 10.53.0.2:2112 TCP 287b www.isc.org/IN/A)
*** Check failed: ../../../../lib/dns-pkcs11/tests/dnstap_test.c:346: (char *) isc_buffer_base(b) != s (04-Feb-2017 00:47:16.830 TR 10.53.0.1:2112 <- 10.53.0.2:2112 TCP 287b www.isc.org/IN/A != 03-Feb-2017 16:47:16.830 TR 10.53.0.1:2112 <- 10.53.0.2:2112 TCP 287b www.isc.org/IN/A)
dnstap_test:totext -> failed: 96 checks failed; see output for more details
```
### Possible fixes
Setenv [is called](https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/dns/tests/dnstap_test.c#L310) too late.https://gitlab.isc.org/isc-projects/bind9/-/issues/625dnssec-coverage complains about issues in the past2021-10-04T13:27:22ZOndřej Surýdnssec-coverage complains about issues in the pastReported by Peter Palfrader in Debian:
We regularly rotate our ZSKs, and just recently we started removing old
.key files from our keydir.
The oldest remaining ZSK now has a published date in the past, and an
activation date also in th...Reported by Peter Palfrader in Debian:
We regularly rotate our ZSKs, and just recently we started removing old
.key files from our keydir.
The oldest remaining ZSK now has a published date in the past, and an
activation date also in the past but after the publish date.
(Previously, the oldest ZSK was the *first* ZSK, and it had publish
and activate at the same time.)
dnssec-coverage complains about this:
```
| Checking scheduled ZSK events for zone debian.nl, algorithm RSASHA256...
| Wed Jul 11 12:07:03 UTC 2018:
| Publish: debian.nl/008/17304 (ZSK)
| ERROR: No ZSK's are active after this event
for
; This is a zone-signing key, keyid 17304, for debian.nl.
; Created: 20180211121307 (Sun Feb 11 12:13:07 2018)
; Publish: 20180711120703 (Wed Jul 11 12:07:03 2018)
; Activate: 20180810120703 (Fri Aug 10 12:07:03 2018)
; Inactive: 20181208120703 (Sat Dec 8 12:07:03 2018)
; Delete: 20190107120703 (Mon Jan 7 12:07:03 2019)
[..key..]
; This is a zone-signing key, keyid 29616, for debian.nl.
; Created: 20180612045523 (Tue Jun 12 04:55:23 2018)
; Publish: 20181108120703 (Thu Nov 8 12:07:03 2018)
; Activate: 20181208120703 (Sat Dec 8 12:07:03 2018)
; Inactive: 20190407120703 (Sun Apr 7 12:07:03 2019)
; Delete: 20190507120703 (Tue May 7 12:07:03 2019)
[..key..]
; This is a zone-signing key, keyid 37155, for debian.nl.
; Created: 20181009121102 (Tue Oct 9 12:11:02 2018)
; Publish: 20190308120703 (Fri Mar 8 12:07:03 2019)
; Activate: 20190407120703 (Sun Apr 7 12:07:03 2019)
; Inactive: 20190805120703 (Mon Aug 5 12:07:03 2019)
; Delete: 20190904120703 (Wed Sep 4 12:07:03 2019)
[..key..]
```
I propose dnssec-coverage ignore cases of no
active/publish/active&published that happened in the past.
```
--- /usr/sbin/dnssec-coverage 2018-01-15 21:40:17.000000000 +0000
+++ /srv/dns.debian.org/bin/dnssec-coverage 2018-10-24 18:24:01.216562896 +0000
@@ -15,6 +15,10 @@
# PERFORMANCE OF THIS SOFTWARE.
############################################################################
+# changes 2018-10-24, Peter Palfrader
+# - ignore "errors" in the past (like no active keys)
+# as that can result from retiring old (and deleted) keyfiles
+
import argparse
import os
import glob
@@ -23,6 +27,7 @@
import time
import calendar
from collections import defaultdict
+from itertools import zip_longest
import pprint
prog='dnssec-coverage'
@@ -531,7 +536,7 @@
if eventgroup:
eventgroups.append(eventgroup)
- for eventgroup in eventgroups:
+ for eventgroup, next_eventgroup in zip_longest(eventgroups, eventgroups[1:]):
if (args.checklimit and
calendar.timegm(eventgroup[0].when) > args.checklimit):
print("Ignoring events after %s" %
@@ -545,18 +550,19 @@
list_events(eventgroup)
# and then check for inconsistencies:
+
+ # but do not bail out on inconsistencies in the past that may be the result of keys that got retired
+ bygones = next_eventgroup is not None and calendar.timegm(next_eventgroup[0].when) < time.time()
if len(active) == 0:
- print ("ERROR: No %s's are active after this event" % keytype)
- return False
+ print ("%s: No %s's are active after this event" %(['ERROR', 'INFO'][bygones], keytype))
+ if not bygones: return False
elif len(published) == 0:
- sys.stdout.write("ERROR: ")
- print ("ERROR: No %s's are published after this event" % keytype)
- return False
+ print ("%s: No %s's are published after this event" % (['ERROR', 'INFO'][bygones], keytype))
+ if not bygones: return False
elif len(published.intersection(active)) == 0:
- sys.stdout.write("ERROR: ")
- print (("ERROR: No %s's are both active and published " +
- "after this event") % keytype)
- return False
+ print (("%s: No %s's are both active and published " +
+ "after this event") % (['ERROR', 'INFO'][bygones], keytype))
+ if not bygones: return False
if not eventsfound:
print ("ERROR: No %s events found in '%s'" %
```
To reproduce:
```
mkdir example.com
cd example.com
faketime -f '-1y' /usr/sbin/dnssec-keygen -f KSK -K . -a RSASHA256 -3 -b 2048 example.com
key=$(faketime -f '-1y' /usr/sbin/dnssec-keygen -K . -a RSASHA256 -3 -b 1024 -I +120d -D +150d example.com)
first=$key
lt=120
for i in `seq 1 5`; do
lt=$((lt + 120))
key=$(faketime -f '-1y' /usr/sbin/dnssec-keygen -K . -S "$key.key" -I +${lt}d -D +$((lt+30))d example.com)
done
/usr/sbin/dnssec-coverage -K . -l 200d -c /usr/sbin/named-compilezone example.com
rm $first.key $first.private
/usr/sbin/dnssec-coverage -K . -l 200d -c /usr/sbin/named-compilezone example.com
```Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/626Implement EID and NIMLOC2018-10-25T22:29:30ZMark AndrewsImplement EID and NIMLOChttps://gitlab.isc.org/isc-projects/bind9/-/issues/627Check that GID, UID and UINFO can be loaded using unknown record format.2018-10-25T20:34:10ZMark AndrewsCheck that GID, UID and UINFO can be loaded using unknown record format.