BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2018-09-27T02:46:55Zhttps://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 Krecicki