ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2018-04-10T22:17:16Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/183Add dns_fixedname_initname()2018-04-10T22:17:16ZGhost UserAdd dns_fixedname_initname()The following pattern is repeated in many places in BIND code:
```c
dns_fixedname_t fixed;
dns_name_t *name;
dns_fixedname_init(&fixed);
name = dns_fixedname_name(&name);
```
Let's add a helper function that does the equivalent:
```c...The following pattern is repeated in many places in BIND code:
```c
dns_fixedname_t fixed;
dns_name_t *name;
dns_fixedname_init(&fixed);
name = dns_fixedname_name(&name);
```
Let's add a helper function that does the equivalent:
```c
dns_fixedname_t fixed;
dns_name_t *name;
name = dns_fixedname_initname(&fixed);
```
Implementation would be:
```c
dns_name_t *
dns_fixedname_initname(dns_fixedname_t *fixed) {
dns_fixedname_init(fixed);
return (dns_fixedname_name(fixed));
}
```https://gitlab.isc.org/isc-projects/bind9/-/issues/184Lock bucket mapping is broken in rbtdb.c when DNS_RBT_USEHASH is not defined2018-05-25T16:29:57ZGhost UserLock bucket mapping is broken in rbtdb.c when DNS_RBT_USEHASH is not definedLock bucket mapping is broken in `rbtdb.c` when `DNS_RBT_USEHASH` is not defined. It does case-sensitive hash computation in error, and so "Foo" and "foo" names map to different locks.Lock bucket mapping is broken in `rbtdb.c` when `DNS_RBT_USEHASH` is not defined. It does case-sensitive hash computation in error, and so "Foo" and "foo" names map to different locks.https://gitlab.isc.org/isc-projects/bind9/-/issues/185[CVE-2018-5737] serve-stale crash2021-03-31T12:02:44ZTony Finch[CVE-2018-5737] serve-stale crashOne of my recursive servers crashed messily this evening, logging more than a million lines of
```
27-Mar-2018 18:20:35.862 general: info: 105.91.84.115.in-addr.arpa resolver failure, stale answer used
[snip 100MB logs]
27-Mar-2018...One of my recursive servers crashed messily this evening, logging more than a million lines of
```
27-Mar-2018 18:20:35.862 general: info: 105.91.84.115.in-addr.arpa resolver failure, stale answer used
[snip 100MB logs]
27-Mar-2018 18:24:03.414 general: info: 105.91.84.115.in-addr.arpa resolver failure, stale answer used
27-Mar-2018 18:24:03.414 general: critical: rbtdb.c:2115: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed
27-Mar-2018 18:24:03.414 general: critical: exiting (due to assertion failure)
```
Earlier today I turned on serve-stale in production, so it did not last long before crashing!
I'm afraid I don't have the start of the logspam because I only keep 100MB logs, but the obvious query will reproduce the problem.
Tangentially related, I think the serve-stale logging needs work: it's very noisy, so it should be in its own category, and perhaps some of the messages should have at debugging rather than informational level...
Full configuration below. It's possibly of note that I have two views with a shared cache using attach-cache.
```
acl "blackhole" {
240.0.0.0/4;
};
acl "secure" {
"localhost";
131.111.56.56/32;
131.111.57.57/32;
2001:630:212:110::d:7a7/128;
2001:630:212:110:221:9bff:fe16:a526/128;
2001:630:212:110:646f:7461:742e:6174/128;
131.111.9.53/32;
131.111.9.73/32;
2001:630:212:8::d:aa/128;
2001:630:212:8::d:aaaa/128;
};
acl "loopback" {
127.0.0.0/8;
::1/128;
};
acl "cudn" {
127.0.0.0/8;
::1/128;
2001:630:210::/44;
2a00:1098:5::/48;
128.232.0.0/16;
129.169.0.0/16;
131.111.0.0/16;
192.18.195.0/24;
192.84.5.0/24;
192.153.213.0/24;
193.60.80.0/20;
193.63.252.0/23;
!172.31.0.0/16;
172.16.0.0/12;
10.128.0.0/9;
};
acl "isc" {
"ipreg";
key "university_of_cambridge-a1ec5f18.sns-pba.isc.org";
};
acl "secondaries" {
"cudn";
"isc";
key "tsig-cam-maths";
key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
194.81.227.226/32;
2001:630:0:44::e2/128;
193.63.105.17/32;
2001:630:0:45::11/128;
193.63.106.103/32;
2001:630:0:46::67/128;
193.62.157.66/32;
2001:630:0:47::42/128;
93.93.130.49/32;
69.56.173.190/32;
2600:3c00::f03c:91ff:fe96:beac/128;
93.93.128.67/32;
2a00:1098:0:80:1000::10/128;
185.24.221.32/32;
2a02:2770:11:0:21a:4aff:febe:759b/128;
};
acl "ipreg" {
key "tsig-ipreg";
"secure";
};
controls {
inet 0.0.0.0 port 953 allow {
"secure";
};
inet :: port 953 allow {
"secure";
};
};
logging {
channel "log" {
file "../log/named.log" versions 10 size 10485760;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"log";
};
category "cname" {
"default_debug";
};
category "dnssec" {
"default_debug";
};
category "lame-servers" {
"default_debug";
};
category "query-errors" {
"default_debug";
};
category "resolver" {
"default_debug";
};
category "security" {
"default_debug";
};
category "update-security" {
"default_debug";
};
};
masters "notify-isc" {
149.20.67.14 key "university_of_cambridge-a1ec5f18.sns-pba.isc.org";
199.6.0.100 key "university_of_cambridge-a1ec5f18.sns-pba.isc.org";
};
masters "notify-auth" {
2001:630:212:8::d:a0 key "tsig-ipreg";
2001:630:212:12::d:a1 key "tsig-ipreg";
2001:630:212:8::d:a2 key "tsig-ipreg";
2001:630:212:12::d:a3 key "tsig-ipreg";
};
masters "notify-rec" {
"notify-auth";
2001:630:212:8::d:92 key "tsig-ipreg";
2001:630:212:8::d:93 key "tsig-ipreg";
2001:630:212:8::d:94 key "tsig-ipreg";
2001:630:212:8::d:95 key "tsig-ipreg";
};
masters "master-ipreg" {
2001:630:212:8::d:aa key "tsig-ipreg";
};
masters "master-fanf" {
2001:630:212:110::d:7a7 key "tsig-fanf";
2001:630:212:110:646f:7461:742e:6174 key "tsig-fanf";
};
masters "master-cl" {
2001:630:212:200::d:a0;
128.232.0.19;
2001:630:212:200::d:a1;
128.232.0.18;
};
masters "master-eng" {
129.169.8.8;
129.169.8.9;
};
masters "master-maths" {
131.111.16.129;
131.111.16.30;
131.111.16.32;
};
masters "master-janet-rpz" {
2001:630:1:128::166;
194.82.174.166;
2001:630:1:12a::235;
194.83.56.235;
};
masters "master-imperial" {
2001:630:12:600:1::80 key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
2001:630:12:600:1::81 key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
2001:630:12:600:1::82 key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
195.97.216.196 key "cam.ac.uk.feb2016.tsig.ic.ac.uk";
};
masters "master-salford" {
146.87.136.156;
146.87.136.157;
};
masters "master-york" {
144.32.129.200;
144.32.128.230;
};
masters "master-sanger" {
193.62.203.30;
};
masters "master-chiark" {
212.13.197.229;
};
masters "master-srcf" {
131.111.179.79;
};
masters "master-exim" {
2001:630:212:8::e:f0e key "tsig-cam-exim";
131.111.8.88 key "tsig-cam-exim";
2a02:898:31::53:0 key "tsig-cam-exim";
94.142.241.91 key "tsig-cam-exim";
2604:a880:800:a1::419:1001 key "tsig-cam-exim";
159.203.114.39 key "tsig-cam-exim";
};
options {
blackhole {
"blackhole";
};
directory "/home/named/run";
recursive-clients 12345;
server-id hostname;
tcp-clients 1234;
dnssec-validation auto;
max-cache-size 17179869184;
max-stale-ttl 3600;
no-case-compress {
"any";
};
rrset-order {
order random;
};
stale-answer-enable yes;
allow-query {
"cudn";
};
notify no;
zone-statistics full;
};
statistics-channels {
inet 0.0.0.0 port 8053 allow {
"cudn";
};
inet :: port 8053 allow {
"cudn";
};
};
view "main" {
match-destinations {
!131.111.9.99/32;
!2001:630:212:8::d:2/128;
!131.111.12.99/32;
!2001:630:212:12::d:3/128;
!131.111.9.118/32;
!2001:630:212:8::d:fff2/128;
!131.111.12.118/32;
!2001:630:212:12::d:fff3/128;
"any";
};
zone "1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "../zone/1.2.0.0.3.6.0.1.0.0.2.ip6.arpa";
masters {
"master-ipreg";
};
};
zone "10.in-addr.arpa" {
type slave;
file "../zone/10.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "111.131.in-addr.arpa" {
type slave;
file "../zone/111.131.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "145.111.131.in-addr.arpa" {
type slave;
file "../zone/145.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "16.111.131.in-addr.arpa" {
type slave;
file "../zone/16.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "16.172.in-addr.arpa" {
type slave;
file "../zone/16.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "169.129.in-addr.arpa" {
type slave;
file "../zone/169.129.in-addr.arpa";
masters {
"master-eng";
};
};
zone "17.111.131.in-addr.arpa" {
type slave;
file "../zone/17.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "17.172.in-addr.arpa" {
type slave;
file "../zone/17.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "18.111.131.in-addr.arpa" {
type slave;
file "../zone/18.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "18.172.in-addr.arpa" {
type slave;
file "../zone/18.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "19.172.in-addr.arpa" {
type slave;
file "../zone/19.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "195.18.192.in-addr.arpa" {
type slave;
file "../zone/195.18.192.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" {
type slave;
file "../zone/2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa";
masters {
"master-cl";
};
};
zone "20.111.131.in-addr.arpa" {
type slave;
file "../zone/20.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "20.172.in-addr.arpa" {
type slave;
file "../zone/20.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "21.172.in-addr.arpa" {
type slave;
file "../zone/21.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "213.153.192.in-addr.arpa" {
type slave;
file "../zone/213.153.192.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "22.172.in-addr.arpa" {
type slave;
file "../zone/22.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "23.172.in-addr.arpa" {
type slave;
file "../zone/23.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "232.128.in-addr.arpa" {
type slave;
file "../zone/232.128.in-addr.arpa";
masters {
"master-cl";
};
};
zone "24.111.131.in-addr.arpa" {
type slave;
file "../zone/24.111.131.in-addr.arpa";
masters {
"master-maths";
};
};
zone "24.172.in-addr.arpa" {
type slave;
file "../zone/24.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "25.172.in-addr.arpa" {
type slave;
file "../zone/25.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "252.63.193.in-addr.arpa" {
type slave;
file "../zone/252.63.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "253.63.193.in-addr.arpa" {
type slave;
file "../zone/253.63.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "26.172.in-addr.arpa" {
type slave;
file "../zone/26.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "27.172.in-addr.arpa" {
type slave;
file "../zone/27.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "28.172.in-addr.arpa" {
type slave;
file "../zone/28.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "29.172.in-addr.arpa" {
type slave;
file "../zone/29.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "30.172.in-addr.arpa" {
type slave;
file "../zone/30.172.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "5.0.0.0.8.9.0.1.0.0.a.2.ip6.arpa" {
type slave;
file "../zone/5.0.0.0.8.9.0.1.0.0.a.2.ip6.arpa";
masters {
"master-ipreg";
};
};
zone "5.84.192.in-addr.arpa" {
type slave;
file "../zone/5.84.192.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "80.60.193.in-addr.arpa" {
type slave;
file "../zone/80.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "81.60.193.in-addr.arpa" {
type slave;
file "../zone/81.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "82.60.193.in-addr.arpa" {
type slave;
file "../zone/82.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "83.60.193.in-addr.arpa" {
type slave;
file "../zone/83.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "84.60.193.in-addr.arpa" {
type slave;
file "../zone/84.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "85.60.193.in-addr.arpa" {
type slave;
file "../zone/85.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "86.60.193.in-addr.arpa" {
type slave;
file "../zone/86.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "87.60.193.in-addr.arpa" {
type slave;
file "../zone/87.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "88.60.193.in-addr.arpa" {
type slave;
file "../zone/88.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "89.60.193.in-addr.arpa" {
type slave;
file "../zone/89.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "90.60.193.in-addr.arpa" {
type slave;
file "../zone/90.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "91.60.193.in-addr.arpa" {
type slave;
file "../zone/91.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "92.60.193.in-addr.arpa" {
type slave;
file "../zone/92.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "93.60.193.in-addr.arpa" {
type slave;
file "../zone/93.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "94.60.193.in-addr.arpa" {
type slave;
file "../zone/94.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "95.60.193.in-addr.arpa" {
type slave;
file "../zone/95.60.193.in-addr.arpa";
masters {
"master-ipreg";
};
};
zone "block.arpa.cam.ac.uk" {
type slave;
file "../zone/block.arpa.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "botnetcc.rpz.spamhaus.org" {
type slave;
file "../zone/botnetcc.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "cam.ac.uk" {
type slave;
file "../zone/cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "cl.cam.ac.uk" {
type slave;
file "../zone/cl.cam.ac.uk";
masters {
"master-cl";
};
};
zone "cst.cam.ac.uk" {
type slave;
file "../zone/cst.cam.ac.uk";
masters {
"master-cl";
};
};
zone "damtp.cam.ac.uk" {
type slave;
file "../zone/damtp.cam.ac.uk";
masters {
"master-maths";
};
};
zone "dbl.rpz.spamhaus.org" {
type slave;
file "../zone/dbl.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "dpmms.cam.ac.uk" {
type slave;
file "../zone/dpmms.cam.ac.uk";
masters {
"master-maths";
};
};
zone "drop.rpz.spamhaus.org" {
type slave;
file "../zone/drop.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "eng.cam.ac.uk" {
type slave;
file "../zone/eng.cam.ac.uk";
masters {
"master-eng";
};
};
zone "in-addr.arpa.cam.ac.uk" {
type slave;
file "../zone/in-addr.arpa.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "in-addr.arpa.private.cam.ac.uk" {
type slave;
file "../zone/in-addr.arpa.private.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "malware-aggressive.rpz.spamhaus.org" {
type slave;
file "../zone/malware-aggressive.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "malware.rpz.spamhaus.org" {
type slave;
file "../zone/malware.rpz.spamhaus.org";
masters {
"master-janet-rpz";
};
};
zone "maths.cam.ac.uk" {
type slave;
file "../zone/maths.cam.ac.uk";
masters {
"master-maths";
};
};
zone "newton.cam.ac.uk" {
type slave;
file "../zone/newton.cam.ac.uk";
masters {
"master-maths";
};
};
zone "passthru.arpa.cam.ac.uk" {
type slave;
file "../zone/passthru.arpa.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "private.cam.ac.uk" {
type slave;
file "../zone/private.cam.ac.uk";
masters {
"master-ipreg";
};
};
zone "srcf.net" {
type slave;
file "../zone/srcf.net";
masters {
"master-srcf";
};
};
zone "srcf.ucam.org" {
type slave;
file "../zone/srcf.ucam.org";
masters {
"master-srcf";
};
};
zone "statslab.cam.ac.uk" {
type slave;
file "../zone/statslab.cam.ac.uk";
masters {
"master-maths";
};
};
zone "ucam.org" {
type slave;
file "../zone/ucam.org";
masters {
"master-chiark";
};
};
response-policy {
zone "passthru.arpa.cam.ac.uk" policy passthru;
zone "block.arpa.cam.ac.uk" policy cname "block.dns.cam.ac.uk";
} break-dnssec yes max-policy-ttl 300 qname-wait-recurse no;
};
view "unfiltered" {
zone "1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" {
in-view "main";
};
zone "10.in-addr.arpa" {
in-view "main";
};
zone "111.131.in-addr.arpa" {
in-view "main";
};
zone "145.111.131.in-addr.arpa" {
in-view "main";
};
zone "16.111.131.in-addr.arpa" {
in-view "main";
};
zone "16.172.in-addr.arpa" {
in-view "main";
};
zone "169.129.in-addr.arpa" {
in-view "main";
};
zone "17.111.131.in-addr.arpa" {
in-view "main";
};
zone "17.172.in-addr.arpa" {
in-view "main";
};
zone "18.111.131.in-addr.arpa" {
in-view "main";
};
zone "18.172.in-addr.arpa" {
in-view "main";
};
zone "19.172.in-addr.arpa" {
in-view "main";
};
zone "195.18.192.in-addr.arpa" {
in-view "main";
};
zone "2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa" {
in-view "main";
};
zone "20.111.131.in-addr.arpa" {
in-view "main";
};
zone "20.172.in-addr.arpa" {
in-view "main";
};
zone "21.172.in-addr.arpa" {
in-view "main";
};
zone "213.153.192.in-addr.arpa" {
in-view "main";
};
zone "22.172.in-addr.arpa" {
in-view "main";
};
zone "23.172.in-addr.arpa" {
in-view "main";
};
zone "232.128.in-addr.arpa" {
in-view "main";
};
zone "24.111.131.in-addr.arpa" {
in-view "main";
};
zone "24.172.in-addr.arpa" {
in-view "main";
};
zone "25.172.in-addr.arpa" {
in-view "main";
};
zone "252.63.193.in-addr.arpa" {
in-view "main";
};
zone "253.63.193.in-addr.arpa" {
in-view "main";
};
zone "26.172.in-addr.arpa" {
in-view "main";
};
zone "27.172.in-addr.arpa" {
in-view "main";
};
zone "28.172.in-addr.arpa" {
in-view "main";
};
zone "29.172.in-addr.arpa" {
in-view "main";
};
zone "30.172.in-addr.arpa" {
in-view "main";
};
zone "5.0.0.0.8.9.0.1.0.0.a.2.ip6.arpa" {
in-view "main";
};
zone "5.84.192.in-addr.arpa" {
in-view "main";
};
zone "80.60.193.in-addr.arpa" {
in-view "main";
};
zone "81.60.193.in-addr.arpa" {
in-view "main";
};
zone "82.60.193.in-addr.arpa" {
in-view "main";
};
zone "83.60.193.in-addr.arpa" {
in-view "main";
};
zone "84.60.193.in-addr.arpa" {
in-view "main";
};
zone "85.60.193.in-addr.arpa" {
in-view "main";
};
zone "86.60.193.in-addr.arpa" {
in-view "main";
};
zone "87.60.193.in-addr.arpa" {
in-view "main";
};
zone "88.60.193.in-addr.arpa" {
in-view "main";
};
zone "89.60.193.in-addr.arpa" {
in-view "main";
};
zone "90.60.193.in-addr.arpa" {
in-view "main";
};
zone "91.60.193.in-addr.arpa" {
in-view "main";
};
zone "92.60.193.in-addr.arpa" {
in-view "main";
};
zone "93.60.193.in-addr.arpa" {
in-view "main";
};
zone "94.60.193.in-addr.arpa" {
in-view "main";
};
zone "95.60.193.in-addr.arpa" {
in-view "main";
};
zone "block.arpa.cam.ac.uk" {
in-view "main";
};
zone "botnetcc.rpz.spamhaus.org" {
in-view "main";
};
zone "cam.ac.uk" {
in-view "main";
};
zone "cl.cam.ac.uk" {
in-view "main";
};
zone "cst.cam.ac.uk" {
in-view "main";
};
zone "damtp.cam.ac.uk" {
in-view "main";
};
zone "dbl.rpz.spamhaus.org" {
in-view "main";
};
zone "dpmms.cam.ac.uk" {
in-view "main";
};
zone "drop.rpz.spamhaus.org" {
in-view "main";
};
zone "eng.cam.ac.uk" {
in-view "main";
};
zone "in-addr.arpa.cam.ac.uk" {
in-view "main";
};
zone "in-addr.arpa.private.cam.ac.uk" {
in-view "main";
};
zone "malware-aggressive.rpz.spamhaus.org" {
in-view "main";
};
zone "malware.rpz.spamhaus.org" {
in-view "main";
};
zone "maths.cam.ac.uk" {
in-view "main";
};
zone "newton.cam.ac.uk" {
in-view "main";
};
zone "passthru.arpa.cam.ac.uk" {
in-view "main";
};
zone "private.cam.ac.uk" {
in-view "main";
};
zone "srcf.net" {
in-view "main";
};
zone "srcf.ucam.org" {
in-view "main";
};
zone "statslab.cam.ac.uk" {
in-view "main";
};
zone "ucam.org" {
in-view "main";
};
attach-cache "main";
};
key "cam.ac.uk.feb2016.tsig.ic.ac.uk" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "tsig-ipreg" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "university_of_cambridge-a1ec5f18.sns-pba.isc.org" {
algorithm "hmac-sha512";
secret "????????????????????????????????????????????????????????????????????????????????????????";
};
key "tsig-cam-maths" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "tsig-cam-exim" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "tsig-fanf" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
server 157.83.102.245/32 {
send-cookie no;
};
server 157.83.102.246/32 {
send-cookie no;
};
server 157.83.126.245/32 {
send-cookie no;
};
server 157.83.126.246/32 {
send-cookie no;
};
server 43.242.49.158/32 {
send-cookie no;
};
server 113.209.232.218/32 {
send-cookie no;
};
server 63.150.72.5/32 {
send-cookie no;
};
server 2001:428::7/128 {
send-cookie no;
};
server 208.44.130.121/32 {
send-cookie no;
};
server 2001:428::8/128 {
send-cookie no;
};
server 172.16.3.0/24 {
bogus no;
};
server 0.0.0.0/8 {
bogus yes;
};
server 10.0.0.0/8 {
bogus yes;
};
server 100.64.0.0/10 {
bogus yes;
};
server 127.0.0.0/8 {
bogus yes;
};
server 169.254.0.0/16 {
bogus yes;
};
server 172.16.0.0/12 {
bogus yes;
};
server 192.0.0.0/24 {
bogus yes;
};
server 192.0.2.0/24 {
bogus yes;
};
server 192.88.99.0/24 {
bogus yes;
};
server 192.168.0.0/16 {
bogus yes;
};
server 198.18.0.0/15 {
bogus yes;
};
server 198.51.100.0/24 {
bogus yes;
};
server 203.0.113.0/24 {
bogus yes;
};
server 224.0.0.0/3 {
bogus yes;
};
server ::/3 {
bogus yes;
};
server 2001::/32 {
bogus yes;
};
server 2001:2::/48 {
bogus yes;
};
server 2001:10::/28 {
bogus yes;
};
server 2001:db8::/32 {
bogus yes;
};
server 2002::/16 {
bogus yes;
};
server 3000::/4 {
bogus yes;
};
server 4000::/2 {
bogus yes;
};
server 8000::/1 {
bogus yes;
};
```https://gitlab.isc.org/isc-projects/bind9/-/issues/186Bind 9.12.x: Potential bug with Dig when Tools installed on Windows2018-11-09T05:47:30ZGhost UserBind 9.12.x: Potential bug with Dig when Tools installed on Windows<!--
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
Typing dig www.google.com or simply dig hangs after installation of 9.12.x
### Steps to reproduce
1. On a Windows box (W10 -1709 here), run the Bind installer and select Tools installation.
2. After the redistributable and tools are installed, open a cmd prompt and navigate to the install location.
3. Type: dig www.google.com or dig
### What is the current *bug* behavior?
dig hangs and I have to hit ctrl+c to get the cursor back.
### What is the expected *correct* behavior?
Resolve www.google.com's ip.
Now if I type: dig @8.8.8.8 www.google.com, dig works.
On the surface it does not look like dig.exe is looking in the registry to get the nameserver address. Manually creating resolve.conf with a nameserver included in the install folder made no difference. Typing dig.exe would still hang.
The dig.exe included in the 9.11.x branch works as expected.
### Relevant configuration files
### Relevant logs and/or screenshots
### Possible fixesMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/187bind-tools 9.12.1: Parsing of /etc/resolv.conf fails with link-local IPv6 NS ...2018-10-25T06:39:10ZGhost Userbind-tools 9.12.1: Parsing of /etc/resolv.conf fails with link-local IPv6 NS server address### Summary
On Linux, Freedesktop.org's NetworkManager (v 1.10.6) sometimes generates a /etc/resolv.conf file which only contains a single link-local IPv6 nameserver address:
```
# Generated by NetworkManager
nameserver fe80::1%wlp3s0
...### Summary
On Linux, Freedesktop.org's NetworkManager (v 1.10.6) sometimes generates a /etc/resolv.conf file which only contains a single link-local IPv6 nameserver address:
```
# Generated by NetworkManager
nameserver fe80::1%wlp3s0
```
Bind-Tools fail to parse the file correctly while glibc tools (`getent hosts`...) or ping (via GNU inetutils) succeed:
```
$ dig a isc.org
dig: parse of /etc/resolv.conf failed
```
```
$ ping isc.org
PING isc.org (149.20.64.69) 56(84) bytes of data.
```
(Same result for all Bind-Tools).
### Steps to reproduce
Add a single IPv6 link-local nameserver entry to your resolv.conf
### What is the current *bug* behavior?
Common bind-tools (dig, nslookup, host) fail to parse resolv.conf.
### What is the expected *correct* behavior?
bind-tools should parse resolv.conf correctly regardless of what special IPv6 address format is used.
### Relevant configuration files
/etc/resolv.conf.
### Relevant logs and/or screenshots
Not applicable.
### Possible fixes
No data.BIND 9.13.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/188named_paths_init(void) (bin\named\win32\os.c) contains redundant code line.2018-04-04T10:37:06ZGhost Usernamed_paths_init(void) (bin\named\win32\os.c) contains redundant code line.The **named_paths_init(void)** method in bin\named\win32\os.c (master branch) contains **named_g_conffile = isc_ntpaths_get(NAMED_CONF_PATH);** twice.The **named_paths_init(void)** method in bin\named\win32\os.c (master branch) contains **named_g_conffile = isc_ntpaths_get(NAMED_CONF_PATH);** twice.https://gitlab.isc.org/isc-projects/bind9/-/issues/189Fix TSIG dump keyfile name generation issues2018-04-22T19:42:50ZGhost UserFix TSIG dump keyfile name generation issuesThere are issues with `<view>.tsigkeys` dump keyfile name generation. Buffer size is insufficient and slashes may not be handled correctly.There are issues with `<view>.tsigkeys` dump keyfile name generation. Buffer size is insufficient and slashes may not be handled correctly.https://gitlab.isc.org/isc-projects/bind9/-/issues/190DNSSEC Disable for Forward Zone2024-02-23T07:41:05ZGhost UserDNSSEC Disable for Forward Zone### Description
When DNSSEC is enabled, all forward zones will request queries with DNSSEC enabled. Not all services allow DNSSEC responses, and therefore Bind will fail its lookup.
Usecase is where someone is running a Bind server wi...### Description
When DNSSEC is enabled, all forward zones will request queries with DNSSEC enabled. Not all services allow DNSSEC responses, and therefore Bind will fail its lookup.
Usecase is where someone is running a Bind server with a forward zone for Emercoin TLDs. Emercoin TLDs are ofcourse not secured by DNSSEC, and therefore are unable to respond on requests where DNSSEC is enabled.
### Request
Disable DNSSEC per (forward) zone.
### Links / references
NoneMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/191Remove OpenSSL < 1.0.0 support2018-05-03T20:32:48ZOndřej SurýRemove OpenSSL < 1.0.0 supportThe current code is #ifdef spaghetti supporting OpenSSL 1.1, OpenSSL 1.0/LibreSSL and OpenSSL 0.9.6/0.9.8. Let's remove OpenSSL 0.9.x support to simplify the code.The current code is #ifdef spaghetti supporting OpenSSL 1.1, OpenSSL 1.0/LibreSSL and OpenSSL 0.9.6/0.9.8. Let's remove OpenSSL 0.9.x support to simplify the code.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/192Make IPv6 support in the system mandatory2018-08-28T08:51:39ZOndřej SurýMake IPv6 support in the system mandatory...and cleanup related code....and cleanup related code.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/193make distclean fails2018-04-11T03:06:08ZMark Andrewsmake distclean failsmake distclean fails because "system" is in both SUBDIRS and TESTDIRS in bin/tests/Makefile.in. remove from TESTDIRS.make distclean fails because "system" is in both SUBDIRS and TESTDIRS in bin/tests/Makefile.in. remove from TESTDIRS.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/194Commit c8aa1ee forgot one occurence of dns_dt_create2.2018-04-09T14:51:55ZMathieu ArnoldCommit c8aa1ee forgot one occurence of dns_dt_create2.[0001-Rename-the-last-occurence-of-dns_dt_create2.patch](/uploads/7b1a71f7678e55ff044d53f1019cff0c/0001-Rename-the-last-occurence-of-dns_dt_create2.patch)[0001-Rename-the-last-occurence-of-dns_dt_create2.patch](/uploads/7b1a71f7678e55ff044d53f1019cff0c/0001-Rename-the-last-occurence-of-dns_dt_create2.patch)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/195Enable dnstap in GitLab CI builds2019-07-22T21:53:37ZOndřej SurýEnable dnstap in GitLab CI buildsMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/196clang scan-build reporting possible null pointer dereferences2018-05-11T01:02:52ZStephen Morrisclang scan-build reporting possible null pointer dereferencesJenkins build 203 (https://jenkins.isc.org/view/BIND/job/bind9-clang-static-analyzer/203/clangScanBuildBugs/) highlighted some possiible null dereferences in rbt.c.
(It is also reporting a variable that is not used after it is increment...Jenkins build 203 (https://jenkins.isc.org/view/BIND/job/bind9-clang-static-analyzer/203/clangScanBuildBugs/) highlighted some possiible null dereferences in rbt.c.
(It is also reporting a variable that is not used after it is incremented.)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/197dnstap: log actual local IPv6 address, not :: listening address2018-04-11T00:39:20ZEvan Huntdnstap: log actual local IPv6 address, not :: listening addressReported by @fanf in !186; I'm creating a new issue/MR so I can modify his submitted branch.
When logging client and auth queries and responses, dnstap is recording the listening interface address rather than the destination address of ...Reported by @fanf in !186; I'm creating a new issue/MR so I can modify his submitted branch.
When logging client and auth queries and responses, dnstap is recording the listening interface address rather than the destination address of the query.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/198All channels are configured for a specific log facility, however bind9 still ...2018-11-13T13:01:02ZGhost UserAll channels are configured for a specific log facility, however bind9 still logs to daemon.info and daemon.notice### Summary
All channels are configured for a specific log facility, however bind9 still logs to daemon.info and daemon.notice
### Steps to reproduce
Configure logging and specify default_syslog and default_debug to use locale6, rath...### Summary
All channels are configured for a specific log facility, however bind9 still logs to daemon.info and daemon.notice
### Steps to reproduce
Configure logging and specify default_syslog and default_debug to use locale6, rather than file. All documented categories are also defined to use default_syslog only, including the default and unmatched as catchalls.
```
logging {
channel default_syslog {
print-time yes;
print-category yes;
print-severity yes;
syslog local6;
severity info;
};
// is anything usinig this by default?
channel default_debug {
print-time yes;
print-category yes;
print-severity yes;
syslog local6;
severity dynamic;
};
channel default_stderr {
null;
};
channel null {
// toss anything sent to this channel
null;
};
category client { default_syslog; };
category cname { default_syslog; };
category config { default_syslog; };
category database { default_syslog; };
category delegation-only { default_syslog; };
category dispatch { default_syslog; };
category dnssec { default_syslog; };
category edns-disabled { default_syslog; };
category general { default_syslog; };
category lame-servers { default_syslog; };
category network { default_syslog; };
category notify { default_syslog; };
category queries { default_syslog; };
category query-errors { default_syslog; };
category rate-limit { default_syslog; };
category resolver { default_syslog; };
category rpz { default_syslog; };
category security { default_syslog; };
category spill { default_syslog; };
category update { default_syslog; };
category update-security { default_syslog; };
category xfer-in { default_syslog; };
category xfer-out { default_syslog; };
// why doesn't this work - to redirect everything????
category unmatched { default_syslog; };
category default { default_syslog; };
};
options {
...
```
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
Some output is correctly directed to local6
```
Apr 11 12:24:26 local6.info: apu named[19291]: 11-Apr-2018 12:24:26.074 network: info: no longer listening on 192.168.201.1#53
Apr 11 12:24:26 local6.info: apu named[19291]: 11-Apr-2018 12:24:26.075 network: info: no longer listening on 192.168.202.1#53
Apr 11 12:24:26 local6.info: apu named[19291]: 11-Apr-2018 12:24:26.075 network: info: no longer listening on 192.168.203.1#53
Apr 11 12:24:26 local6.info: apu named[19291]: 11-Apr-2018 12:24:26.075 network: info: no longer listening on 192.168.204.1#53
Apr 11 12:24:26 local6.notice: apu named[19291]: 11-Apr-2018 12:24:26.105 general: notice: exiting
Apr 11 12:24:26 local6.info: apu named[19307]: 11-Apr-2018 12:24:26.255 general: info: managed-keys-zone: journal file is out of date: removing journal file
Apr 11 12:24:26 local6.info: apu named[19307]: 11-Apr-2018 12:24:26.256 general: info: managed-keys-zone: loaded serial 439
Apr 11 12:24:26 local6.info: apu named[19307]: 11-Apr-2018 12:24:26.258 general: info: zone 0.in-addr.arpa/IN: loaded serial 1
Apr 11 12:24:26 local6.info: apu named[19307]: 11-Apr-2018 12:24:26.272 general: info: zone 255.in-addr.arpa/IN: loaded serial 1
Apr 11 12:24:26 local6.info: apu named[19307]: 11-Apr-2018 12:24:26.273 general: info: zone 127.in-addr.arpa/IN: loaded serial 1
Apr 11 12:24:26 local6.info: apu named[19307]: 11-Apr-2018 12:24:26.277 rpz: info: (re)loading policy zone 'rpz' changed from 0 to 2 qname, 0 to 0 nsdname, 0 to 0 IP, 0 to 0 NSIP, 0 to 0 CLIENTIP entries
```
But a lot of output is sent to rsyslod daemon.info and daemon.notice
```
Apr 11 12:22:03 daemon.info: apu systemd[1]: Started BIND Domain Name Server.
Apr 11 12:22:03 daemon.notice: apu named[19291]: starting BIND 9.10.3-P4-Debian <id:ebd72b3> -f -u bind
Apr 11 12:22:03 daemon.notice: apu named[19291]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--libdir=/usr/lib/x86_64-linux-gnu' '-
-infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-l
ibtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--w
ith-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib/x86_64-linux-gnu/softhsm/libs
ofthsm2.so' '--with-randomdev=/dev/urandom' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-VypbYM/bind9-9.10.3.dfsg.P4=. -fstack-protector-stron
g -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro
-Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
Apr 11 12:22:03 daemon.notice: apu named[19291]: ----------------------------------------------------
Apr 11 12:22:03 daemon.notice: apu named[19291]: BIND 9 is maintained by Internet Systems Consortium,
Apr 11 12:22:03 daemon.notice: apu named[19291]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Apr 11 12:22:03 daemon.notice: apu named[19291]: corporation. Support and training for BIND 9 are
Apr 11 12:22:03 daemon.notice: apu named[19291]: available at https://www.isc.org/support
Apr 11 12:22:03 daemon.notice: apu named[19291]: ----------------------------------------------------
Apr 11 12:22:03 daemon.notice: apu named[19291]: adjusted limit on open files from 4096 to 1048576
Apr 11 12:22:03 daemon.info: apu named[19291]: found 2 CPUs, using 2 worker threads
Apr 11 12:22:03 daemon.info: apu named[19291]: using 2 UDP listeners per interface
Apr 11 12:22:03 daemon.info: apu named[19291]: using up to 4096 sockets
Apr 11 12:22:03 daemon.info: apu named[19291]: loading configuration from '/etc/bind/named.conf'
...
Apr 11 12:22:03 daemon.info: apu named[19291]: automatic empty zone: B.E.F.IP6.ARPA
Apr 11 12:22:03 daemon.info: apu named[19291]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
Apr 11 12:22:03 daemon.info: apu named[19291]: automatic empty zone: EMPTY.AS112.ARPA
Apr 11 12:22:03 daemon.info: apu named[19291]: configuring command channel from '/etc/bind/rndc.key'
Apr 11 12:22:03 daemon.notice: apu named[19291]: command channel listening on 127.0.0.1#953
Apr 11 12:22:03 daemon.info: apu named[19291]: configuring command channel from '/etc/bind/rndc.key'
Apr 11 12:22:03 daemon.notice: apu named[19291]: command channel listening on ::1#953
```
### What is the expected *correct* behavior?
I expect only the configured channel (locale6 ) to be used.
### 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.)BIND 9.15.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/199v9_10_sub: decrement_reference() not effective for node cleanup2019-04-25T15:46:41ZGhost Userv9_10_sub: decrement_reference() not effective for node cleanup`decrement_reference()` doesn't appear effective for node cleanup in 9.10-sub. This is because `clean_cache_node()` fails to set `node->data` to NULL after freeing the `rbtdb_data_t` when all data under it has been cleaned up.
Something...`decrement_reference()` doesn't appear effective for node cleanup in 9.10-sub. This is because `clean_cache_node()` fails to set `node->data` to NULL after freeing the `rbtdb_data_t` when all data under it has been cleaned up.
Something like this is required:
```
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index 5730d3b14e..eb23137681 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -1990,6 +1990,13 @@ clean_cache_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node) {
rbtdb->common.mctx,
clean_iptree_nodedata,
rbtdb);
+
+ if ((data->nonecs_data == NULL) &&
+ (data->ecs_root == NULL))
+ {
+ isc_mem_put(rbtdb->common.mctx, data, sizeof(*data));
+ node->data = NULL;
+ }
}
node->dirty = 0;
```https://gitlab.isc.org/isc-projects/bind9/-/issues/200Add clang (with clang specific extra options like -Wenum-conversion) to out G...2018-04-18T03:59:05ZOndřej SurýAdd clang (with clang specific extra options like -Wenum-conversion) to out GitLab CIAdding clang to the matrix of our GitLab CI would be beneficial to catch some warnings/errors, that gcc ignores, and also we will ensure that we don't add anything too gcc specific.Adding clang to the matrix of our GitLab CI would be beneficial to catch some warnings/errors, that gcc ignores, and also we will ensure that we don't add anything too gcc specific.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/9kea-admin, keactrl doesn't report Kea version2022-10-27T12:44:25ZTomek Mrugalskikea-admin, keactrl doesn't report Kea versionThose two tools don't report their version as other components do (neither -v or -V is working).
For original ticket, see https://kea.isc.org/ticket/5411Those two tools don't report their version as other components do (neither -v or -V is working).
For original ticket, see https://kea.isc.org/ticket/5411Kea1.5-beta1https://gitlab.isc.org/isc-projects/bind9/-/issues/201serve-stale degraded performance, resolver client leak, and logspam2019-04-25T15:46:50ZTony Finchserve-stale degraded performance, resolver client leak, and logspam### Summary
When `serve-stale` is enabled, `named` can be forced into a bad state in which:
* the performance of the server drops dramatically
* it leaks resolver client tasks
* it uses large amounts of CPU even when not serving real c...### Summary
When `serve-stale` is enabled, `named` can be forced into a bad state in which:
* the performance of the server drops dramatically
* it leaks resolver client tasks
* it uses large amounts of CPU even when not serving real clients
* it writes a huge volume of 'stale answer' log messages
In my testing this bad state starts after about an hour.
This was originally reported in #185 but this problem seems to be separate from the crash so I am opening a new issue.
### Steps to reproduce
I run three copies of the following command-line
```
$ while sleep $(( RANDOM / 100 ))
do time adns-masterfile -s $SERVER -m 100 -qqqq <named_dump_reverse.db
done
```
The dump file is available from https://jackdaw.cam.ac.uk/ipreg/named_dump_reverse.db - it contains about 350000 records from . to as - mainly in-add.arpa, which has a lot of broken authoritative servers and therefore is good for exercising `serve-stale`.
`adns-masterfile` comes from https://git.uis.cam.ac.uk/x/uis/ipreg/adns-masterfile.git
### Relevant configuration files
I use the following options to enable `serve-stale`
```
max-stale-ttl 1h;
stale-answer-enable yes;
```
### Relevant logs and/or screenshots
Here is an indication of how fast it is logging when in the bad state:
```
-rw-rw-r-- 1 named named 11M Apr 11 17:01 named.log.1
-rw-rw-r-- 1 named named 11M Apr 11 17:01 named.log.2
-rw-rw-r-- 1 named named 11M Apr 11 17:01 named.log.3
-rw-rw-r-- 1 named named 11M Apr 11 17:01 named.log.4
-rw-rw-r-- 1 named named 11M Apr 11 17:00 named.log.5
-rw-rw-r-- 1 named named 11M Apr 11 17:00 named.log.6
-rw-rw-r-- 1 named named 11M Apr 11 17:00 named.log.7
-rw-rw-r-- 1 named named 11M Apr 11 17:00 named.log.8
-rw-rw-r-- 1 named named 11M Apr 11 17:00 named.log.9
```Michał KępieńMichał Kępień