BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2019-09-03T16:45:30Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/106[RT# 44978] dig feature to print unexpected reply messages2019-09-03T16:45:30ZVicky Riskvicky@isc.org[RT# 44978] dig feature to print unexpected reply messagesMark,
I was wondering how difficult it would be to have an option where dig would parse DNS replies seen from the unexpected source for debugging purposes.
Example from the IETF network:
<pre>dig @75.75.75.75 +timeout=1 +retries=1000
...Mark,
I was wondering how difficult it would be to have an option where dig would parse DNS replies seen from the unexpected source for debugging purposes.
Example from the IETF network:
<pre>dig @75.75.75.75 +timeout=1 +retries=1000
;; reply from unexpected source: 69.241.23.140#53, expected 75.75.75.75#53
;; reply from unexpected source: 69.241.23.140#53, expected 75.75.75.75#53
;; reply from unexpected source: 69.241.23.152#53, expected 75.75.75.75#53
;; reply from unexpected source: 69.241.23.152#53, expected 75.75.75.75#53
;; reply from unexpected source: 69.241.23.150#53, expected 75.75.75.75#53
;; reply from unexpected source: 69.241.23.150#53, expected 75.75.75.75#53
;; reply from unexpected source: 69.241.23.148#53, expected 75.75.75.75#53
;; reply from unexpected source: 69.241.23.136#53, expected 75.75.75.75#53
;; reply from unexpected source: 69.241.23.136#53, expected 75.75.75.75#53</pre>
"Jared Mauch" <jared@puck.nether.net>
-----
comment [Mark]
Seems reasonable. Basically it would be a new flag then parse and print the response.
Testing would require a custom server that replies from a different address.Not plannedDiego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/107[RT#45306] RNDC & Views2018-02-23T20:23:34ZVicky Riskvicky@isc.org[RT#45306] RNDC & ViewsIt would be useful if rndc treated views as first-class objects.
Its command syntax has the [view] last, so while several commands act
on "all" when no target is specified, you can't say "all in this view".
There are a number of cases...It would be useful if rndc treated views as first-class objects.
Its command syntax has the [view] last, so while several commands act
on "all" when no target is specified, you can't say "all in this view".
There are a number of cases where one would like to do things to
all zones in a view.
The immediate example is this:
rndc freeze/thaw have the syntax:
freeze [zone [class [view]]]
thaw [zone [class [view]]]
I'm in the unfortunate situation of having to do a bulk renumbering
of a view that contains a lot (well, for me) of zones..., and I need
to do an atomic update, while not freezing other views.
For the next round, it would be useful to have something like:
rndc freeze -view internal # Freeze all zones in the "internal" view
...
rndc thaw -view internal
Other cases where a view as a whole seems to be a sensible target:
rndc flush
rndc notify
rndc refresh
rndc reload
rndc retransfer
rndc sync
Thanks.
--
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Download smime.p7s
application/pkcs7-signature 4.4KiBNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/108repeated crashes in 9.12.02019-04-25T15:44:31ZEvan Huntrepeated crashes in 9.12.0Reported by Andrew Fried in private mail:
I've experienced half a dozen core dumps over the past week with BIND
9.12.0. Every time it happens I found critical logs like this in bind.log:
```
24-Feb-2018 06:43:49.404 general: critical:...Reported by Andrew Fried in private mail:
I've experienced half a dozen core dumps over the past week with BIND
9.12.0. Every time it happens I found critical logs like this in bind.log:
```
24-Feb-2018 06:43:49.404 general: critical: rbt.c:2119: REQUIRE((__builtin_expect(!!((node) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(node))->magic == ((('R') << 24 | ('B') << 16 | ('N') << 8 | ('O')))), 1))) failed, back trace
24-Feb-2018 06:43:49.404 general: critical: #0 0x42e460 in assertion_failed()+0x60
24-Feb-2018 06:43:49.404 general: critical: #1 0x61660a in isc_assertion_failed()+0xa
24-Feb-2018 06:43:49.404 general: critical: #2 0x4ff232 in dns_rbt_deletenode()+0x522
24-Feb-2018 06:43:49.404 general: critical: #3 0x503674 in delete_node()+0x214
24-Feb-2018 06:43:49.404 general: critical: #4 0x50d1c6 in decrement_reference()+0x936
24-Feb-2018 06:43:49.404 general: critical: #5 0x50d68e in expire_header()+0xbe
24-Feb-2018 06:43:49.404 general: critical: #6 0x517164 in addrdataset()+0x8a4
24-Feb-2018 06:43:49.404 general: critical: #7 0x4eeea1 in addoptout()+0x861
24-Feb-2018 06:43:49.404 general: critical: #8 0x4ef054 in dns_ncache_add()+0x14
24-Feb-2018 06:43:49.404 general: critical: #9 0x56aaad in ncache_adderesult()+0xad
24-Feb-2018 06:43:49.404 general: critical: #10 0x57824a in validated()+0xfea
24-Feb-2018 06:43:49.404 general: critical: #11 0x63b397 in run()+0x2f7
24-Feb-2018 06:43:49.404 general: critical: #12 0x7fa3d58dc6ba in __do_global_dtors_aux_fini_array_entry()+0x7fa3d4fcdc4a
24-Feb-2018 06:43:49.404 general: critical: #13 0x7fa3d525741d in __do_global_dtors_aux_fini_array_entry()+0x7fa3d49489ad
24-Feb-2018 06:43:49.404 general: critical: exiting (due to assertion failure)
```
This is not a one-off issue - it's happened to multiple servers. I'd
really appreciate it if you'd look into this. I have the core dump
files available on the last two issues that happened this evening an
hour or so apart.BIND-9.12.2https://gitlab.isc.org/isc-projects/bind9/-/issues/109[PATCH] dnssec-keygen: double free after keygen error2018-04-06T04:28:14ZPetr Menšík[PATCH] dnssec-keygen: double free after keygen errorHello,
while I was playing with FIPS mode support, I found dnssec-keygen is
crashing reliably in that mode. If RSA_generate_key_ex fails for any
reason and OpenSSL 1.1+ is used, freed pointer is not reset to null. In
err label it is the...Hello,
while I was playing with FIPS mode support, I found dnssec-keygen is
crashing reliably in that mode. If RSA_generate_key_ex fails for any
reason and OpenSSL 1.1+ is used, freed pointer is not reset to null. In
err label it is then freed again. I doubt it is possible to trigger this
error remotely, but it might be security related. I will leave that to
you for consideration. I think always assigning explicit NULL outside
BN_GENCB_free would not hurt. Changed by the second patch.
Is there reason why EVP_PKEY_CTX is not used for key generation instead?
Is patch with more recent generic API welcome?
[0001-Fix-double-free-on-RSA_generate_key_ex-failure.patch](/uploads/b89822b9cb21f828215e07c924c38cf2/0001-Fix-double-free-on-RSA_generate_key_ex-failure.patch)[0002-Do-not-assign-NULL-conditionally-in-OpenSSL-1.1-make.patch](/uploads/0bb04e2a3d9414f44794804a41f4ac29/0002-Do-not-assign-NULL-conditionally-in-OpenSSL-1.1-make.patch)BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/110libirs: Errors raised while parsing resolv.conf are ignored2018-03-19T22:18:15ZMichał Kępieńlibirs: Errors raised while parsing resolv.conf are ignored`irs_resconf_load()` [stores](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/lib/irs/resconf.c#L569-582) the value returned by `add_search()` into `ret` without consulting its current value first....`irs_resconf_load()` [stores](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/lib/irs/resconf.c#L569-582) the value returned by `add_search()` into `ret` without consulting its current value first. This causes any previous errors raised while parsing `resolv.conf` to be ignored as long as any `domain` or `search` statement is present in the file.BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/111GitLab CI does not run unit tests2018-03-09T16:29:53ZMichał KępieńGitLab CI does not run unit testsGitLab CI currently `./configure`s BIND [without ATF support](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/.gitlab-ci.yml#L88), which prevents unit tests from being executed upon each CI run.
S...GitLab CI currently `./configure`s BIND [without ATF support](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/.gitlab-ci.yml#L88), which prevents unit tests from being executed upon each CI run.
Sadly, ATF is not widely packaged: in the case of Debian, which is of particular interest given that it is the only OS our CI setup uses right now, there have been [several](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766576) [attempts](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773277) to package ATF, but it looks like they did not end with ATF packages getting accepted into official Debian repositories.
Thus, we have two options:
* put a precompiled ATF release into in all of our Docker images (more work to prepare, but saves time upon each CI run),
* compile the ATF version shipped with BIND upon each CI run (easier, but a lot of CPU power goes to waste due to recompiling ATF code over and over).
I ruled out packaging ATF ourselves as I hardly doubt the benefits will outweigh the work we would need to put into it.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/112MX checks are not applied to dynamic updates2018-03-19T22:18:39ZMichał KępieńMX checks are not applied to dynamic updatesThe `check_mx()` function in `lib/ns/update.c` [incorrectly](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/lib/ns/update.c#L1740) [tests](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a663...The `check_mx()` function in `lib/ns/update.c` [incorrectly](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/lib/ns/update.c#L1740) [tests](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/lib/ns/update.c#L1749) whether the `DNS_RDATA_CHECKMX`/`DNS_RDATA_CHECKMXFAIL` flags are set for each applied MX record update as these flags are never set in code paths related to dynamic updates; they can only be set when loading a zone from a master file (`DNS_ZONEOPT_CHECKMX` → `DNS_MASTER_CHECKMX` → `DNS_RDATA_CHECKMX`). This flaw allows MX records containing IP addresses to be added to a zone even when `check-mx fail;` is used.BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/113Minor testsummary.sh improvements (handling colored output, failure summary)2020-09-16T10:05:12ZMichał KępieńMinor testsummary.sh improvements (handling colored output, failure summary)`bin/tests/system/testsummary.sh` could be slightly improved, so that it:
* correctly processes colored system test output,
* prints a summary of failed system tests, if any.`bin/tests/system/testsummary.sh` could be slightly improved, so that it:
* correctly processes colored system test output,
* prints a summary of failed system tests, if any.BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/114Out of tree system tests2020-10-02T08:41:05ZEvan HuntOut of tree system testsAn submitted by @pemensik and addressed in !82An submitted by @pemensik and addressed in !82October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/115clean up bin/tests, convert unit tests to ATF2018-03-19T22:15:47ZEvan Huntclean up bin/tests, convert unit tests to ATFThis is an old item on the TODO list whose time has come. Let's clean up bin/tests:
- remove bin/tests/master, it's been superfluous for a long time; it was turned into lib/isc/tests/master_test.c, but the original was never removed
- m...This is an old item on the TODO list whose time has come. Let's clean up bin/tests:
- remove bin/tests/master, it's been superfluous for a long time; it was turned into lib/isc/tests/master_test.c, but the original was never removed
- move dnssec-signzone tests into bin/tests/system/dnssec (if they aren't already there)
- rewrite atomic, db, dst, hashes, mem, names, net, rbt, resolver, sockaddr, tasks and timers as ATF tests (and ideally do something about how slow a few of them are)
- review the remaining tests in bin/tests/*_test.c and see if there are others that should be converted
- remove lib/tests and bin/tests/t_api.pl after all tests using them are convertedBIND-9.13.0Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/116dnsrpz-enable log message appears to be broken2018-03-19T22:16:40ZGhost Userdnsrpz-enable log message appears to be brokenSee the following log message:
```c
#ifndef USE_DNSRPS
if (dnsrps_enabled) {
cfg_obj_log(rpz_obj, named_g_lctx, DNS_RPZ_ERROR_LEVEL,
"\"dnsrps-enable yes\" but"
" with `./configure --enable-d...See the following log message:
```c
#ifndef USE_DNSRPS
if (dnsrps_enabled) {
cfg_obj_log(rpz_obj, named_g_lctx, DNS_RPZ_ERROR_LEVEL,
"\"dnsrps-enable yes\" but"
" with `./configure --enable-dnsrps`");
return (ISC_R_FAILURE);
}
#else
```
Should it not say **without**? That log message is better thrown away and handled as a `CFG_CLAUSEFLAG_NOTCONFIGURED`.BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/117Running dnssec-keymgr with old keys inactivates/deletes them immediately2019-01-22T18:10:49ZGhost UserRunning dnssec-keymgr with old keys inactivates/deletes them immediatelyTested with 9.11.2, but I haven't seen any commits in master that would fix this, so reporting anyway
When you run dnssec-keymgr with keys that are older (Activation Time further in the past) than the configured (or default) roll-period...Tested with 9.11.2, but I haven't seen any commits in master that would fix this, so reporting anyway
When you run dnssec-keymgr with keys that are older (Activation Time further in the past) than the configured (or default) roll-period, the keys are set to be inactive/deleted at a date way in the past. You can easily test this with the default policy by creating a ZSK that has been activated 2 years in the past
```
# dnssec-keygen -f KSK -A -2y -a RSASHA256 -b 2048 example.com
Generating key pair......................................................+++ .........................................+++
Kexample.com.+008+37477
# dnssec-keygen -A -2y -a RSASHA256 -b 2048 example.com
Generating key pair....................................+++ ....................+++
Kexample.com.+008+19905
# dnssec-coverage
WARNING: Maximum TTL value was not specified. Using 1 week
(604800 seconds); re-run with the -m option to get more
accurate results.
PHASE 1--Loading keys to check for internal timing problems
PHASE 2--Scanning future key events for coverage failures
Checking scheduled KSK events for zone example.com, algorithm RSASHA256...
Sun Feb 28 16:02:23 UTC 2016:
Publish: example.com/RSASHA256/37477 (KSK)
Activate: example.com/RSASHA256/37477 (KSK)
No errors found
Checking scheduled ZSK events for zone example.com, algorithm RSASHA256...
Sun Feb 28 16:02:25 UTC 2016:
Publish: example.com/RSASHA256/19905 (ZSK)
Activate: example.com/RSASHA256/19905 (ZSK)
No errors found
```
```
; This is a zone-signing key, keyid 19905, for example.com.
; Created: 20180227160225 (Tue Feb 27 17:02:25 2018)
; Publish: 20160228160225 (Sun Feb 28 17:02:25 2016)
; Activate: 20160228160225 (Sun Feb 28 17:02:25 2016)
```
Now running dnssec-keymgr sets the key to Inactivate at Publish+1y (which is 1 year in the past) and delete a month later. Additionally there the generation of the NEW ZSK fails with a Python error, which leaves the zone without any active ZSK
```
# dnssec-keymgr
# /usr/sbin/dnssec-settime -K . -I 20170227160225 -D 20170329160225 Kexample.com.+008+19905
# /usr/sbin/dnssec-keygen -q -K . -S Kexample.com.+008+19905 -L 3600 -i 2592000
Unable to apply policy: example.com/RSASHA256: Can't convert 'bytes' object to str implicitly
```
```
; This is a zone-signing key, keyid 19905, for example.com.
; Created: 20180227160225 (Tue Feb 27 17:02:25 2018)
; Publish: 20160228160225 (Sun Feb 28 17:02:25 2016)
; Activate: 20160228160225 (Sun Feb 28 17:02:25 2016)
; Inactive: 20170227160225 (Mon Feb 27 17:02:25 2017)
; Delete: 20170329160225 (Wed Mar 29 18:02:25 2017)
```
The next run of dnssec-keymgr generates a new ZSK.
In the end this creates a completely messed up ZSK rollover where the DNSKEY is pulled immediately without a new ZSK being present.BIND 9.11.6Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/118BIND 9.10 cookie system test failing2018-03-01T21:48:10ZMark AndrewsBIND 9.10 cookie system test failingas at 35117c19014bf80d46f4b29b96214df6c55c5ecb the cookie system test is failing
<pre>
S:cookie/:Wed 28 Feb 2018 07:14:52 AEDT
T:cookie/:1:A
A:cookie/:System test cookie/
I:cookie/:PORTRANGE:5300 - 5399
../conf.sh: line 280: ns3/named.c...as at 35117c19014bf80d46f4b29b96214df6c55c5ecb the cookie system test is failing
<pre>
S:cookie/:Wed 28 Feb 2018 07:14:52 AEDT
T:cookie/:1:A
A:cookie/:System test cookie/
I:cookie/:PORTRANGE:5300 - 5399
../conf.sh: line 280: ns3/named.conf: No such file or directory
../conf.sh: line 280: ns4/named.conf: No such file or directory
../conf.sh: line 280: ns5/named.conf: No such file or directory
../conf.sh: line 280: ns6/named.conf: No such file or directory
I:cookie:checking that named-checkconf detects error in bad-cookie-badhex.conf
I:cookie:checking that named-checkconf detects error in bad-cookie-toolong.conf
I:cookie:checking COOKIE token returned to empty COOKIE option (1)
I:cookie:checking COOKIE token returned to empty COOKIE option (+sit) (2)
I:cookie:checking response size without COOKIE (3)
/Users/marka/git/bind9/bin/dig/dig: '.example' is not a legal name (empty label)
I:cookie:failed
I:cookie:checking response size without valid COOKIE (4)
I:cookie:checking response size without valid COOKIE (+sit) (5)
I:cookie:checking response size with COOKIE (6)
I:cookie:checking response size with COOKIE (+sit) (7)
I:cookie:checking response size with COOKIE recursive (8)
I:cookie:checking response size with COOKIE recursive (+sit) (9)
I:cookie:checking COOKIE is learnt for TCP retry (10)
I:cookie:checking COOKIE is learnt for TCP retry (+sit) (11)
I:cookie:checking for COOKIE value in adb (12)
I:cookie:exit status: 1
R:cookie/:FAIL
E:cookie/:Wed 28 Feb 2018 07:14:56 AEDT
</pre>Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/119Remove unnecessary INSIST() in code2018-03-19T22:18:09ZGhost UserRemove unnecessary INSIST() in code```
diff --git a/lib/ns/query.c b/lib/ns/query.c
index 6f8df29dce..e9f0590f07 100644
--- a/lib/ns/query.c
+++ b/lib/ns/query.c
@@ -3882,8 +3882,8 @@ rpz_rewrite(ns_client_t *client, dns_rdatatype_t qtype,
st->popt = popt;...```
diff --git a/lib/ns/query.c b/lib/ns/query.c
index 6f8df29dce..e9f0590f07 100644
--- a/lib/ns/query.c
+++ b/lib/ns/query.c
@@ -3882,8 +3882,8 @@ rpz_rewrite(ns_client_t *client, dns_rdatatype_t qtype,
st->popt = popt;
st->rpz_ver = rpz_ver;
client->query.rpz_st = st;
- if (popt.dnsrps_enabled) {
#ifdef USE_DNSRPS
+ if (popt.dnsrps_enabled) {
if (st->rpsdb != NULL) {
dns_db_detach(&st->rpsdb);
}
@@ -3898,10 +3898,8 @@ rpz_rewrite(ns_client_t *client, dns_rdatatype_t qtype,
st->m.policy = DNS_RPZ_POLICY_ERROR;
return (ISC_R_SUCCESS);
}
-#else
- INSIST(0);
-#endif
}
+#endif
}
/*
```BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/120BIND 9.11 addzone fails.2018-03-04T22:14:15ZMark AndrewsBIND 9.11 addzone fails.<pre>
S:addzone:Tue Feb 27 17:37:24 PST 2018
T:addzone:1:A
A:addzone:System test addzone
I:addzone:PORTRANGE:5400 - 5499
I:Couldn't start server ns1 (pid=12843)
I:failed
R:addzone:FAIL
E:addzone:Tue Feb 27 17:37:39 PST 2018
</pre><pre>
S:addzone:Tue Feb 27 17:37:24 PST 2018
T:addzone:1:A
A:addzone:System test addzone
I:addzone:PORTRANGE:5400 - 5499
I:Couldn't start server ns1 (pid=12843)
I:failed
R:addzone:FAIL
E:addzone:Tue Feb 27 17:37:39 PST 2018
</pre>Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/121views system test has wrong test strings for reload completion.2018-03-19T22:21:19ZMark Andrewsviews system test has wrong test strings for reload completion.We should be looking for "all zones loaded" rather than "reloading zones succeeded". The later results in timing issues.
<pre>
S:views/:Wed 28 Feb 2018 17:07:34 AEDT
T:views/:1:A
A:views/:System test views/
I:views/:PORTRANGE:5300 - 53...We should be looking for "all zones loaded" rather than "reloading zones succeeded". The later results in timing issues.
<pre>
S:views/:Wed 28 Feb 2018 17:07:34 AEDT
T:views/:1:A
A:views/:System test views/
I:views/:PORTRANGE:5300 - 5399
I:views:fetching a.example from ns2's initial configuration
I:views:fetching a.example from ns3's initial configuration
I:views:copying in new configurations for ns2 and ns3
I:views:reloading ns2 and ns3 with rndc
I:views:ns2 server reload successful
I:views:ns3 server reload successful
I:views:wait for reload
ns2/named.run
28-Feb-2018 17:07:37.082 zone_settimer: zone example/IN/internal: enter
28-Feb-2018 17:07:37.082 zone_settimer: zone example/IN/internal: settimer inactive
28-Feb-2018 17:07:37.119 zone_settimer: zone example/IN/external: enter
28-Feb-2018 17:07:37.120 zone_settimer: zone example/IN/external: settimer inactive
28-Feb-2018 17:07:37.203 zone example/IN: (master) removed
28-Feb-2018 17:07:37.205 reloading zones succeeded
28-Feb-2018 17:07:37.244 zone_shutdown: zone example/IN: shutting down
28-Feb-2018 17:07:37.249 zone example/IN/internal: starting load
28-Feb-2018 17:07:37.251 zone example/IN/internal: number of nodes in database: 5
28-Feb-2018 17:07:37.251 zone example/IN/internal: journal rollforward completed successfully: no journal
28-Feb-2018 17:07:37.251 zone example/IN/internal: loaded; checking validity
28-Feb-2018 17:07:37.251 zone_settimer: zone example/IN/internal: enter
28-Feb-2018 17:07:37.251 zone example/IN/internal: loaded serial 2
28-Feb-2018 17:07:37.259 zone_timer: zone example/IN/internal: enter
28-Feb-2018 17:07:37.259 zone_maintenance: zone example/IN/internal: enter
28-Feb-2018 17:07:37.259 zone example/IN/internal: sending notifies (serial 2)
28-Feb-2018 17:07:37.259 zone_settimer: zone example/IN/internal: enter
28-Feb-2018 17:07:37.259 zone_settimer: zone example/IN/internal: settimer inactive
28-Feb-2018 17:07:37.263 zone example/IN/internal: sending notify to 10.53.0.3#5300
28-Feb-2018 17:07:37.307 zone example/IN/external: starting load
28-Feb-2018 17:07:37.308 zone example/IN/external: number of nodes in database: 4
28-Feb-2018 17:07:37.308 zone example/IN/external: journal rollforward completed successfully: no journal
28-Feb-2018 17:07:37.309 zone example/IN/external: loaded; checking validity
28-Feb-2018 17:07:37.309 zone_settimer: zone example/IN/external: enter
28-Feb-2018 17:07:37.309 zone example/IN/external: loaded serial 2
28-Feb-2018 17:07:37.313 zone example/IN/internal: notify response from 10.53.0.3#5300: NOERROR
28-Feb-2018 17:07:37.313 all zones loaded
28-Feb-2018 17:07:37.314 zone_timer: zone example/IN/external: enter
28-Feb-2018 17:07:37.314 zone_maintenance: zone example/IN/external: enter
28-Feb-2018 17:07:37.314 zone example/IN/external: sending notifies (serial 2)
28-Feb-2018 17:07:37.315 zone_settimer: zone example/IN/external: enter
28-Feb-2018 17:07:37.315 dns_zone_maintenance: zone example/IN/internal: enter
28-Feb-2018 17:07:37.315 zone_settimer: zone example/IN/external: settimer inactive
28-Feb-2018 17:07:37.315 zone_settimer: zone example/IN/internal: enter
28-Feb-2018 17:07:37.315 zone_settimer: zone example/IN/internal: settimer inactive
28-Feb-2018 17:07:37.325 dns_zone_maintenance: zone example/IN/external: enter
28-Feb-2018 17:07:37.325 zone_settimer: zone example/IN/external: enter
28-Feb-2018 17:07:37.326 zone_settimer: zone example/IN/external: settimer inactive
28-Feb-2018 17:07:37.391 client @0x7f93d08dfe10 10.53.0.3#56010 (example): view internal: transfer of 'example/IN': AXFR question section OK
28-Feb-2018 17:07:37.391 client @0x7f93d08dfe10 10.53.0.3#56010 (example): view internal: transfer of 'example/IN': AXFR authority section OK
28-Feb-2018 17:07:37.391 client @0x7f93d08dfe10 10.53.0.3#56010 (example): view internal: transfer of 'example/IN': AXFR started (serial 2)
28-Feb-2018 17:07:37.392 client @0x7f93d08dfe10 10.53.0.3#56010 (example): view internal: transfer of 'example/IN': sending TCP message of 227 bytes
28-Feb-2018 17:07:37.392 client @0x7f93d08dfe10 10.53.0.3#56010 (example): view internal: transfer of 'example/IN': AXFR ended
ns3/named.run
28-Feb-2018 17:07:37.220 zone example/IN: not reusable: type mismatch
28-Feb-2018 17:07:37.286 zone example/IN: (master) removed
28-Feb-2018 17:07:37.287 zone_shutdown: zone example/IN: shutting down
28-Feb-2018 17:07:37.287 zone example/IN: notify from 10.53.0.2#56578: no serial
28-Feb-2018 17:07:37.287 queue_soa_query: zone example/IN: enter
28-Feb-2018 17:07:37.288 reloading zones succeeded
28-Feb-2018 17:07:37.288 soa_query: zone example/IN: enter
28-Feb-2018 17:07:37.388 refresh_callback: zone example/IN: enter
28-Feb-2018 17:07:37.388 refresh_callback: zone example/IN: serial: new 2, old not loaded
28-Feb-2018 17:07:37.389 queue_xfrin: zone example/IN: enter
28-Feb-2018 17:07:37.389 zone example/IN: Transfer started.
28-Feb-2018 17:07:37.389 zone example/IN: no database exists yet, requesting AXFR of initial version from 10.53.0.2#5300
28-Feb-2018 17:07:37.390 transfer of 'example/IN' from 10.53.0.2#5300: connected using 10.53.0.3#56010
28-Feb-2018 17:07:37.390 transfer of 'example/IN' from 10.53.0.2#5300: sent request data
28-Feb-2018 17:07:37.392 transfer of 'example/IN' from 10.53.0.2#5300: received 227 bytes
28-Feb-2018 17:07:37.393 transfer of 'example/IN' from 10.53.0.2#5300: got nonincremental response
28-Feb-2018 17:07:37.395 zone example/IN: replacing zone database
28-Feb-2018 17:07:37.395 zone example/IN: zone transfer finished: success
28-Feb-2018 17:07:37.395 zone example/IN: transferred serial 2
28-Feb-2018 17:07:37.395 zone_needdump: zone example/IN: enter
28-Feb-2018 17:07:37.395 zone_settimer: zone example/IN: enter
28-Feb-2018 17:07:37.395 zone_settimer: zone example/IN: enter
28-Feb-2018 17:07:37.395 transfer of 'example/IN' from 10.53.0.2#5300: Transfer status: success
28-Feb-2018 17:07:37.395 transfer of 'example/IN' from 10.53.0.2#5300: Transfer completed: 1 messages, 9 records, 227 bytes, 0.005 secs (45400 bytes/sec)
28-Feb-2018 17:07:37.395 zone_timer: zone example/IN: enter
28-Feb-2018 17:07:37.395 zone_maintenance: zone example/IN: enter
28-Feb-2018 17:07:37.402 all zones loaded
28-Feb-2018 17:07:37.405 dns_zone_maintenance: zone example/IN: enter
28-Feb-2018 17:07:37.405 zone_settimer: zone example/IN: enter
28-Feb-2018 17:07:37.405 zone_timer: zone example/IN: enter
28-Feb-2018 17:07:37.405 zone_maintenance: zone example/IN: enter
28-Feb-2018 17:07:37.405 zone example/IN: sending notifies (serial 2)
28-Feb-2018 17:07:37.405 zone_dump: zone example/IN: enter
28-Feb-2018 17:07:37.405 zone_settimer: zone example/IN: enter
28-Feb-2018 17:07:37.405 zone example/IN: sending notify to 10.53.0.2#5300
28-Feb-2018 17:07:37.405 zone_gotwritehandle: zone example/IN: enter
28-Feb-2018 17:07:37.406 dump_done: zone example/IN: enter
28-Feb-2018 17:07:37.406 zone_journal_compact: zone example/IN: target journal size 2240
28-Feb-2018 17:07:37.406 zone example/IN: dns_journal_compact: not found
28-Feb-2018 17:07:37.407 zone example/IN: notify response from 10.53.0.2#5300: NOERROR
I:views:fetching a.example from ns2's 10.53.0.4, source address 10.53.0.4
I:views:fetching a.example from ns2's 10.53.0.2, source address 10.53.0.2
I:views:fetching a.example from ns3's 10.53.0.3, source address defaulted
I:views:comparing ns3's initial a.example to one from reconfigured 10.53.0.2
I:views:comparing ns3's initial a.example to one from reconfigured 10.53.0.3
I:views:comparing ns2's initial a.example to one from reconfigured 10.53.0.4
I:views:comparing ns2's initial a.example to one from reconfigured 10.53.0.3
I:views:(should be different)
I:views:updating cloned zone in internal view
I:views:sleeping to allow update to take effect
I:views:verifying update affected both views
I:views:verifying forwarder in cloned zone works
I:views:verifying inline zones work with views
I:views:exit status: 0
R:views/:PASS
E:views/:Wed 28 Feb 2018 17:07:44 AEDT
</pre>BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/122nsupdate system test fails for BIND < 9.122018-03-01T20:55:17ZMark Andrewsnsupdate system test fails for BIND < 9.12`I:nsupdate:ensure 'check-mx warn' allows adding MX records containing an address with a warning`
subtest fails because `nsupdate` is called with `-4`.`I:nsupdate:ensure 'check-mx warn' allows adding MX records containing an address with a warning`
subtest fails because `nsupdate` is called with `-4`.Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/123Support 64 RPZ zones by default from 9.13 onwards2018-03-18T10:25:34ZGhost UserSupport 64 RPZ zones by default from 9.13 onwardsSupport 64 RPZ zones by default from 9.13 onwards. Right now it's 32 or 64, and there doesn't seem to be any pressing need to have this choice going forward.Support 64 RPZ zones by default from 9.13 onwards. Right now it's 32 or 64, and there doesn't seem to be any pressing need to have this choice going forward.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/124validation fails for rs.dns-oarc.net/TXT2023-10-31T09:44:05ZEvan Huntvalidation fails for rs.dns-oarc.net/TXTApparently caused by change 4859 - we're over-aggressively checking for validation deadlocks when a an apex CNAME is found.Apparently caused by change 4859 - we're over-aggressively checking for validation deadlocks when a an apex CNAME is found.https://gitlab.isc.org/isc-projects/bind9/-/issues/125in-view duplicate zone not detected by named-checkconf2018-03-19T22:16:09ZCathy Almondin-view duplicate zone not detected by named-checkconfIt doesn't seem that the configuration checker is applied effectively to zones of type 'in-view' that are declared referencing a copy of the zone that is being loaded in another view.
For example:
```
view "my-default" {
...
z...It doesn't seem that the configuration checker is applied effectively to zones of type 'in-view' that are declared referencing a copy of the zone that is being loaded in another view.
For example:
```
view "my-default" {
...
zone "yum.co.uk" IN {
type master;
file "yum.co.uk.zone";
};
...
};
```
```
view "another-one" {
match-clients { any; };
zone "yum.co.uk" IN {
type master;
file "yum.co.uk.zone";
};
zone "yum.co.uk" IN {
in-view "my-default";
};
};
```
There are no errors reported when it is run through named-checkconf, but when loading, named fails when parsing the second instance of "yum.co.uk" in the second view - having not previously detected that there might be a problem loading it.
The error message reported is not particularly helpful:
```
02-Mar-2018 18:37:43.266 automatic empty zone: view my-default: EMPTY.AS112.ARPA
02-Mar-2018 18:37:43.266 loading configuration: already exists
02-Mar-2018 18:37:43.266 exiting (due to fatal error)
```
Compare this with the scenario where the same zone has been declared identically in the view:
...
```
view "another-one" {
match-clients { any; };
zone "yum.co.uk" IN {
type master;
file "yum.co.uk.zone";
};
zone "yum.co.uk" IN {
type master;
file "yum.co.uk.zone";
};
```
```
$ named-checkconf /etc/named.conf
/etc/named.conf:180: zone 'yum.co.uk': already exists previous definition: /etc/named.conf:175
$
```
Which of course is repeated if you try to start named without checking the configuration first:
```
02-Mar-2018 18:51:24.689 loading configuration from '/etc/named.conf'
02-Mar-2018 18:51:24.690 /etc/named.conf:180: zone 'yum.co.uk': already exists previous definition: /etc/named.conf:175
02-Mar-2018 18:51:24.690 loading configuration: failure
02-Mar-2018 18:51:24.690 exiting (due to fatal error)
```
It would be helpful if the in-view zones were included in the same sanity checking as other zone types, and thus generate a more helpful error message (including the line number of named.conf) for the administrator to fix.BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/126"make distclean" fails.2018-03-19T22:18:27ZMark Andrews"make distclean" fails."make distclean" fails as some make cannot handle macros that end in '\' which is currently the case for SUBDIR in bin/tests if @PKCS11_TOOLS@ is empty. The last element gets repeated which causes the system directory to be entered twic..."make distclean" fails as some make cannot handle macros that end in '\' which is currently the case for SUBDIR in bin/tests if @PKCS11_TOOLS@ is empty. The last element gets repeated which causes the system directory to be entered twice. This can also cause timing issues when building.
<pre>
-SUBDIRS = atomic db dst master mem hashes names \
- net rbt resolver sockaddr tasks timers system \
- @PKCS11_TOOLS@
+SUBDIR = atomic db dst master mem hashes names net rbt resolver \
+ sockaddr tasks timers system @PKCS11_TOOLS@
</pre>BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/127Add Code Coverage mechanism to BIND2021-09-15T08:30:48ZOndřej SurýAdd Code Coverage mechanism to BINDOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/128mkeys system test fails intermittently2018-03-08T13:09:18ZMichał Kępieńmkeys system test fails intermittentlyThe failure mode below has been observed once so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
```
S:mkeys:Tue Mar 6 07:42:47 UTC 2018
T:mkeys:1:A
A:mkeys:System test mkeys
I:mkeys:PORTRANGE:9600 - 9699
I:mkeys:check fo...The failure mode below has been observed once so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
```
S:mkeys:Tue Mar 6 07:42:47 UTC 2018
T:mkeys:1:A
A:mkeys:System test mkeys
I:mkeys:PORTRANGE:9600 - 9699
I:mkeys:check for signed record (1)
I:mkeys:check positive validation with valid trust anchor (2)
I:mkeys:check positive validation using delv (3)
I:mkeys:check for failed validation due to wrong key in managed-keys (4)
I:mkeys:check new trust anchor can be added (5)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check new trust anchor can't be added with bad initial key (6)
I:mkeys:ns3 refreshing managed keys for '_default'
I:mkeys:remove untrusted standby key, check timer restarts (7)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore untrusted standby key, revoke original key (8)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:refresh managed-keys, ensure same result (9)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore revoked key, ensure same result (10)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reinitialize trust anchors, add second key to bind.keys
I:mkeys:check that no key from bind.keys is marked as an initializing key (11)
I:mkeys:reinitialize trust anchors, revert to one key in bind.keys
I:mkeys:check that standby key is now trusted (12)
I:mkeys:revoke original key, add new standby (13)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:revoke standby before it is trusted (14)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:wait 20 seconds for key add/remove holddowns to expire (15)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:revoke all keys, confirm roll to insecure (16)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check for insecure response (17)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reset the root server
I:mkeys:reinitialize trust anchors
I:mkeys:check positive validation (18)
I:mkeys:revoke key with bad signature, check revocation is ignored (19)
I:mkeys:ns1 zone reload queued
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check validation fails with bad DNSKEY rrset (20)
I:mkeys:restore DNSKEY rrset, check validation succeeds again (21)
I:mkeys:ns1 zone reload queued
I:mkeys:reset the root server with no keys, check for minimal update (22)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reset the root server with no signatures, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore root server, check validation succeeds again (24)
I:mkeys:ns1 zone reload queued
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check that trust-anchor-telemetry queries are logged (25)
I:mkeys:check that trust-anchor-telemetry queries are received (26)
I:mkeys:check 'rndc-managed-keys destroy' (27)
I:mkeys:ns2 destroying managed-keys database for '_default'
I:mkeys:check that trust-anchor-telemetry queries contain the correct key (28)
I:mkeys:check initialization fails if managed-keys can't be created (29)
I:mkeys:check failure to contact root servers does not prevent key refreshes after restart (30)
I:mkeys:check key refreshes are resumed after root servers become available (31)
I:mkeys:exceeded time limit waiting for 'Returned from key fetch in keyfetch_done()' in ns5/named.run
I:mkeys:failed
I:mkeys:exit status: 1
R:mkeys:FAIL
E:mkeys:Tue Mar 6 07:44:44 UTC 2018
```
Contents of `bin/tests/system/mkeys/` [attached](/uploads/1d49120036975b1478ae848ad3bc0689/mkeys.tar.gz).BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/129dnssec system test fails intermittently2019-03-11T12:02:07ZMichał Kępieńdnssec system test fails intermittentlyThe failure mode below has been observed 4 times so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3025
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3048
* https://g...The failure mode below has been observed 4 times so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3025
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3048
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3078
```
S:dnssec:Tue Mar 6 07:40:18 UTC 2018
T:dnssec:1:A
A:dnssec:System test dnssec
I:dnssec:PORTRANGE:7400 - 7499
I:dnssec:checking that zone transfer worked (1)
I:dnssec:checking AD bit asking for validation (2)
I:dnssec:checking that AD is not set without +adflag or +dnssec (3)
I:dnssec:checking for AD in authoritative answer (4)
I:dnssec:checking positive validation NSEC (5)
I:dnssec:checking postive validation NSEC using dns_client (6)
I:dnssec:checking positive validation NSEC3 (7)
I:dnssec:checking positive validation NSEC3 using dns_client (8)
I:dnssec:checking positive validation OPTOUT (9)
I:dnssec:checking positive validation OPTOUT using dns_client (10)
I:dnssec:checking positive wildcard validation NSEC (11)
I:dnssec:checking positive wildcard validation NSEC using dns_client (12)
I:dnssec:checking positive wildcard answer NSEC3 (13)
I:dnssec:checking positive wildcard answer NSEC3 (14)
I:dnssec:checking positive wildcard validation NSEC3 (15)
I:dnssec:checking positive wildcard validation NSEC3 using dns_client (16)
I:dnssec:checking positive wildcard validation OPTOUT (17)
I:dnssec:checking positive wildcard validation OPTOUT using dns_client (18)
I:dnssec:checking negative validation NXDOMAIN NSEC (19)
I:dnssec:checking negative validation NXDOMAIN NSEC using dns_client (20)
I:dnssec:checking negative validation NXDOMAIN NSEC3 (21)
I:dnssec:checking negative validation NXDOMAIN NSEC3 using dns_client (22)
I:dnssec:checking negative validation NXDOMAIN OPTOUT (23)
I:dnssec:checking negative validation NXDOMAIN OPTOUT using dns_client (24)
I:dnssec:checking negative validation NODATA NSEC (25)
I:dnssec:checking negative validation NODATA OPTOUT using dns_client (26)
I:dnssec:checking negative validation NODATA NSEC3 (27)
I:dnssec:checking negative validation NODATA NSEC3 using dns_client (28)
I:dnssec:checking negative validation NODATA OPTOUT (29)
I:dnssec:checking negative validation NODATA OPTOUT using dns_client (30)
I:dnssec:checking negative wildcard validation NSEC (31)
I:dnssec:checking negative wildcard validation NSEC using dns_client (32)
I:dnssec:checking negative wildcard validation NSEC3 (33)
I:dnssec:checking negative wildcard validation NSEC3 using dns_client (34)
I:dnssec:checking negative wildcard validation OPTOUT (35)
I:dnssec:checking negative wildcard validation OPTOUT using dns_client (36)
I:dnssec:checking 1-server insecurity proof NSEC (37)
I:dnssec:checking 1-server insecurity proof NSEC using dns_client (38)
I:dnssec:checking 1-server insecurity proof NSEC3 (39)
I:dnssec:checking 1-server insecurity proof NSEC3 using dns_client (40)
I:dnssec:checking 1-server insecurity proof OPTOUT (41)
I:dnssec:checking 1-server insecurity proof OPTOUT using dns_client (42)
I:dnssec:checking 1-server negative insecurity proof NSEC (43)
I:dnssec:checking 1-server negative insecurity proof NSEC using dns_client (44)
I:dnssec:checking 1-server negative insecurity proof NSEC3 (45)
I:dnssec:checking 1-server negative insecurity proof NSEC3 using dns_client (46)
I:dnssec:checking 1-server negative insecurity proof OPTOUT (47)
I:dnssec:checking 1-server negative insecurity proof OPTOUT using dns_client (48)
I:dnssec:checking 1-server negative insecurity proof with SOA hack NSEC (49)
I:dnssec:checking 1-server negative insecurity proof with SOA hack NSEC3 (50)
I:dnssec:checking 1-server negative insecurity proof with SOA hack OPTOUT (51)
I:dnssec:checking multi-stage positive validation NSEC/NSEC (52)
I:dnssec:checking multi-stage positive validation NSEC/NSEC3 (53)
I:dnssec:checking multi-stage positive validation NSEC/OPTOUT (54)
I:dnssec:checking multi-stage positive validation NSEC3/NSEC (55)
I:dnssec:checking multi-stage positive validation NSEC3/NSEC3 (56)
I:dnssec:checking multi-stage positive validation NSEC3/OPTOUT (57)
I:dnssec:checking multi-stage positive validation OPTOUT/NSEC (58)
I:dnssec:checking multi-stage positive validation OPTOUT/NSEC3 (59)
I:dnssec:checking multi-stage positive validation OPTOUT/OPTOUT (60)
I:dnssec:checking empty NODATA OPTOUT (61)
I:dnssec:checking failed validation (62)
I:dnssec:checking failed validation using dns_client (63)
I:dnssec:checking that validation fails with a misconfigured trusted key (64)
I:dnssec:checking that negative validation fails with a misconfigured trusted key (65)
I:dnssec:checking that insecurity proofs fail with a misconfigured trusted key (66)
I:dnssec:checking that validation fails when key record is missing (67)
I:dnssec:checking that validation fails when key record is missing using dns_client (68)
I:dnssec:checking that validation succeeds when a revoked key is encountered (69)
I:dnssec:checking that validation succeeds when a revoked key is encountered using dns_client (70)
I:dnssec:Checking that a bad CNAME signature is caught after a +CD query (71)
I:dnssec:Checking that a bad DNAME signature is caught after a +CD query (72)
I:dnssec:checking 2-server insecurity proof (73)
I:dnssec:checking 2-server insecurity proof with a negative answer (74)
I:dnssec:checking 2-server insecurity proof with a negative answer and SOA hack (75)
I:dnssec:checking security root query (76)
I:dnssec:checking cd bit on a positive answer (77)
I:dnssec:checking cd bit on a negative answer (78)
I:dnssec:checking positive validation RSASHA256 NSEC (79)
I:dnssec:checking positive validation RSASHA512 NSEC (80)
I:dnssec:checking positive validation with KSK-only DNSKEY signature (81)
I:dnssec:checking cd bit on a query that should fail (82)
I:dnssec:checking cd bit on an insecurity proof (83)
I:dnssec:checking cd bit on a negative insecurity proof (84)
I:dnssec:checking that validation of an ANY query works (85)
I:dnssec:checking that validation of a query returning a CNAME works (86)
I:dnssec:checking that validation of a query returning a DNAME works (87)
I:dnssec:checking that validation of an ANY query returning a CNAME works (88)
I:dnssec:checking that validation of an ANY query returning a DNAME works (89)
I:dnssec:checking that positive validation in a privately secure zone works (90)
I:dnssec:checking that negative validation in a privately secure zone works (91)
I:dnssec:checking that lookups succeed after disabling a algorithm works (92)
I:dnssec:checking privately secure to nxdomain works (93)
I:dnssec:checking privately secure wildcard to nxdomain works (94)
I:dnssec:checking a non-cachable NODATA works (95)
I:dnssec:checking a non-cachable NXDOMAIN works (96)
I:dnssec:checking dnssec-lookaside-validation works (97)
I:dnssec:checking that we can load a rfc2535 signed zone (98)
I:dnssec:checking that we can transfer a rfc2535 signed zone (99)
I:dnssec:checking that we can sign a zone with out-of-zone records (100)
I:dnssec:checking that we can sign a zone (NSEC3) with out-of-zone records (101)
I:dnssec:checking NSEC3 signing with empty nonterminals above a delegation (102)
I:dnssec:checking that dnsssec-signzone updates originalttl on ttl changes (103)
I:dnssec:checking dnssec-signzone keeps valid signatures from removed keys (104)
I:dnssec:checking dnssec-signzone -R purges signatures from removed keys (105)
I:dnssec:checking dnssec-signzone keeps valid signatures from inactive keys (106)
I:dnssec:checking dnssec-signzone -Q purges signatures from inactive keys (107)
I:dnssec:checking dnssec-signzone retains unexpired signatures (108)
I:dnssec:checking dnssec-signzone purges RRSIGs from formerly-owned glue (nsec) (109)
I:dnssec:checking dnssec-signzone purges RRSIGs from formerly-owned glue (nsec3) (110)
I:dnssec:checking dnssec-signzone output format (111)
I:dnssec:checking TTLs are capped by dnssec-signzone -M (112)
I:dnssec:checking dnssec-signzone -N date (113)
I:dnssec:checking validated data are not cached longer than originalttl (114)
I:dnssec:checking rndc secroots (115)
I:dnssec:checking RRSIG query from cache (116)
I:dnssec:checking RRSIG query not in cache (117)
I:dnssec:checking NSEC3 zone with mismatched NSEC3PARAM / NSEC parameters (118)
I:dnssec:checking optout NSEC3 referral with only insecure delegations (119)
I:dnssec:checking optout NSEC3 NXDOMAIN with only insecure delegations (120)
I:dnssec:checking optout NSEC3 nodata with only insecure delegations (121)
I:dnssec:checking that a zone finishing the transition from RSASHA1 to RSASHA256 validates secure (122)
I:dnssec:checking positive and negative validation with negative trust anchors (123)
I:dnssec:ns4 Negative trust anchor added: bogus.example/_default, expires 06-Mar-2018 07:43:35.000
I:dnssec:ns4 Negative trust anchor added: badds.example/_default, expires 06-Mar-2018 07:43:27.000
I:dnssec:ns4 Negative trust anchor added: secure.example/_default, expires 06-Mar-2018 07:43:28.000
I:dnssec:ns4 Negative trust anchor added: fakenode.secure.example/_default, expires 06-Mar-2018 07:43:29.000
I:dnssec:ns4 server reload successful
I:dnssec:dumping secroots
I:dnssec:waiting for NTA rechecks/expirations
I:dnssec:testing NTA removals (124)
I:dnssec:ns4 Negative trust anchor added: badds.example/_default, expires 06-Mar-2018 07:43:51.000
I:dnssec:remove non-existent NTA three times
I:dnssec:testing NTA with bogus lifetimes (125)
I:dnssec:check with no nta lifetime specified
I:dnssec:check with bad nta lifetime
I:dnssec:check with too long nta lifetime
I:dnssec:testing NTA persistence across restarts (126)
I:dnssec:ns4 Negative trust anchor added: bogus.example/_default, expires 06-Mar-2018 07:44:12.000
I:dnssec:ns4 Negative trust anchor added: badds.example/_default, expires 06-Mar-2018 07:43:53.000
I:dnssec:killing ns4 with SIGTERM
I:dnssec:waiting till 14s have passed since NTAs were added before restarting ns4
I:dnssec:restarted server ns4
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully startup
I:dnssec:testing loading regular attribute from NTA file (127)
I:dnssec:killing ns4 with SIGTERM
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully shutdown
I:dnssec:restarted server ns4
I:dnssec:waiting till 10s have passed after ns4 was restarted
I:dnssec:failed - NTA persistence: loading regular NTAs failed
I:dnssec:testing loading forced attribute from NTA file (128)
I:dnssec:killing ns4 with SIGTERM
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully shutdown
I:dnssec:restarted server ns4
I:dnssec:waiting till 10s have passed after ns4 was restarted
I:dnssec:testing loading out of bounds lifetime from NTA file (129)
I:dnssec:killing ns4 with SIGTERM
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully shutdown
I:dnssec:restarted server ns4
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully startup
I:dnssec:completed NTA tests
I:dnssec:running DNSSEC update test
I:dnssec:Add a name
I:dnssec:Delete the name
I:dnssec:All update tests successful.
I:dnssec:checking managed key maintenance has not started yet (130)
I:dnssec:switching to automatic root key configuration
I:dnssec:checking managed key maintenance timer has now started (131)
I:dnssec:checking positive validation NSEC (132)
I:dnssec:checking positive validation NSEC3 (133)
I:dnssec:checking positive validation OPTOUT (134)
I:dnssec:checking negative validation (135)
I:dnssec:checking that root DS queries validate (136)
I:dnssec:checking that DS at a RFC 1918 empty zone lookup succeeds (137)
I:dnssec:checking expired signatures remain with "allow-update { none; };" and no keys available (138)
I:dnssec:checking expired signatures do not validate (139)
I:dnssec:checking that the NSEC3 record for the apex is properly signed when a DNSKEY is added via UPDATE (140)
I:dnssec:checking that the NSEC record is properly generated when DNSKEY are added via auto-dnssec (141)
I:dnssec:checking that the NSEC3 record is properly generated when DNSKEY are added via auto-dnssec (142)
I:dnssec:checking that signing records have been marked as complete (143)
I:dnssec:check that 'rndc signing' without arguments is handled (144)
I:dnssec:check that 'rndc signing -list' without zone is handled (145)
I:dnssec:check that 'rndc signing -clear' without additional arguments is handled (146)
I:dnssec:check that 'rndc signing -clear all' without zone is handled (147)
I:dnssec:check that 'rndc signing -nsec3param' without additional arguments is handled (148)
I:dnssec:check that 'rndc signing -nsec3param none' without zone is handled (149)
I:dnssec:check that 'rndc signing -nsec3param 1' without additional arguments is handled (150)
I:dnssec:check that 'rndc signing -nsec3param 1 0' without additional arguments is handled (151)
I:dnssec:check that 'rndc signing -nsec3param 1 0 0' without additional arguments is handled (152)
I:dnssec:check that 'rndc signing -nsec3param 1 0 0 -' without zone is handled (153)
I:dnssec:check that 'rndc signing -nsec3param' works with salt (154)
I:dnssec:check that 'rndc signing -nsec3param' works without salt (155)
I:dnssec:check that 'rndc signing -nsec3param' works with 'auto' as salt (156)
I:dnssec:check that 'rndc signing -nsec3param' with 'auto' as salt again generates a different salt (157)
I:dnssec:check rndc signing -list output (158)
I:dnssec:clear signing records (159)
I:dnssec:checking that a insecure zone beneath a cname resolves (160)
I:dnssec:checking that a secure zone beneath a cname resolves (161)
I:dnssec:checking dnskey query with no data still gets put in cache (162)
I:dnssec:check that a split dnssec dnssec-signzone work (163)
I:dnssec:check that a smart split dnssec dnssec-signzone work (164)
I:dnssec:check that NOTIFY is sent at the end of NSEC3 chain generation (165)
I:dnssec:sleeping ....
I:dnssec:sleeping ....
I:dnssec:check dnssec-dsfromkey from stdin (166)
I:dnssec:check dnssec-dsfromkey error message when keyfile is not found (167)
I:dnssec:testing soon-to-expire RRSIGs without a replacement private key (168)
I:dnssec:testing new records are signed with 'no-resign' (169)
I:dnssec:testing expiring records aren't resigned with 'no-resign' (170)
I:dnssec:testing updates fail with no private key (171)
I:dnssec:testing legacy upper case signer name validation (172)
I:dnssec:testing that we lower case signer name (173)
I:dnssec:testing TTL is capped at RRSIG expiry time (174)
I:dnssec:ns3 zone reload queued
I:dnssec:testing TTL is capped at RRSIG expiry time for records in the additional section (175)
I:dnssec:testing TTL of about to expire RRsets with dnssec-accept-expired yes; (176)
I:dnssec:testing TTL of expired RRsets with dnssec-accept-expired yes; (177)
I:dnssec:testing TTL is capped at RRSIG expiry time for records in the additional section with dnssec-accept-expired yes; (178)
I:dnssec:testing DNSKEY lookup via CNAME (179)
I:dnssec:testing KEY lookup at CNAME (present) (180)
I:dnssec:testing KEY lookup at CNAME (not present) (181)
I:dnssec:testing DNSKEY lookup via DNAME (182)
I:dnssec:testing KEY lookup via DNAME (183)
I:dnssec:check that named doesn't loop when all private keys are not available (184)
I:dnssec:check against against missing nearest provable proof (185)
I:dnssec:check that key id are logged when dumping the cache (186)
I:dnssec:check KEYDATA records are printed in human readable form in key zone (187)
I:dnssec:check dig's +nocrypto flag (188)
I:dnssec:check simultaneous inactivation and publishing of dnskeys removes inactive signature (189)
I:dnssec:check that increasing the sig-validity-interval resigning triggers re-signing (190)
I:dnssec:check insecure delegation between static-stub zones (191)
I:dnssec:check the acceptance of seconds as inception and expiration times (192)
I:dnssec:check the correct resigning time is reported in zonestatus (193)
I:dnssec:check that split rrsigs are handled (194)
I:dnssec:check that 'dnssec-keygen -S' works for all supported algorithms (195)
I:dnssec:check that CDS records are signed using KSK by dnssec-signzone (196)
I:dnssec:check that CDS records are not signed using ZSK by dnssec-signzone -x (197)
I:dnssec:checking that positive unknown NSEC3 hash algorithm does validate (198)
I:dnssec:check that CDS records are signed using KSK by with dnssec-auto (199)
I:dnssec:check that a lone non matching CDS record is rejected (200)
I:dnssec:check that CDS records are signed using KSK when added by nsupdate (201)
I:dnssec:check that CDS records are signed only using KSK when added by
I:dnssec:nsupdate when dnssec-dnskey-kskonly is yes (202)
I:dnssec:checking that positive unknown NSEC3 hash algorithm with OPTOUT does validate (203)
I:dnssec:check that a non matching CDS record is accepted with a matching CDS record (204)
I:dnssec:checking that negative unknown NSEC3 hash algorithm does not validate (205)
I:dnssec:check that CDNSKEY records are signed using KSK by dnssec-signzone (206)
I:dnssec:check that CDNSKEY records are not signed using ZSK by dnssec-signzone -x (207)
I:dnssec:checking that negative unknown NSEC3 hash algorithm with OPTOUT does not validate (208)
I:dnssec:check that CDNSKEY records are signed using KSK by with dnssec-auto (209)
I:dnssec:checking that unknown DNSKEY algorithm validates as insecure (210)
I:dnssec:check that a lone non matching CDNSKEY record is rejected (211)
I:dnssec:checking that unknown DNSKEY algorithm + unknown NSEC3 has algorithm validates as insecure (212)
I:dnssec:check that CDNSKEY records are signed using KSK when added by nsupdate (213)
I:dnssec:check that CDNSKEY records are signed only using KSK when added by
I:dnssec:nsupdate when dnssec-dnskey-kskonly is yes (214)
I:dnssec:checking initialization with a revoked managed key (215)
I:dnssec:check that a non matching CDNSKEY record is accepted with a matching CDNSKEY record (216)
I:dnssec:check that RRSIGs are correctly removed from apex when RRset is removed NSEC (217)
I:dnssec:check that RRSIGs are correctly removed from apex when RRset is removed NSEC3 (218)
I:dnssec:check that a named managed zone that was signed 'in-the-future' is re-signed when loaded (219)
I:dnssec:check that trust-anchor-telemetry queries are logged (220)
I:dnssec:check that _ta-XXXX trust-anchor-telemetry queries are logged (221)
I:dnssec:check that _ta-AAAA trust-anchor-telemetry are not sent when disabled (222)
I:dnssec:check that KEY-TAG trust-anchor-telemetry queries are logged (223)
I:dnssec:check that the view is logged in messages from the validator when using views (224)
I:dnssec:exit status: 1
R:dnssec:FAIL
E:dnssec:Tue Mar 6 07:46:29 UTC 2018
```
Contents of `bin/tests/system/dnssec/` from the first 3 jobs listed above are [attached](/uploads/0c726aec02894931d792e765804347b9/dnssec.tar.gz).BIND 9.13.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/130Use ccache to speed-up Gitlab CI builds2018-03-08T14:22:12ZOndřej SurýUse ccache to speed-up Gitlab CI buildsOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/131Add util/check-changes to CI for master2018-03-08T02:24:42ZMark AndrewsAdd util/check-changes to CI for masterhttps://gitlab.isc.org/isc-projects/bind9/-/issues/132fix changes entry2018-03-08T01:57:39ZMark Andrewsfix changes entryhttps://gitlab.isc.org/isc-projects/bind9/-/issues/133Update util/check-changes to work on release branches.2018-03-08T10:16:40ZMark AndrewsUpdate util/check-changes to work on release branches.https://gitlab.isc.org/isc-projects/bind9/-/issues/134Crash in BIND 9.12.0-RedHat-9.12.0-1.el7.02019-04-26T09:49:56ZJakob DhondtCrash in BIND 9.12.0-RedHat-9.12.0-1.el7.0I'd like to report a crash on a production host (ns2.switch.ch).
All the necessary info can be found here: [REDACTED]
Thanks,
JakobI'd like to report a crash on a production host (ns2.switch.ch).
All the necessary info can be found here: [REDACTED]
Thanks,
JakobMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/135Add basic unit tests for update_sigs()2018-05-10T16:50:52ZMichał KępieńAdd basic unit tests for update_sigs()The static [`update_sigs()`](https://gitlab.isc.org/isc-projects/bind9/blob/c9f4bdde949dd337f900f47995537076d2370d1d/lib/dns/zone.c#L7345-7391) function could use some basic unit tests so that it can be safely [refactored](!10).The static [`update_sigs()`](https://gitlab.isc.org/isc-projects/bind9/blob/c9f4bdde949dd337f900f47995537076d2370d1d/lib/dns/zone.c#L7345-7391) function could use some basic unit tests so that it can be safely [refactored](!10).BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/136cds system test fails intermittently2018-03-19T22:15:52ZMichał Kępieńcds system test fails intermittentlyThe failure mode below has been observed 2 times so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3108
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3340
```
S:cds:Tue Mar 6 15:58:36 UTC 2018
T:cds:1:A
A:cds:System test...The failure mode below has been observed 2 times so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3108
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3340
```
S:cds:Tue Mar 6 15:58:36 UTC 2018
T:cds:1:A
A:cds:System test cds
I:cds:PORTRANGE:6200 - 6299
I:cds:usage (1)
I:cds:need a DS file (2)
I:cds:name of dsset in directory (3)
I:cds:load a file (4)
I:cds:load DS records (5)
I:cds:missing DNSKEY (6)
I:cds:sigs too old (7)
I:cds:sigs too old, verbosely (8)
I:cds:old sigs are allowed (9)
I:cds:no CDS/CDNSKEY records (10)
I:cds:no child records, verbosely (11)
I:cds:unsigned CDS (12)
I:cds:correct signature inception time (13)
I:cds:in-place reads modification time (14)
I:cds:in-place output correct modification time (15)
D:stderr did not match ''
D:bad mtime 3610 at checkmtime.pl line 15.
I:cds:failed
D:exit status does not match 0
I:cds:failed
I:cds:in-place backup correct modification time (16)
D:stderr did not match ''
D:bad mtime 7210 at checkmtime.pl line 15.
I:cds:failed
D:exit status does not match 0
I:cds:failed
I:cds:in-place correct output (17)
I:cds:in-place backup unmodified (18)
I:cds:one mangled DS (19)
I:cds:other mangled DS (20)
I:cds:both mangled DS (21)
I:cds:mangle RRSIG CDS by ZSK (22)
I:cds:mangle RRSIG CDS by KSK (23)
I:cds:mangle CDS 1 (24)
I:cds:inconsistent digests (25)
I:cds:inconsistent algorithms (26)
I:cds:add DS records (27)
I:cds:update add (28)
I:cds:remove DS records (29)
I:cds:update del (30)
I:cds:swap DS records (31)
I:cds:update swap (32)
I:cds:TTL from -T (33)
I:cds:update TTL from -T (34)
I:cds:update TTL from dsset (35)
I:cds:TTL from -T overrides dsset (36)
I:cds:stable DS record order (changes) (37)
I:cds:CDNSKEY default algorithm (38)
I:cds:CDNSKEY SHA1 (39)
I:cds:CDNSKEY two algorithms (40)
I:cds:CDNSKEY two algorithms, reversed (41)
I:cds:CDNSKEY and CDS (42)
I:cds:prefer CDNSKEY (43)
I:cds:exit status: 4
R:cds:FAIL
E:cds:Tue Mar 6 15:59:05 UTC 2018
```
Contents of `bin/tests/system/cds/` from both jobs listed above are [attached](/uploads/9472df3aa2bfa776e40e1a8ae20737c6/cds.tar.gz).BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/137Remove support for systems without ftello/fseeko2018-03-19T22:14:27ZOndřej SurýRemove support for systems without ftello/fseeko`fseeko` and `ftello` conforms to SUSv2, POSIX.1-2001. The `configure.in` says:
```
# BSDI doesn't have ftello fseeko
AC_CHECK_FUNCS(ftello fseeko)
```
The last version of BSD/OS was released in 2003, henceforth I believe it's safe to...`fseeko` and `ftello` conforms to SUSv2, POSIX.1-2001. The `configure.in` says:
```
# BSDI doesn't have ftello fseeko
AC_CHECK_FUNCS(ftello fseeko)
```
The last version of BSD/OS was released in 2003, henceforth I believe it's safe to remove this workaround.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/138Tweak CI settings2018-03-09T17:13:27ZMichał KępieńTweak CI settingsOur current CI configuration has two issues described below.
# ccache is used ineffectively
`gitlab-runner` cache is effectively a ZIP file passed between jobs. Creating a ZIP archive containing a ccache directory, potentially contain...Our current CI configuration has two issues described below.
# ccache is used ineffectively
`gitlab-runner` cache is effectively a ZIP file passed between jobs. Creating a ZIP archive containing a ccache directory, potentially containing hundreds of thousands of files taking up several gigabytes of storage space is a bad idea.
Our current CI configuration also causes the ccache directory to be treated as a build artifact, which only makes things worse.
What we should do instead is to stop using the `cache` directive altogether, create a ccache directory on each runner and mount it inside containers. This will allow ccache data to persist between jobs without requiring it to be packed into a ZIP file at the end of each job.
As a side note for posterity, it is critical for `/etc/gitlab-runner/config.toml` to contain `volumes = ["/cache"]` for the `cache` directive to actually work, at least with Docker. Otherwise, `gitlab-runner` will just create a ZIP file when a job is finished, store it in `/cache/<namespace>/<project>` and then tear the container down, obliterating the cache it just created. Adding the `volume` line mentioned above causes `/cache` to be persisted.
# `make` uses fixed concurrency settings
Our CI jobs currently always use `make -j6` for building and `make -j8` for running system tests. Meanwhile, concurrency settings need to be tweaked separately for each runner to ensure stability. We should modify our `.gitlab-ci.yml` to fetch the number of parallel `make` jobs to use from environment variables which will subsequently be set by each runner through its configuration file.
There are three rules I can think of for tweaking concurrency-related settings:
1. With ccache being used, building becomes more (though not fully, of course) I/O-bound than CPU-bound.
1. As a rule of thumb, it should be assumed that each parallel system test being executed uses about 0.5 GB of RAM.
1. Currently, total system test execution time plateaus around `make -j8` because some tests just take a *long* time to run.
Apart from the above, the number of concurrent jobs `make` is allowed to use while building and testing has to be considered together with the `concurrent` setting in `/etc/gitlab-runner/config.toml` which limits the number of CI jobs allowed to be run concurrently at any time on a given runner.
Considering the above, an optimal CI machine would have:
* **8+ CPU cores**: 8 cores allow concurrent compilation for two OS images using `make -j4` without putting to much strain on the host (ccache storage is not infinite, so we cannot rely on everything being cached beforehand), which sounds like a bare minimum; more cores would enable quicker pipeline completion in case multiple branches and/or more OS images are to be processed concurrently,
* **fast storage** (or lots of RAM, so that ramdisks can be used for ccache data and/or compilation), to let ccache shine,
* **more than 8 GB of RAM**: with tests for two OS images running concurrently, each image using `make -j8`, top RAM utilization around 8 GB may occur (2 * 8 * 0.5), which would lead to swapping; the more RAM the machine has, the more concurrent test phase jobs (e.g. for different branches and/or different OS images) it will be able to handle (though more RAM itself will not cause system tests to complete faster because increasing the number of parallel jobs used while testing beyond 8 has virtually no effect).
In any case, there are a few trade-offs to consider here, so allowing runner-specific concurrency settings in our `.gitlab-ci.yml` sounds like a good idea no matter what machine(s) we will be using for CI in the end.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/139Tests for IDNA2008 (libidn2)2018-04-04T13:52:44ZOndřej SurýTests for IDNA2008 (libidn2)The following discussion from !56 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/56#note_4595):
> This mostly looks fine to me (after the nits being fixed), but t...The following discussion from !56 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/56#note_4595):
> This mostly looks fine to me (after the nits being fixed), but the biggest issue before merging the code would be having tests for the code.
>
> Could you come up with couple of tests cases (IDNA2008 compliant, and also some tests that should "fail" because the encoding is broken, etc.) and either write the tests yourself (preferred :)), or just shove it to us and we'll take care of the tests. But they need to be present before the final merge.BIND-9.13.0Stephen MorrisStephen Morrishttps://gitlab.isc.org/isc-projects/bind9/-/issues/140Add safeguards to dnssec key utilities2021-10-04T12:31:48ZBrian ConryAdd safeguards to dnssec key utilitiesWarn when generating DS records for new keys with a different set of algorithm types than the current set of DS recordsWarn when generating DS records for new keys with a different set of algorithm types than the current set of DS recordshttps://gitlab.isc.org/isc-projects/bind9/-/issues/141RT 43435 - Upload BIND Python module to pypi, package for BIND users2021-10-04T12:33:06ZVicky Riskvicky@isc.orgRT 43435 - Upload BIND Python module to pypi, package for BIND usersRT 43435 - text below is migrated from bugsRT
On Wed, May 3, 2017 at 1:04 PM, Vicky Risk via RT <bind9-bugs@isc.org> wrote:
We discussed uploading a python module for BIND to the pypi repository in our development meeting today. ... ...RT 43435 - text below is migrated from bugsRT
On Wed, May 3, 2017 at 1:04 PM, Vicky Risk via RT <bind9-bugs@isc.org> wrote:
We discussed uploading a python module for BIND to the pypi repository in our development meeting today. ... The open question we are considering is whether to submit just the RNDC components, or <more>. I think Evan is wondering whether it might cause user confusion having multiple different copies of the python library (assuming they are also running BIND).
.......
I wasn't aware the python library was going to be distributed with BIND... but here are some thoughts on that:
A very common (nearly standard) way of operating with python is to work inside what's referred to as a "python virtual environment," or virtualenv/venv. In this environment, libraries and other python packages required by one's work can be installed without interfering with the system packages.. this is very important, for example, when working on tools that have conflicting package (version) requirements.
The packages inside a venv are typically installed using 'pip'.. the python package manager that uses pypi as its back-end.
Getting something installed into a venv that is not on pypi is irritating at best, and occasionally difficult to do. This is especially true for automated deployments where the virtualenv is used in production operations.
For a real-world example, the ldns python bindings are only shipped with the ldns source code, and not in pypi, and as a result I need to have a very compelling reason to need them over any other DNS library (and over just shelling out to an ldns binary) in order to deal with the complexities of working with them.
To view this from another angle: If BIND's 'make install' places the RNDC python libraries on the system in such a way that they're visible to/registered with pip, then end users aren't going to find anything confusing .. because as far as pip is concerned it doesn't matter where the library came from. If the RNDC python library is not visible to/registered with pip, then BIND shouldn't be installing it that way.. it will cause confusion regardless of whether the library is available on pypi or not.
--------
Adding Matt Pounsett as stakeholder, because he has offered us a package that includes just the python RNDC stuff that is ready to upload.
Matt, I can’t find the email from you about the Python package for the BIND RNDC interface. Did you submit it to bind-bugs@isc.org? If you want to reply to this ticket and attach it, it will be easier for us to find it to work on.
I didn't.. this started as a conversation with Ray, and so I emailed him about it. The work I've done so far is in a private repo on github. Github, because it seemed a reasonable place to work on it, and private so that I don't inadvertently share it with anyone other than ISC prior to ISC applying a license to it.
My email to Ray included an offer to add ISC employees' accounts to access the repository and/or hand over full ownership of the repository. Whichever you like. The repo is at <https://github.com/mpounsett/rndc> but that won't be accessible until we do something with access.
There are still a few small steps to be taken before it's ready for upload: notably decisions I couldn't make on behalf of ISC about licensing, development status indicators, etc.https://gitlab.isc.org/isc-projects/bind9/-/issues/142add more checks to precheck CI stage2018-08-24T20:18:53ZEvan Huntadd more checks to precheck CI stageIt should also call util/checklibs.sh, to make sure that needed include files are present and .def files are up to date.
It could also check xmllint when documentation is updated, look for $Id$ tags that haven't been removed, etc.It should also call util/checklibs.sh, to make sure that needed include files are present and .def files are up to date.
It could also check xmllint when documentation is updated, look for $Id$ tags that haven't been removed, etc.https://gitlab.isc.org/isc-projects/bind9/-/issues/143rndc command crashes bind-9.10.6-P1 - ev_ratelink.prev on Debian 92018-03-10T16:03:47ZGhost Userrndc command crashes bind-9.10.6-P1 - ev_ratelink.prev on Debian 9Good evening,
Running fresh install of Debian 9 (x64), named is running in background, but when issuing rndc status (any command really) it crashes with:
task.c:551: REQUIRE(!((void *)((event)->ev_ratelink.prev) != (void *)(-1))) faile...Good evening,
Running fresh install of Debian 9 (x64), named is running in background, but when issuing rndc status (any command really) it crashes with:
task.c:551: REQUIRE(!((void *)((event)->ev_ratelink.prev) != (void *)(-1))) failed, back trace
#0 0x7f2a69b070e4 in ??
#1 0x7f2a69b0704a in ??
#2 0x7f2a69b2c4aa in ??
#3 0x7f2a6a378cd8 in ??
#4 0x7f2a69b2a570 in ??
#5 0x7f2a69247494 in ??
#6 0x7f2a68f89aff in ??
Aborted
Here's the named -V dump:
BIND 9.10.6-P1 <id:f941e36>
running on Linux x86_64 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
built by make with '--without-gost' '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--with-libtool' '--mandir=/usr/man' '--enable-shared' '--disable-static' '--with-libxml2=no' '--enable-threads' '--with-openssl' '--enable-developer'
compiled by GCC 6.3.0 20170516
compiled with OpenSSL version: OpenSSL 1.1.0f 25 May 2017
linked to OpenSSL version: OpenSSL 1.1.0f 25 May 2017
Obtained the core and dropped it through gdb and issued
thread apply all bt full
[gdb_dump.txt](/uploads/b3a791b04155edd8eacff57bccaf46f7/gdb_dump.txt)
I am able to install bind-9.10.6-P1 on a fresh install of Debian 8 (x64) with no problems.
Thank you for reviewing this.
Erichttps://gitlab.isc.org/isc-projects/bind9/-/issues/144CVE-2016-2776 and CVE-2015-46202018-03-13T14:39:26ZGhost UserCVE-2016-2776 and CVE-2015-4620Dear
The bind version we used is 9.10.0-P1.We want to fix the loophole(CVE-2016-2776 and CVE-2015-4620).and I have compared the changes between the problem version and fixed version.I can't ensure the specific modification points of the...Dear
The bind version we used is 9.10.0-P1.We want to fix the loophole(CVE-2016-2776 and CVE-2015-4620).and I have compared the changes between the problem version and fixed version.I can't ensure the specific modification points of the loopholes.Can you apply the the specific modification points of the loopholes(CVE-2016-2776 and CVE-2015-4620)?Please.
best regards!https://gitlab.isc.org/isc-projects/bind9/-/issues/145different RRSIG expiry for DNSKEY2018-08-02T19:33:02ZEvan Huntdifferent RRSIG expiry for DNSKEYAs reported by @cathya, a customer has a use case in which they keep the KSK offline most of the time, but bring it online periodically so that the zone's DNSKEY RRSIGs can be refreshed. They'd like to have a longer signature validity pe...As reported by @cathya, a customer has a use case in which they keep the KSK offline most of the time, but bring it online periodically so that the zone's DNSKEY RRSIGs can be refreshed. They'd like to have a longer signature validity period for the DNSKEY only. This is similar to what's done by `dnssec-signzone -X`, but done by the automatic signing process in `named`.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/146Fix existing auth ECS support as much as possible2018-03-28T16:08:47ZGhost UserFix existing auth ECS support as much as possibleBIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/147Add Windows to GitLab CI2022-11-10T14:18:14ZOndřej SurýAdd Windows to GitLab CIOctober 2019 (9.11.12, 9.14.7, 9.15.5)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/148Add BSDs to GitLab CI2019-11-05T11:03:22ZOndřej SurýAdd BSDs to GitLab CINovember 2019 (9.11.13, 9.14.8, 9.15.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/150Remove workarounds for servers that are not EDNS compliant.2019-09-04T23:48:20ZMark AndrewsRemove workarounds for servers that are not EDNS compliant.BIND-9.13.4Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/151arpaname segfault on OpenBSD 6.2 i3862018-03-15T18:55:12ZCarsten Strotmannarpaname segfault on OpenBSD 6.2 i386### Summary
the command "arpaname" segfaults and writes a core file when used
OpenBSD 6.2 i386 BIND 9.12.0
### Steps to reproduce
call arpaname with an ipv4 or ipv6 address
### What is the current *bug* behavior?
arpaname segfauls ...### Summary
the command "arpaname" segfaults and writes a core file when used
OpenBSD 6.2 i386 BIND 9.12.0
### Steps to reproduce
call arpaname with an ipv4 or ipv6 address
### What is the current *bug* behavior?
arpaname segfauls and writes a core dump file
```
# arpaname 2001:db8::1
Segmentation fault (core dumped)
```
### What is the expected *correct* behavior?
arpaname prints the arpaname of the ip address
### Relevant logs and/or screenshots
````
(gdb) bt
#0 malloc (size=65536) at /usr/src/lib/libc/stdlib/malloc.c:1165
#1 0x024efde9 in __smakebuf (fp=0x22453798) at /usr/src/lib/libc/stdio/makebuf.c:62
#2 0x024ef113 in __swsetup (fp=0x22453798) at /usr/src/lib/libc/stdio/wsetup.c:73
#3 0x024dccea in __vfprintf (fp=0x22453798, fmt0=0x358d8000 "%X.%X.", ap=0xcf7c2468 "\001") at /usr/src/lib/libc/stdio/vfprintf.c:461
#4 0x024dfabf in vfprintf (fp=0x22453798, fmt0=0x358d8000 "%X.%X.", ap=0xcf7c2468 "\001") at /usr/src/lib/libc/stdio/vfprintf.c:267
#5 0x024c08e9 in fprintf (fp=0x22453798, fmt=0x358d8000 "%X.%X.") at /usr/src/lib/libc/stdio/fprintf.c:45
#6 0x158d8d1d in main (argc=Cannot access memory at address 0x0
) at arpaname.c:38
````https://gitlab.isc.org/isc-projects/bind9/-/issues/152auto-insert child DS records into parent zones when both are being mastered l...2022-06-05T19:00:48ZBrian Conryauto-insert child DS records into parent zones when both are being mastered locally and having DNSSEC maintained by BIND### Description
Coming from an ops ticket:
On Thu Mar 15 07:28:34 2018, michal@isc.org wrote:
[...]
> There is a DS for 57.20.149.in-addr.arpa. at 20.149.in-addr-arpa., but
> 57.20.149.in-addr.arpa. is not signed:
[...]
> Thus, everythi...### Description
Coming from an ops ticket:
On Thu Mar 15 07:28:34 2018, michal@isc.org wrote:
[...]
> There is a DS for 57.20.149.in-addr.arpa. at 20.149.in-addr-arpa., but
> 57.20.149.in-addr.arpa. is not signed:
[...]
> Thus, everything beneath 57.20.149.in-addr.arpa. is currently bogus.
On Thu Mar 15 08:34:28 2018, dmahoney wrote:
[...]
> I should note that we're still dependent on old-ass perl scripts
> because BIND still lacks the ability to auto-insert child DS records
> into parent zones when both are managed by BIND. This is the missing
> link in all the key-management magic we keep offering up.
### Request
Create the missing link.
I should think that it would even be possible if the child zone is a secondary but with inline signing.
I'm less certain, but wonder if it might be permissible even if the parent is secondary but with inline signing.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/153Review the needed libraries to link...2020-04-28T09:09:42ZOndřej SurýReview the needed libraries to link...f.e. arpaname links to libisc (and friends) and there's really no reason to (it just uses `inet_pton` and `fprintf`). There might be more.
It's probably easy (with right tools) to review the symbols actually needed in the binary and re...f.e. arpaname links to libisc (and friends) and there's really no reason to (it just uses `inet_pton` and `fprintf`). There might be more.
It's probably easy (with right tools) to review the symbols actually needed in the binary and remove the unnecessary linking.https://gitlab.isc.org/isc-projects/bind9/-/issues/154Build failure on OSX with --disable-atomic --enable-developer2018-03-19T22:14:14ZCurtis BlackburnBuild failure on OSX with --disable-atomic --enable-developer<!--
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
BIND9 fails to build on OSX with --disable-atomic and --enable developer
see output at: https://jenkins.isc.org/view/BIND/job/bind9-master-macmini--disable-atomic/513/console
### Steps to reproduce
$ ./configure --disable-atomic --without-zlib --with-atf=/Users/jenkins/opt/atf --with-openssl=/usr/local/opt/openssl/ --with-libxml2=/usr/local/opt/libxml2 --enable-full-report --enable-developer
$ make
### What is the current *bug* behavior?
atomic_test.c:319:16: error: unused parameter 'tp' [-Werror,-Wunused-parameter]
ATF_TP_ADD_TCS(tp) {
^
1 error generated.
make[3]: *** [atomic_test.o] Error 1
### What is the expected *correct* behavior?
a successful build
### Relevant configuration files
none
### Relevant logs and/or screenshots
see https://jenkins.isc.org/view/BIND/job/bind9-master-macmini--disable-atomic/513/console
### Possible fixes
we probably need an UNUSED(tp) on line 320 of atomic_test.cBIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/155add version flag to all tools2021-10-04T12:35:42ZCarsten Strotmannadd version flag to all tools### Description
some BIND 9 tools (such as arpaname, named-checkconf, named-checkzone, named-rrchecker, maybe more) don't have a version information that can be printed out.
That makes it harder to identify old versions in the path (i...### Description
some BIND 9 tools (such as arpaname, named-checkconf, named-checkzone, named-rrchecker, maybe more) don't have a version information that can be printed out.
That makes it harder to identify old versions in the path (it would have helped me to identify the problem in issue #151 faster).
### Request
Give all BIND 9 tools / commandline commands a "-V" switch that prints out the BIND 9 release version the binary originated from.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/156Test Issue [ISC-support #12616]2018-03-21T16:02:17ZGhost UserTest Issue [ISC-support #12616]### Description
Please ignore this.
### Request
Please ignore this.
### Links / references### Description
Please ignore this.
### Request
Please ignore this.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/157Windows build fails2018-03-19T22:15:43ZCurtis BlackburnWindows build failsThe build fails on windows, because the sln file still references lib/tests, which was removed.
see: https://jenkins.isc.org/view/BIND/job/bind9-master-win2012-x64-systests/1072/consoleThe build fails on windows, because the sln file still references lib/tests, which was removed.
see: https://jenkins.isc.org/view/BIND/job/bind9-master-win2012-x64-systests/1072/consoleBIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/158crash at shutdown in rbtdb.c2020-05-20T20:49:34ZTony Finchcrash at shutdown in rbtdb.cDunno if this is related to #84 and/or my patch !71
```
2018-03-16.11:33:05.661 general: critical: rbtdb.c:1300: INSIST((((rbtdb->rdatasets[i]).head == ((void *)0)) ? isc_boolean_true : isc_boolean_false)) failed
2018-03-16.11:33:05.67...Dunno if this is related to #84 and/or my patch !71
```
2018-03-16.11:33:05.661 general: critical: rbtdb.c:1300: INSIST((((rbtdb->rdatasets[i]).head == ((void *)0)) ? isc_boolean_true : isc_boolean_false)) failed
2018-03-16.11:33:05.675 general: critical: exiting (due to assertion failure)
```
```
(gdb) bt
#0 0x00007ff885a46067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ff885a47448 in __GI_abort () at abort.c:89
#2 0x000055cefcca24c9 in assertion_failed (file=0x55cefcf1e8aa "rbtdb.c", line=1300, type=4246502448,
cond=0x55cefcf1c7b0 "(((rbtdb->rdatasets[i]).head == ((void *)0)) ? isc_boolean_true : isc_boolean_false)") at ./main.c:248
#3 0x000055cefce98a7a in isc_assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at assertions.c:49
#4 0x000055cefcd802c1 in free_rbtdb (rbtdb=0x7ff87c98d010, log=(unknown: 16), event=0x0) at rbtdb.c:1300
#5 0x000055cefcd832a6 in maybe_free_rbtdb (rbtdb=0x7ff87c98d010) at rbtdb.c:1416
#6 0x000055cefcd833b5 in detach (dbp=0x7ff87c989090) at rbtdb.c:1431
#7 0x000055cefcd22470 in dns_db_detach (dbp=dbp@entry=0x7ff87c989090) at db.c:164
#8 0x000055cefcd188d7 in cache_free (cache=0x7ff87c989010) at cache.c:385
#9 0x000055cefcd19eac in dns_cache_detach (cachep=<optimized out>) at cache.c:476
#10 0x000055cefce358d2 in destroy (view=0x7ff8781fcbf0) at view.c:413
#11 0x000055cefce36ab2 in dns_view_weakdetach (viewp=viewp@entry=0x7ff8788671e8) at view.c:689
#12 0x000055cefce40639 in zone_free (zone=zone@entry=0x7ff878866890) at zone.c:1144
#13 0x000055cefce5c728 in zone_shutdown (task=<optimized out>, event=<optimized out>) at zone.c:12845
#14 0x000055cefcebf237 in dispatch (manager=0x7ff887623010) at task.c:1138
#15 run (uap=0x7ff887623010) at task.c:1310
#16 0x00007ff88612b064 in start_thread (arg=0x7ff8844b4700) at pthread_create.c:309
#17 0x00007ff885af962d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
```https://gitlab.isc.org/isc-projects/bind9/-/issues/159Improve handling of inline signed zones with missing signing keys2018-04-25T19:25:27ZMichał KępieńImprove handling of inline signed zones with missing signing keys[RT #35502](https://bugs.isc.org/Ticket/Display.html?id=35502) points out that `named` treats inline signed zones with no associated signing keys in a somewhat confusing way. It boils down to two issues:
1. Bumped signed serial is logg...[RT #35502](https://bugs.isc.org/Ticket/Display.html?id=35502) points out that `named` treats inline signed zones with no associated signing keys in a somewhat confusing way. It boils down to two issues:
1. Bumped signed serial is logged even when an error occurs while updating signatures later on. To reproduce the problem, configure a zone like this:
```
zone "foo." {
type master;
file "foo.db";
inline-signing yes;
auto-dnssec maintain;
};
```
Do not create any signing keys, prepare zone file `foo.db` with serial number 1, start `named`. Then update `foo.db` by setting the serial number to 2 and run `rndc reload foo`. Something like this will be logged:
```
16-Mar-2018 23:33:46.839 zone foo/IN (unsigned): loaded serial 2
16-Mar-2018 23:33:46.839 zone foo/IN (signed): serial 2 (unsigned 2)
16-Mar-2018 23:33:46.840 zone foo/IN (signed): could not get zone keys for secure dynamic update
16-Mar-2018 23:33:46.840 zone foo/IN (signed): receive_secure_serial: not found
```
However, `named` will still be serving version 1 of the zone.
1. While configuring an inline signed zone without any signing keys results in an unsigned version of the zone being served, any subsequent updates to the raw zone are not reflected in the secure zone. While not creating signing keys for a zone explicitly designated to be signed may be considered a self-foot-shoot, it would arguably be a more user-friendly approach to keep applying raw zone changes to the secure zone as long as it is safe to do so, i.e. until signing keys become available (at which point applying raw zone changes without the accompanying signature changes would break existing signatures).BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/160Several BIND 9.11.3 system test fail on Solaris 10 (SunOS 5.10)2018-11-08T19:19:36ZGhost UserSeveral BIND 9.11.3 system test fail on Solaris 10 (SunOS 5.10)<!--
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).
-->
<pre>
### Summary
(Summarize the bug encountered concisely.)
bind 9.11.3 make test failed.
paltform:
SunOS pepper 5.10 Generic_142901-10 i86pc i386 i86pc
config line:
./configure --enable-shared --enable-threads --with-libtool --with-openssl=/usr/local/ssl
openssl,gcc and perl version:
OpenSSL 1.0.2n 7 Dec 2017
This is perl 5, version 24, subversion 0 (v5.24.0) built for i86pc-solaris
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
path etc:
PATH=/usr/local/perl5/bin:/usr/ccs/bin:/usr/local/ssl/bin:/usr/sfw/bin:/usr/sbin:/usr/bin:/usr/local/bin
### Steps to reproduce
(How one can reproduce the issue - this is very important.)
run as root.
cd /usr/local/src/bind/bind-9.11.3
./configure --enable-shared --enable-threads --with-libtool --with-openssl=/usr/local/ssl
make depend && make &&
make test
### What is the current *bug* behavior?
(What actually happens.)
no compile error but reports 3 errors (autosign, runtime and sfcache) in test.
results:
I:System test result summary:
I: 3 FAIL
I: 76 PASS
I: 5 SKIPPED
I: 1 UNTESTED
9.9.12 also reports 5 errors with same configuration.
I:System test result summary:
I: 5 FAIL
I: 58 PASS
I: 1 PKCS11ONLY
I: 4 SKIPPED
I: 1 UNTESTED
in 9.9.11-P1, no compile errors and no error reports in test.
### What is the expected *correct* behavior?
(What you should see instead.)
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
S:autosign:Thu Mar 15 13:41:14 JST 2018
T:autosign:1:A
A:System test autosign
I:generating keys and preparing zones
I:setting up zone: secure.example
I:setting up zone: secure.nsec3.example
I:setting up zone: nsec3.nsec3.example
I:setting up zone: optout.nsec3.example
I:setting up zone: nsec3.example
I:setting up zone: autonsec3.example
I:setting up zone: secure.optout.example
I:setting up zone: nsec3.optout.example
I:setting up zone: optout.optout.example
I:setting up zone: optout.example
I:setting up zone: rsasha256.example
I:setting up zone: rsasha512.example
I:setting up zone: nsec.example
I:setting up zone: oldsigs.example
I:setting up zone: nsec3-to-nsec.example
I:setting up zone: secure-to-insecure.example
I:setting up zone: secure-to-insecure2.example
I:setting up zone: prepub.example
I:setting up zone: ttl1.example
I:setting up zone: ttl2.example
I:setting up zone: ttl3.example
I:setting up zone: ttl4.example
I:setting up zone: delay.example
I:setting up zone: nozsk.example
I:setting up zone: inaczsk.example
I:setting up zone: reconf.example
I:setting up zone: sync.example
I:setting up zone: inacksk2.example
I:setting up zone: inaczsk2.example
I:setting up zone: inacksk3.example
I:setting up zone: inaczsk3.example
I:waiting for autosign changes to take effect
I:waiting ... (1)
I:waiting ... (2)
I:waiting ... (3)
I:done
I:check that zone with active and inactive KSK and active ZSK is properly
I: resigned after the active KSK is deleted - stage 1: Verify that DNSKEY
I: is initially signed with a KSK and not a ZSK. (1)
dnssec-settime: fatal: Invalid keyfile Kinacksk3.example.+007+%05uu: file not found
I:check that zone with active and inactive ZSK and active KSK is properly
I: resigned after the active ZSK is deleted - stage 1: Verify that zone
I: is initially signed with a ZSK and not a KSK. (2)
dnssec-settime: fatal: Invalid keyfile Kinaczsk3.example.+007+%05uu: file not found
I:checking NSEC->NSEC3 conversion prerequisites (3)
I:checking NSEC3->NSEC conversion prerequisites (4)
I:converting zones from nsec to nsec3
I:preset nsec3param in unsigned zone via nsupdate (5)
I:checking for nsec3param in unsigned zone (5)
I:checking for nsec3param signing record (6)
I:resetting nsec3param via rndc signing (7)
I:signing preset nsec3 zone
I:waiting for changes to take effect
I:converting zone from nsec3 to nsec
I:waiting for change to take effect
I:checking that expired RRSIGs from missing key are not deleted (8)
I:checking that expired RRSIGs from inactive key are not deleted (9)
I:checking that non-replaceable RRSIGs are logged only once (missing private key) (10)
I:checking that non-replaceable RRSIGs are logged only once (inactive private key) (11)
I:dumping zone files
I:checking expired signatures were updated (12)
I:checking NSEC->NSEC3 conversion succeeded (13)
I:checking direct NSEC3 autosigning succeeded (14)
I:checking NSEC->NSEC3 conversion failed with NSEC-only key (15)
I:checking NSEC3->NSEC conversion succeeded (16)
I:checking NSEC3->NSEC conversion with 'rndc signing -nsec3param none' (17)
I:checking TTLs of imported DNSKEYs (no default) (18)
I:checking TTLs of imported DNSKEYs (with default) (19)
I:checking TTLs of imported DNSKEYs (mismatched) (20)
I:checking TTLs of imported DNSKEYs (existing RRset) (21)
I:checking positive validation NSEC (22)
I:checking positive validation NSEC3 (23)
I:checking positive validation OPTOUT (24)
I:checking negative validation NXDOMAIN NSEC (25)
I:checking negative validation NXDOMAIN NSEC3 (26)
I:checking negative validation NXDOMAIN OPTOUT (27)
I:checking negative validation NODATA NSEC (28)
I:checking negative validation NODATA NSEC3 (29)
I:checking negative validation NODATA OPTOUT (30)
I:checking 1-server insecurity proof NSEC (31)
I:checking 1-server negative insecurity proof NSEC (32)
I:checking multi-stage positive validation NSEC/NSEC (33)
I:checking multi-stage positive validation NSEC/NSEC3 (34)
I:checking multi-stage positive validation NSEC/OPTOUT (35)
I:checking multi-stage positive validation NSEC3/NSEC (36)
I:checking multi-stage positive validation NSEC3/NSEC3 (37)
I:checking multi-stage positive validation NSEC3/OPTOUT (38)
I:checking multi-stage positive validation OPTOUT/NSEC (39)
I:checking multi-stage positive validation OPTOUT/NSEC3 (40)
I:checking multi-stage positive validation OPTOUT/OPTOUT (41)
I:checking empty NODATA OPTOUT (42)
I:checking 2-server insecurity proof (43)
I:checking 2-server insecurity proof with a negative answer (44)
I:checking security root query (45)
I:checking positive validation RSASHA256 NSEC (46)
I:checking positive validation RSASHA512 NSEC (47)
I:checking that positive validation in a privately secure zone works (48)
I:checking that negative validation in a privately secure zone works (49)
I:checking privately secure to nxdomain works (50)
I:checking that validation returns insecure due to revoked trusted key (51)
I:checking that revoked key is present (52)
I:checking that revoked key self-signs (53)
I:checking for unpublished key (54)
I:checking for activated but unpublished key (55)
I:checking that standby key does not sign records (56)
I:checking that deactivated key does not sign records (57)
I:checking insertion of public-only key (58)
I:checking key deletion (59)
I:checking secure-to-insecure transition, nsupdate (60)
I:checking secure-to-insecure transition, scheduled (61)
I:checking that serial number and RRSIGs are both updated (rt21045) (62)
I:preparing to test key change corner cases
I:removing a private key file
I:preparing ZSK roll
I:revoking key to duplicated key ID
dnssec-settime: warning: Permissions on the file ns2/Kbar.+005+30676.private have changed from 0644 to 0600 as a result of this operation.
I:waiting for changes to take effect
I:checking former standby key is now active (63)
I:checking former standby key has only signed incrementally (64)
I:checking that signing records have been marked as complete (65)
I:forcing full sign
I:waiting for change to take effect
I:checking former standby key has now signed fully (66)
I:checking SOA serial number has been incremented (67)
I:checking delayed key publication/activation (68)
I:checking scheduled key publication, not activation (69)
I:waiting for changes to take effect
I:checking scheduled key activation (70)
I:waiting for changes to take effect
I:checking former active key was removed (71)
I:checking private key file removal caused no immediate harm (72)
I:checking revoked key with duplicate key ID (failure expected) (73)
I:not yet implemented
I:checking key event timers are always set (74)
I:checking automatic key reloading interval (75)
I:checking for key reloading loops (76)
I:forcing full sign with unreadable keys (77)
I:test turning on auto-dnssec during reconfig (78)
I:ns3 zone 'reconf.example' reconfigured.
I:test CDS and CDNSKEY auto generation (79)
I:setting CDS and CDNSKEY deletion times and calling 'rndc loadkeys'
ns3/Ksync.example.+007+13704.key
ns3/Ksync.example.+007+13704.private
I:waiting for deletion to occur
I:checking that the CDS and CDNSKEY are deleted (80)
I:check that dnssec-settime -p Dsync works (81)
I:check that dnssec-settime -p Psync works (82)
I:check that zone with inactive KSK and active ZSK is properly autosigned (83)
I:check that zone with inactive ZSK and active KSK is properly autosigned (84)
I:check that zone with active and inactive KSK and active ZSK is properly
I: resigned after the active KSK is deleted - stage 2: Verify that DNSKEY
I: is now signed with the ZSK. (85)
I:failed
I:check that zone with active and inactive ZSK and active KSK is properly
I: resigned after the active ZSK is deleted - stage 2: Verify that zone
I: is now signed with the KSK. (86)
I:failed
I:exit status: 2
R:FAIL
E:autosign:Thu Mar 15 13:43:40 JST 2018
S:runtime:Thu Mar 15 14:16:31 JST 2018
T:runtime:1:A
A:System test runtime
I:verifying that named started normally (1)
I:verifying that named checks for conflicting listeners (2)
I:verifying that named checks for conflicting named processes (3)
I:verifying that 'lock-file none' disables process check (4)
I: checking that named refuses to reconfigure if managed-keys-directory is set and not writable (5)
I:failed
I: checking that named refuses to reconfigure if managed-keys-directory is unset and working directory is not writable (6)
I:failed
I: checking that named reconfigures if working directory is not writable but managed-keys-directory is (7)
I: shutting down existing named
I: checking that named refuses to start if managed-keys-directory is set and not writable (8)
I:failed
I: checking that named refuses to start if managed-keys-directory is unset and working directory is not writable (9)
I: checking that named starts if managed-keys-directory is writable and working directory is not writable (10)
I:exit status: 3
R:FAIL
E:runtime:Thu Mar 15 14:16:47 JST 2018
S:sfcache:Thu Mar 15 14:16:47 JST 2018
T:sfcache:1:A
A:System test sfcache
I:checking DNSSEC SERVFAIL is cached (0)
I:checking SERVFAIL is returned from cache (1)
I:checking that +cd bypasses cache check (2)
I:disabling server to force non-dnssec SERVFAIL
I:checking SERVFAIL is cached (3)
I:checking SERVFAIL is returned from cache (4)
I:checking with +cd query (5)
I:failed
I:checking with +dnssec query (6)
I:failed
I:exit status: 2
R:FAIL
E:sfcache:Thu Mar 15 14:16:54 JST 2018
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)
</pre>https://gitlab.isc.org/isc-projects/bind9/-/issues/161Several time related unit tests fail on Mac OS X2019-06-19T12:13:29ZOndřej SurýSeveral time related unit tests fail on Mac OS X```
===> Failed tests
lib/dns/tests/update_test:future_to_date -> failed: update_test.c:320: serial != 2014040101 [0.058s]
lib/dns/tests/update_test:future_to_unix -> failed: update_test.c:156: serial != old + 1 [0.055s]
lib/dns/te...```
===> Failed tests
lib/dns/tests/update_test:future_to_date -> failed: update_test.c:320: serial != 2014040101 [0.058s]
lib/dns/tests/update_test:future_to_unix -> failed: update_test.c:156: serial != old + 1 [0.055s]
lib/dns/tests/update_test:now_to_date -> failed: update_test.c:296: serial != 2014040101 [0.054s]
lib/dns/tests/update_test:now_to_unix -> failed: update_test.c:133: serial != old + 1 [0.053s]
lib/dns/tests/update_test:past_to_date -> failed: update_test.c:273: serial != 2014040100 [0.052s]
lib/dns/tests/update_test:past_to_unix -> failed: update_test.c:110: serial != mystdtime [0.055s]
lib/dns/tests/update_test:undefined_plus1_to_unix -> failed: update_test.c:180: serial != mystdtime [0.056s]
lib/dns/tests/update_test:unixtime_zero -> failed: update_test.c:250: serial != old + 1 [0.054s]
```
Master on latest Mac OS X, compiler:
```
$ clang --version
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
```Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/162Remove idnkit-1.0 from BIND sources2018-03-17T13:15:03ZOndřej SurýRemove idnkit-1.0 from BIND sourcesThere's a local copy of outdated idnkit-1.0 library in BIND source. Let's just get rid of it (and cleanup relevant documentation).There's a local copy of outdated idnkit-1.0 library in BIND source. Let's just get rid of it (and cleanup relevant documentation).BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/163Add libidn2 info to "Configuration summary"2018-04-05T10:08:12ZOndřej SurýAdd libidn2 info to "Configuration summary"BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/164Remove useless OpenSSL warning from configure script2018-03-19T22:14:23ZOndřej SurýRemove useless OpenSSL warning from configure scriptThere's a OpenSSL warning in `configure` script that's obsolete:
> The latest stable version is the 1.1.0 series. The 1.0.2 series is our Long Term Support (LTS) release, supported until 31st December 2019. The 0.9.8, 1.0.0 and 1.0.1 ve...There's a OpenSSL warning in `configure` script that's obsolete:
> The latest stable version is the 1.1.0 series. The 1.0.2 series is our Long Term Support (LTS) release, supported until 31st December 2019. The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support and should not be used.
and it should be removed as it is not BIND's place to teach users to update their system anyway.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/165Always use OpenSSL or PKCS#11 random data providers2021-05-19T16:44:22ZOndřej SurýAlways use OpenSSL or PKCS#11 random data providersCurrently, we support OpenSSL, PKCS#11 or own (libisc) random bytes provider. Remove the embedded entropy provider and always use crypto library providers.Currently, we support OpenSSL, PKCS#11 or own (libisc) random bytes provider. Remove the embedded entropy provider and always use crypto library providers.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/166statistics system test numbering is bad2018-03-19T22:14:37ZMark Andrewsstatistics system test numbering is badBIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/167coverity: Dereferencing a null pointer in lib/dns/tests/rbt_test.c2018-03-19T22:56:03ZGhost Usercoverity: Dereferencing a null pointer in lib/dns/tests/rbt_test.c```
** CID 1430161: (NULL_RETURNS)
/lib/dns/tests/rbt_test.c: 1142 in atfu_rbt_addname_body()
/lib/dns/tests/rbt_test.c: 1153 in atfu_rbt_addname_body()
_______________________________________________________________________________...```
** CID 1430161: (NULL_RETURNS)
/lib/dns/tests/rbt_test.c: 1142 in atfu_rbt_addname_body()
/lib/dns/tests/rbt_test.c: 1153 in atfu_rbt_addname_body()
________________________________________________________________________________________________________
*** CID 1430161: (NULL_RETURNS)
/lib/dns/tests/rbt_test.c: 1142 in atfu_rbt_addname_body()
1136 result = dns_test_begin(NULL, ISC_TRUE);
1137 ATF_CHECK_EQ(result, ISC_R_SUCCESS);
1138
1139 ctx = test_context_setup();
1140
1141 n = isc_mem_get(mctx, sizeof(size_t));
>>> CID 1430161: (NULL_RETURNS)
>>> Dereferencing a null pointer "n".
1142 *n = 1;
1143
1144 dns_test_namefromstring("d.e.f.g.h.i.j.k", &fname);
1145 name = dns_fixedname_name(&fname);
1146
1147 /* Add a name that doesn't exist */
/lib/dns/tests/rbt_test.c: 1153 in atfu_rbt_addname_body()
1147 /* Add a name that doesn't exist */
1148 result = dns_rbt_addname(ctx->rbt, name, n);
1149 ATF_REQUIRE_EQ(result, ISC_R_SUCCESS);
1150
1151 /* Now add again, should get ISC_R_EXISTS */
1152 n = isc_mem_get(mctx, sizeof(size_t));
>>> CID 1430161: (NULL_RETURNS)
>>> Dereferencing a null pointer "n".
1153 *n = 2;
1154 result = dns_rbt_addname(ctx->rbt, name, n);
1155 ATF_REQUIRE_EQ(result, ISC_R_EXISTS);
1156 isc_mem_put(mctx, n, sizeof(size_t));
1157
1158 test_context_teardown(ctx);
```BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/168coverity: Incorrect shifting in DNS_RPZ_ZMASK2018-03-19T22:14:45ZGhost Usercoverity: Incorrect shifting in DNS_RPZ_ZMASK```
________________________________________________________________________________________________________
*** CID 1430160: (BAD_SHIFT)
/lib/ns/query.c: 2610 in rpz_get_zbits()
2604 * the smallest name,
2605 ...```
________________________________________________________________________________________________________
*** CID 1430160: (BAD_SHIFT)
/lib/ns/query.c: 2610 in rpz_get_zbits()
2604 * the smallest name,
2605 * the longest IP address prefix,
2606 * the lexically smallest address.
2607 */
2608 if (st->m.policy != DNS_RPZ_POLICY_MISS) {
2609 if (st->m.type >= rpz_type) {
>>> CID 1430160: (BAD_SHIFT)
>>> In expression "1 << st->m.rpz->num + 1", left shifting by more than 31 bits has undefined behavior. The shift amount, "st->m.rpz->num + 1", is as much as 63.
2610 zbits &= DNS_RPZ_ZMASK(st->m.rpz->num);
2611 } else{
2612 zbits &= DNS_RPZ_ZMASK(st->m.rpz->num) >> 1;
2613 }
2614 }
2615
/lib/ns/query.c: 2612 in rpz_get_zbits()
2606 * the lexically smallest address.
2607 */
2608 if (st->m.policy != DNS_RPZ_POLICY_MISS) {
2609 if (st->m.type >= rpz_type) {
2610 zbits &= DNS_RPZ_ZMASK(st->m.rpz->num);
2611 } else{
>>> CID 1430160: (BAD_SHIFT)
>>> In expression "1 << st->m.rpz->num + 1", left shifting by more than 31 bits has undefined behavior. The shift amount, "st->m.rpz->num + 1", is as much as 63.
2612 zbits &= DNS_RPZ_ZMASK(st->m.rpz->num) >> 1;
2613 }
2614 }
2615
2616 /*
2617 * If the client wants recursion, allow only compatible policies.
```BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/169rpzrecurse test fails on v9_9_sub branch due to SERVFAIL cache2019-04-25T15:45:51ZGhost Userrpzrecurse test fails on v9_9_sub branch due to SERVFAIL cacherpzrecurse test fails on v9_9_sub branch due to SERVFAIL cache interfering with the RCODE returned for clientip tests.
See: https://bind-build.isc.org//bind9/v9_9_sub/libtool/amd64-unknown-freebsd10.3/daemon2.lab.isc.org/default/2018-03...rpzrecurse test fails on v9_9_sub branch due to SERVFAIL cache interfering with the RCODE returned for clientip tests.
See: https://bind-build.isc.org//bind9/v9_9_sub/libtool/amd64-unknown-freebsd10.3/daemon2.lab.isc.org/default/2018-03-18_19:41:05_UTC/test.txt
```
I:rpzrecurse:starting resolver using named.clientip.conf
I:rpzrecurse:testing CLIENT-IP behavior #2 (63)
I:rpzrecurse:stopping resolver
I:rpzrecurse:starting resolver using named.clientip2.conf
I:rpzrecurse:test 63 failed: query failed
I:rpzrecurse:test 63 failed: query failed
I:rpzrecurse:test 63 failed: didn't get expected answer
```https://gitlab.isc.org/isc-projects/bind9/-/issues/170Affinity for Notifies and Updates2021-10-04T18:08:17ZVicky Riskvicky@isc.orgAffinity for Notifies and Updates### Description
For large authoritative implementations with a large matrix of multiple layers of transfer servers and slaves with multiple alternative masters, it is possible that a slave will get a notify message, and the master they ...### Description
For large authoritative implementations with a large matrix of multiple layers of transfer servers and slaves with multiple alternative masters, it is possible that a slave will get a notify message, and the master they contact for an update may not yet have received that update.
### Request
Ensure that slaves only request update transfers from one of the servers that have sent them a notify message.
### Links / referencesOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/171problems detected by LGTM static analyzer2018-04-22T20:01:36ZEvan Huntproblems detected by LGTM static analyzerhttps://lgtm.com/projects/g/isc-projects/bind9/alerts?mode=listhttps://lgtm.com/projects/g/isc-projects/bind9/alerts?mode=listBIND-9.13.0Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/172rrl tests fail intermittently2023-08-23T12:50:45ZOndřej Surýrrl tests fail intermittentlyWe have one occurrence here:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/5453
```
S:rrl:Mon Mar 19 16:25:54 UTC 2018
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTRANGE:11400 - 11499
I:rrl:0 instead of 50 '192.0.2.8' responses for a*...We have one occurrence here:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/5453
```
S:rrl:Mon Mar 19 16:25:54 UTC 2018
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTRANGE:11400 - 11499
I:rrl:0 instead of 50 '192.0.2.8' responses for a*.a9.tld2
I:rrl:60 instead of 10 dropped responses for a*.a9.tld2
I:rrl:0 instead of 50 NOERROR responses for a*.a9.tld2
I:rrl:exit status: 1
R:rrl:FAIL
E:rrl:Mon Mar 19 16:26:13 UTC 2018
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/173option to disable responding with cookies2018-05-18T11:05:02ZBrian Conryoption to disable responding with cookiesThe use case is a resolver farm with multiple DNS implementations that are expected to all behave as alike as possible. If the other implementation does not support DNS cookies then it is up to BIND to not respond to clients with them w...The use case is a resolver farm with multiple DNS implementations that are expected to all behave as alike as possible. If the other implementation does not support DNS cookies then it is up to BIND to not respond to clients with them when requested.
Either build-time or in named.conf should be acceptable.https://gitlab.isc.org/isc-projects/bind9/-/issues/174Non-standard behavior when encountering single record alias loops2018-11-08T19:17:05ZGhost UserNon-standard behavior when encountering single record alias loopsIt appears BIND has non-standard (both RFC and ecosystem) behavior when encountering single record CNAME alias loop. When a loop in encountered BIND properly terminates the recursion logic but returns a non-error RCODE and the CNAME it e...It appears BIND has non-standard (both RFC and ecosystem) behavior when encountering single record CNAME alias loop. When a loop in encountered BIND properly terminates the recursion logic but returns a non-error RCODE and the CNAME it encountered.
When I first saw this I thought the issue was with normal loops (i.e. loop-a.com -> loop-b.com -> loop-a.com) but BIND behaves correctly when encountering this (throwing a SERVFAIL), the issue is with a slightly more strange single record loop (loop-a.com -> loop-a.com). My initial assumption was there was some specific reason for doing this but I was unable to find one (albeit my search was rather brief so I may have missed something) and as far as I can tell none of the other major resolvers display this behavior.
Using the following zone here are my testing results from BIND, Unbound, PowerDNS, and Google's public resolver.
Zone:
```
loop.testing.bracewel.net. IN CNAME loop.testing.bracewel.net.
```
Results:
```
BIND 9.12.1:
$ dig a loop.testing.bracewel.net @localhost -p 8053
; <<>> DiG 9.9.7-P3 <<>> a loop.testing.bracewel.net @localhost -p 8053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38730
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;loop.testing.bracewel.net. IN A
;; ANSWER SECTION:
loop.testing.bracewel.net. 0 IN CNAME loop.testing.bracewel.net.
;; Query time: 1492 msec
;; SERVER: 127.0.0.1#8053(127.0.0.1)
;; WHEN: Tue Mar 20 15:10:15 GMT 2018
;; MSG SIZE rcvd: 68
```
```
Unbound 1.6.5:
$ dig a loop.testing.bracewel.net @localhost -p 8153
; <<>> DiG 9.9.7-P3 <<>> a loop.testing.bracewel.net @localhost -p 8153
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57714
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1252
;; QUESTION SECTION:
;loop.testing.bracewel.net. IN A
;; Query time: 477 msec
;; SERVER: 127.0.0.1#8153(127.0.0.1)
;; WHEN: Tue Mar 20 15:35:54 GMT 2018
;; MSG SIZE rcvd: 54
```
```
PowerDNS 4.1.1:
$ dig a loop.testing.bracewel.net @localhost -p 8253
; <<>> DiG 9.9.7-P3 <<>> a loop.testing.bracewel.net @localhost -p 8253
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65153
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;loop.testing.bracewel.net. IN A
;; ANSWER SECTION:
loop.testing.bracewel.net. 0 IN CNAME loop.testing.bracewel.net.
;; Query time: 168 msec
;; SERVER: 127.0.0.1#8253(127.0.0.1)
;; WHEN: Tue Mar 20 15:47:23 GMT 2018
;; MSG SIZE rcvd: 68
```
```
Google:
$ dig a loop.testing.bracewel.net @8.8.8.8
; <<>> DiG 9.9.7-P3 <<>> a loop.testing.bracewel.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19269
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;loop.testing.bracewel.net. IN A
;; Query time: 72 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Mar 20 15:11:36 GMT 2018
;; MSG SIZE rcvd: 54
```BIND 9.12.4https://gitlab.isc.org/isc-projects/bind9/-/issues/175Refactor hmac functions to reduce duplication of the code2018-11-08T18:59:41ZOndřej SurýRefactor hmac functions to reduce duplication of the codeWhile looking at a way how to use either OpenSSL or PKCS#11 hashing functions, I found a lot of duplicated code in the HMAC functions.While looking at a way how to use either OpenSSL or PKCS#11 hashing functions, I found a lot of duplicated code in the HMAC functions.https://gitlab.isc.org/isc-projects/bind9/-/issues/176Test build BIND 9 against openssl-1.1.1-pre32018-05-23T10:32:22ZMark AndrewsTest build BIND 9 against openssl-1.1.1-pre3https://gitlab.isc.org/isc-projects/bind9/-/issues/177initial advertised EDNS UDP buffer size problem2018-03-30T06:50:24ZGhost Userinitial advertised EDNS UDP buffer size problembind change the initial UDP buffer size to 512(from bind 9.10.0), result in usging tcp query ROOT & GTLD Server after bind starting.
as both root & gtld's edns response size greater than 512 bytes.
after bind restart, the recurs...bind change the initial UDP buffer size to 512(from bind 9.10.0), result in usging tcp query ROOT & GTLD Server after bind starting.
as both root & gtld's edns response size greater than 512 bytes.
after bind restart, the recursion time of bind 9.10 is much longer than bind 9.9 。
```
reading from file g.pcap, link-type EN10MB (Ethernet)
22:17:57.543248 IP (tos 0x0, ttl 64, id 33740, offset 0, flags [none], proto UDP (17), length 67)
hk.63669 > b.root-servers.net.domain: [bad udp cksum 0x1e5a -> 0x2361!] 35054 [1au] A? google.com. ar: . OPT UDPsize=512 DO (39)
22:17:57.543297 IP (tos 0x0, ttl 64, id 33741, offset 0, flags [none], proto UDP (17), length 56)
hk.20276 > b.root-servers.net.domain: [bad udp cksum 0x1e4f -> 0x9e9b!] 28252 [1au] NS? . ar: . OPT UDPsize=512 DO (28)
22:17:57.697250 IP (tos 0x14, ttl 51, id 50860, offset 0, flags [none], proto UDP (17), length 56)
b.root-servers.net.domain > hk.20276: [udp sum ok] 28252*-| q: NS? . 0/0/1 ar: . OPT UDPsize=4096 DO (28)
22:17:57.697472 IP (tos 0x0, ttl 64, id 36179, offset 0, flags [DF], proto TCP (6), length 60)
hk.20454 > b.root-servers.net.domain: Flags [S], cksum 0x1e48 (incorrect -> 0x99e9), seq 1202528439, win 42340, options [mss 1460,sackOK,TS val 2217782756 ecr 0,nop,wscale 11], length 0
22:17:57.701445 IP (tos 0x14, ttl 51, id 50863, offset 0, flags [none], proto UDP (17), length 67)
b.root-servers.net.domain > hk.63669: [udp sum ok] 35054-| q: A? google.com. 0/0/1 ar: . OPT UDPsize=4096 DO (39)
22:17:57.701551 IP (tos 0x0, ttl 64, id 24089, offset 0, flags [DF], proto TCP (6), length 60)
hk.59642 > b.root-servers.net.domain: Flags [S], cksum 0x1e48 (incorrect -> 0x7cf5), seq 4165858289, win 42340, options [mss 1460,sackOK,TS val 2217782760 ecr 0,nop,wscale 11], length 0
22:17:57.852581 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto TCP (6), length 60)
b.root-servers.net.domain > hk.20454: Flags [S.], cksum 0x63e1 (correct), seq 1881857303, ack 1202528440, win 28960, options [mss 1460,sackOK,TS val 3508620251 ecr 2217782756,nop,wscale 7], length 0
22:17:57.852634 IP (tos 0x0, ttl 64, id 36180, offset 0, flags [DF], proto TCP (6), length 52)
hk.20454 > b.root-servers.net.domain: Flags [.], cksum 0x1e40 (incorrect -> 0x031e), seq 1, ack 1, win 21, options [nop,nop,TS val 2217782911 ecr 3508620251], length 0
22:17:57.852762 IP (tos 0x0, ttl 64, id 36181, offset 0, flags [DF], proto TCP (6), length 82)
hk.20454 > b.root-servers.net.domain: Flags [P.], cksum 0x1e5e (incorrect -> 0xbc43), seq 1:31, ack 1, win 21, options [nop,nop,TS val 2217782911 ecr 3508620251], length 3045932 [1au] NS? . ar: . OPT UDPsize=4096 DO (28)
22:17:57.860436 IP (tos 0x14, ttl 51, id 0, offset 0, flags [DF], proto TCP (6), length 60)
b.root-servers.net.domain > hk.59642: Flags [S.], cksum 0x432e (correct), seq 53890507, ack 4165858290, win 28960, options [mss 1460,sackOK,TS val 3508620251 ecr 2217782760,nop,wscale 7], length 0
22:17:57.860456 IP (tos 0x0, ttl 64, id 24090, offset 0, flags [DF], proto TCP (6), length 52)
hk.59642 > b.root-servers.net.domain: Flags [.], cksum 0x1e40 (incorrect -> 0xe266), seq 1, ack 1, win 21, options [nop,nop,TS val 2217782919 ecr 3508620251], length 0
22:17:57.860527 IP (tos 0x0, ttl 64, id 24091, offset 0, flags [DF], proto TCP (6), length 93)
hk.59642 > b.root-servers.net.domain: Flags [P.], cksum 0x1e69 (incorrect -> 0x9173), seq 1:42, ack 1, win 21, options [nop,nop,TS val 2217782919 ecr 3508620251], length 415201 [1au] A? google.com. ar: . OPT UDPsize=4096 DO (39)
22:17:58.007824 IP (tos 0x0, ttl 51, id 37272, offset 0, flags [DF], proto TCP (6), length 52)
b.root-servers.net.domain > hk.20454: Flags [.], cksum 0x018b (correct), seq 1, ack 31, win 229, options [nop,nop,TS val 3508620416 ecr 2217782911], length 0
22:17:58.007994 IP (tos 0x0, ttl 51, id 37273, offset 0, flags [DF], proto TCP (6), length 1151)
b.root-servers.net.domain > hk.20454: Flags [P.], cksum 0xf32e (correct), seq 1:1100, ack 31, win 229, options [nop,nop,TS val 3508620416 ecr 2217782911], length 109945932*- q: NS? . 14/0/27 . NS f.root-servers.net., . NS l.root-servers.net., . NS j.root-servers.net., . NS d.root-servers.net., . NS m.root-servers.net., . NS i.root-servers.net., . NS e.root-servers.net., . NS c.root-servers.net., . NS g.root-servers.net., . NS b.root-servers.net., . NS h.root-servers.net., . NS a.root-servers.net., . NS k.root-servers.net., . RRSIG ar: a.root-servers.net. A 198.41.0.4, b.root-servers.net. A 199.9.14.201, c.root-servers.net. A 192.33.4.12, d.root-servers.net. A 199.7.91.13, e.root-servers.net. A 192.203.230.10, f.root-servers.net. A 192.5.5.241, g.root-servers.net. A 192.112.36.4, h.root-servers.net. A 198.97.190.53, i.root-servers.net. A 192.36.148.17, j.root-servers.net. A 192.58.128.30, k.root-servers.net. A 193.0.14.129, l.root-servers.net. A 199.7.83.42, m.root-servers.net. A 202.12.27.33, a.root-servers.net. AAAA 2001:503:ba3e::2:30, b.root-servers.net. AAAA 2001:500:200::b, c.root-servers.net. AAAA 2001:500:2::c, d.root-servers.net. AAAA 2001:500:2d::d, e.root-servers.net. AAAA 2001:500:a8::e, f.root-servers.net. AAAA 2001:500:2f::f, g.root-servers.net. AAAA 2001:500:12::d0d, h.root-servers.net. AAAA 2001:500:1::53, i.root-servers.net. AAAA 2001:7fe::53, j.root-servers.net. AAAA 2001:503:c27::2:30, k.root-servers.net. AAAA 2001:7fd::1, l.root-servers.net. AAAA 2001:500:9f::42, m.root-servers.net. AAAA 2001:dc3::35, . OPT UDPsize=4096 DO (1097)
22:17:58.008018 IP (tos 0x0, ttl 64, id 36182, offset 0, flags [DF], proto TCP (6), length 52)
hk.20454 > b.root-servers.net.domain: Flags [.], cksum 0x1e40 (incorrect -> 0xfd72), seq 31, ack 1100, win 23, options [nop,nop,TS val 2217783066 ecr 3508620416], length 0
22:17:58.008573 IP (tos 0x0, ttl 64, id 36183, offset 0, flags [DF], proto TCP (6), length 52)
hk.20454 > b.root-servers.net.domain: Flags [F.], cksum 0x1e40 (incorrect -> 0xfd70), seq 31, ack 1100, win 23, options [nop,nop,TS val 2217783067 ecr 3508620416], length 0
22:17:58.019490 IP (tos 0x14, ttl 51, id 325, offset 0, flags [DF], proto TCP (6), length 52)
b.root-servers.net.domain > hk.59642: Flags [.], cksum 0xe0bf (correct), seq 1, ack 42, win 229, options [nop,nop,TS val 3508620425 ecr 2217782919], length 0
22:17:58.019657 IP (tos 0x14, ttl 51, id 326, offset 0, flags [DF], proto TCP (6), length 1224)
b.root-servers.net.domain > hk.59642: Flags [P.], cksum 0x4548 (correct), seq 1:1173, ack 42, win 229, options [nop,nop,TS val 3508620425 ecr 2217782919], length 11725201- q: A? google.com. 0/15/27 ns: com. NS h.gtld-servers.net., com. NS m.gtld-servers.net., com. NS l.gtld-servers.net., com. NS j.gtld-servers.net., com. NS i.gtld-servers.net., com. NS g.gtld-servers.net., com. NS f.gtld-servers.net., com. NS b.gtld-servers.net., com. NS a.gtld-servers.net., com. NS c.gtld-servers.net., com. NS e.gtld-servers.net., com. NS k.gtld-servers.net., com. NS d.gtld-servers.net., com. DS, com. RRSIG ar: a.gtld-servers.net. A 192.5.6.30, b.gtld-servers.net. A 192.33.14.30, c.gtld-servers.net. A 192.26.92.30, d.gtld-servers.net. A 192.31.80.30, e.gtld-servers.net. A 192.12.94.30, f.gtld-servers.net. A 192.35.51.30, g.gtld-servers.net. A 192.42.93.30, h.gtld-servers.net. A 192.54.112.30, i.gtld-servers.net. A 192.43.172.30, j.gtld-servers.net. A 192.48.79.30, k.gtld-servers.net. A 192.52.178.30, l.gtld-servers.net. A 192.41.162.30, m.gtld-servers.net. A 192.55.83.30, a.gtld-servers.net. AAAA 2001:503:a83e::2:30, b.gtld-servers.net. AAAA 2001:503:231d::2:30, c.gtld-servers.net. AAAA 2001:503:83eb::30, d.gtld-servers.net. AAAA 2001:500:856e::30, e.gtld-servers.net. AAAA 2001:502:1ca1::30, f.gtld-servers.net. AAAA 2001:503:d414::30, g.gtld-servers.net. AAAA 2001:503:eea3::30, h.gtld-servers.net. AAAA 2001:502:8cc::30, i.gtld-servers.net. AAAA 2001:503:39c1::30, j.gtld-servers.net. AAAA 2001:502:7094::30, k.gtld-servers.net. AAAA 2001:503:d2d::30, l.gtld-servers.net. AAAA 2001:500:d937::30, m.gtld-servers.net. AAAA 2001:501:b1f9::30, . OPT UDPsize=4096 DO (1170)
22:17:58.019670 IP (tos 0x0, ttl 64, id 24092, offset 0, flags [DF], proto TCP (6), length 52)
hk.59642 > b.root-servers.net.domain: Flags [.], cksum 0x1e40 (incorrect -> 0xdc5a), seq 42, ack 1173, win 23, options [nop,nop,TS val 2217783078 ecr 3508620425], length 0
22:17:58.020000 IP (tos 0x0, ttl 64, id 43314, offset 0, flags [none], proto UDP (17), length 67)
hk.15653 > j.gtld-servers.net.domain: [bad udp cksum 0x57d6 -> 0x3e39!] 61482 [1au] A? google.com. ar: . OPT UDPsize=512 DO (39)
22:17:58.020038 IP (tos 0x0, ttl 64, id 24093, offset 0, flags [DF], proto TCP (6), length 52)
hk.59642 > b.root-servers.net.domain: Flags [F.], cksum 0x1e40 (incorrect -> 0xdc59), seq 42, ack 1173, win 23, options [nop,nop,TS val 2217783078 ecr 3508620425], length 0
22:17:58.163676 IP (tos 0x0, ttl 51, id 37274, offset 0, flags [DF], proto TCP (6), length 52)
b.root-servers.net.domain > hk.20454: Flags [F.], cksum 0xfc05 (correct), seq 1100, ack 32, win 229, options [nop,nop,TS val 3508620572 ecr 2217783067], length 0
22:17:58.163726 IP (tos 0x0, ttl 64, id 36184, offset 0, flags [DF], proto TCP (6), length 52)
hk.20454 > b.root-servers.net.domain: Flags [.], cksum 0x1e40 (incorrect -> 0xfc38), seq 32, ack 1101, win 23, options [nop,nop,TS val 2217783222 ecr 3508620572], length 0
22:17:58.175412 IP (tos 0x14, ttl 54, id 43332, offset 0, flags [none], proto UDP (17), length 533)
j.gtld-servers.net.domain > hk.15653: [udp sum ok] 61482-| q: A? google.com. 0/7/4 ns: google.com. NS ns2.google.com., google.com. NS ns1.google.com., google.com. NS ns3.google.com., google.com. NS ns4.google.com., CK0POJMG874LJREF7EFN8430QVIT8BSM.com. Type50, CK0POJMG874LJREF7EFN8430QVIT8BSM.com. RRSIG, S848U70KJDCTE8UH1N07QH2EK7LNOUC6.com. Type50 ar: ns2.google.com. AAAA 2001:4860:4802:34::a, ns2.google.com. A 216.239.34.10, ns1.google.com. AAAA 2001:4860:4802:32::a, . OPT UDPsize=4096 DO (505)
22:17:58.175647 IP (tos 0x0, ttl 64, id 30331, offset 0, flags [DF], proto TCP (6), length 60)
hk.41221 > j.gtld-servers.net.domain: Flags [S], cksum 0x57c4 (incorrect -> 0x6dbe), seq 777836985, win 42340, options [mss 1460,sackOK,TS val 2217783234 ecr 0,nop,wscale 11], length 0
22:17:58.178918 IP (tos 0x14, ttl 51, id 327, offset 0, flags [DF], proto TCP (6), length 52)
b.root-servers.net.domain > hk.59642: Flags [F.], cksum 0xdaeb (correct), seq 1173, ack 43, win 229, options [nop,nop,TS val 3508620584 ecr 2217783078], length 0
22:17:58.178939 IP (tos 0x0, ttl 64, id 24094, offset 0, flags [DF], proto TCP (6), length 52)
hk.59642 > b.root-servers.net.domain: Flags [.], cksum 0x1e40 (incorrect -> 0xdb1a), seq 43, ack 1174, win 23, options [nop,nop,TS val 2217783237 ecr 3508620584], length 0
22:17:58.332020 IP (tos 0x0, ttl 54, id 49700, offset 0, flags [none], proto TCP (6), length 44)
j.gtld-servers.net.domain > hk.41221: Flags [S.], cksum 0x3f2c (correct), seq 3326577671, ack 777836986, win 1460, options [mss 1460], length 0
22:17:58.332154 IP (tos 0x0, ttl 64, id 30332, offset 0, flags [DF], proto TCP (6), length 40)
hk.41221 > j.gtld-servers.net.domain: Flags [.], cksum 0x57b0 (incorrect -> 0xb738), seq 1, ack 1, win 42340, length 0
22:17:58.332320 IP (tos 0x0, ttl 64, id 30333, offset 0, flags [DF], proto TCP (6), length 81)
hk.41221 > j.gtld-servers.net.domain: Flags [P.], cksum 0x57d9 (incorrect -> 0x20e9), seq 1:42, ack 1, win 42340, length 4122957 [1au] A? google.com. ar: . OPT UDPsize=4096 DO (39)
22:17:58.488944 IP (tos 0x0, ttl 54, id 57511, offset 0, flags [DF], proto TCP (6), length 814)
j.gtld-servers.net.domain > hk.41221: Flags [P.], cksum 0xab7f (correct), seq 1:775, ack 42, win 65535, length 77422957- q: A? google.com. 0/8/9 ns: google.com. NS ns2.google.com., google.com. NS ns1.google.com., google.com. NS ns3.google.com., google.com. NS ns4.google.com., CK0POJMG874LJREF7EFN8430QVIT8BSM.com. Type50, CK0POJMG874LJREF7EFN8430QVIT8BSM.com. RRSIG, S848U70KJDCTE8UH1N07QH2EK7LNOUC6.com. Type50, S848U70KJDCTE8UH1N07QH2EK7LNOUC6.com. RRSIG ar: ns2.google.com. AAAA 2001:4860:4802:34::a, ns2.google.com. A 216.239.34.10, ns1.google.com. AAAA 2001:4860:4802:32::a, ns1.google.com. A 216.239.32.10, ns3.google.com. AAAA 2001:4860:4802:36::a, ns3.google.com. A 216.239.36.10, ns4.google.com. AAAA 2001:4860:4802:38::a, ns4.google.com. A 216.239.38.10, . OPT UDPsize=4096 DO (772)
22:17:58.488994 IP (tos 0x0, ttl 64, id 30334, offset 0, flags [DF], proto TCP (6), length 40)
hk.41221 > j.gtld-servers.net.domain: Flags [.], cksum 0x57b0 (incorrect -> 0xb01d), seq 42, ack 775, win 43344, length 0
22:17:58.489383 IP (tos 0x0, ttl 64, id 9006, offset 0, flags [none], proto UDP (17), length 67)
hk.41589 > ns4.google.com.domain: [bad udp cksum 0x4781 -> 0x1bcb!] 48541 [1au] A? google.com. ar: . OPT UDPsize=512 DO (39)
22:17:58.489427 IP (tos 0x0, ttl 64, id 30335, offset 0, flags [DF], proto TCP (6), length 40)
hk.41221 > j.gtld-servers.net.domain: Flags [F.], cksum 0x57b0 (incorrect -> 0xb01c), seq 42, ack 775, win 43344, length 0
22:17:58.645265 IP (tos 0x0, ttl 54, id 57520, offset 0, flags [DF], proto TCP (6), length 40)
j.gtld-servers.net.domain > hk.41221: Flags [.], cksum 0x596d (correct), seq 775, ack 43, win 65535, length 0
22:17:58.645269 IP (tos 0x0, ttl 54, id 57521, offset 0, flags [DF], proto TCP (6), length 40)
j.gtld-servers.net.domain > hk.41221: Flags [F.], cksum 0x596c (correct), seq 775, ack 43, win 65535, length 0
22:17:58.645328 IP (tos 0x0, ttl 64, id 56815, offset 0, flags [DF], proto TCP (6), length 40)
hk.41221 > j.gtld-servers.net.domain: Flags [.], cksum 0xb01b (correct), seq 43, ack 776, win 43344, length 0
22:17:58.654219 IP (tos 0x0, ttl 44, id 2814, offset 0, flags [none], proto UDP (17), length 72)
ns4.google.com.domain > hk.41589: [udp sum ok] 48541*- q: A? google.com. 1/0/0 google.com. A 172.217.24.14 (44)
[root@hk ~]#
```Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/178Remove dead code from libraries2020-04-23T19:40:29ZOndřej SurýRemove dead code from librariesReview library functions being used in the BIND 9, and remove code that's not ever called.Review library functions being used in the BIND 9, and remove code that's not ever called.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/179Implement Additional Truncated Response (draft-song-atr-large-resp-00)2024-02-23T07:41:06ZGhost UserImplement Additional Truncated Response (draft-song-atr-large-resp-00)Implement Additional Truncated Response: https://tools.ietf.org/html/draft-song-atr-large-resp-00Implement Additional Truncated Response: https://tools.ietf.org/html/draft-song-atr-large-resp-00https://gitlab.isc.org/isc-projects/bind9/-/issues/180Intermittent recursive resolver issues [socket.c:2135]2018-09-05T15:03:29ZGhost UserIntermittent recursive resolver issues [socket.c:2135]<!--
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
Intermittent recursive resolver issues on an internal view. Introduced with 9.11.3.
### Steps to reproduce
n/a. Random queries seem to trigger, unable to reproduce manually for now.
### What is the current *bug* behavior?
Error log sees Unexpected Errors and Invalid Arguments.
### What is the expected *correct* behavior?
-
### Relevant configuration files
```
view "internal" {
match-clients { internal_hosts; trusted_hosts; };
minimal-responses yes;
recursion yes;
allow-recursion { internal_hosts; trusted_hosts; };
allow-query-cache { internal_hosts; trusted_hosts; };
include "/etc/bind/named.conf.default-zones";
query-source address 1.2.3.4;
query-source-v6 address 2001:aaaa::::2;
};
```
### Relevant logs and/or screenshots
```
Mar 26 11:36:22 edi named[726]: ../../../../lib/isc/unix/socket.c:2135: unexpected error:
Mar 26 11:36:22 edi named[726]: internal_send: 127.0.0.1#39187: Invalid argument
Mar 26 11:36:22 edi named[726]: client @0x7fd748027af0 127.0.0.1#39187 (mail.dovecot.fi): view internal: error sending response: invalid file
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)BIND-9.13.2https://gitlab.isc.org/isc-projects/bind9/-/issues/181Lurking RFCs2019-01-21T06:32:41ZTony FinchLurking RFCsIn lib/dns/tests/testdata/dst/ the RSA/DSA signature tests use copies of RFC 1035 (one of which is slightly modified) as test data. It might be a good idea to reconstruct these tests using a file with a less tricky licensing status.In lib/dns/tests/testdata/dst/ the RSA/DSA signature tests use copies of RFC 1035 (one of which is slightly modified) as test data. It might be a good idea to reconstruct these tests using a file with a less tricky licensing status.https://gitlab.isc.org/isc-projects/bind9/-/issues/182Update GeoIP support to new API (GeoLite2 from Maxmind)2021-01-08T09:46:56ZVicky Riskvicky@isc.orgUpdate GeoIP support to new API (GeoLite2 from Maxmind)### Description
Maxmind is discontinuing support for the version of their GeoIP db that is supported currently by BIND.
'At the beginning of April, 2018, we will cease updating the GeoLite Legacy downloadable databases. We will also ...### Description
Maxmind is discontinuing support for the version of their GeoIP db that is supported currently by BIND.
'At the beginning of April, 2018, we will cease updating the GeoLite Legacy downloadable databases. We will also disable free downloads of GeoLite Legacy databases from the geoipupdate program on that date.'
### Request
Please update the GeoIP support in BIND to work with the new API/schema. I did check their website and they are still providing a free community edition of the db, but the schema is new. (https://dev.maxmind.com/geoip/geoip2/geolite2/)
Excerpt from an email from a user:
Simple example for Australia and New Zealand that we use:
```
acl "ANZ" {
geoip country NZ;
geoip country AU;
};
view "ANZ" {
match-clients { key anzkey; !all_keys; ANZ; };
allow-notify { key anzkey; };
allow-transfer { key anzkey; };
server 192.999.888.77 { keys anzkey; };
zone "geo.xxx.com" {
type slave;
notify no;
file "/usr/local/etc/namedb/geo/ANZ.xxx";
masters { 127.0.0.1; };
};
zone "geo.yyy.com" {
type slave;
notify no;
file "/usr/local/etc/namedb/geo/ANZ.yyy";
masters { 127.0.0.1; };
};
};
```
We use GeoIP commercial database, so we rely on it, and it realy works. :)
It has the same schema but more data than free. The point is that MaxMind changed the schema and API for GeoIP2/GeoLite2,
so old function calls will not work with new shared libraries, so developers have to change headers and function calls.
Bind911 uses headers at lib/dns/geoip.c:
```
#include <GeoIP.h>
#include <GeoIPCity.h>
```
and calls like:
```
GeoIP_country_code_by*
GeoIP_country_name_by*
```
New maxmind libraries called "libmaxminddb" is replacement of old "GeoIP" shared libraries with new API:
headers:
```
#include <maxminddb.h>
```
Functions and data structures begin from MMDB_*.
Examples:
```
MMDB_lookup_string(&mmdb, ip_address, &gai_error, &mmdb_error);
MMDB_get_entry_data_list(&result.entry, &entry_data_list);
MMDB_dump_entry_data_list(stdout, entry_data_list, 2);
```
So, the API has changed dramaticaly.
### Links / references
MaxMind supported APIS: https://dev.maxmind.com/geoip/geoip2/downloadable/
## Notes
This new feature will be backported as to old release and the old GeoIP support will have to stay (`--with-geoip`). The two options will be mutually exclusive though. In the development branch, we will remove support for old GeoIP and only the new one will stay. Internally, the configuration should stay the same (even though this will require changes from the administrator anyway to put the new databases into their respective places).BIND 9.15.2Evan HuntEvan Hunthttps://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/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ńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/202cppcheck reporting miscellaneous issues2018-04-20T22:14:22ZStephen Morriscppcheck reporting miscellaneous issuesSee https://jenkins.isc.org/view/BIND/job/bind9-cpp-check/160/cppcheckResult
I think I've now got rid of most spurious messages (the list of checks excluded can be seen in the Jenkins job description).See https://jenkins.isc.org/view/BIND/job/bind9-cpp-check/160/cppcheckResult
I think I've now got rid of most spurious messages (the list of checks excluded can be seen in the Jenkins job description).https://gitlab.isc.org/isc-projects/bind9/-/issues/203max-cache-ttl should take a ttlval as its argument2018-04-13T18:53:19ZTony Finchmax-cache-ttl should take a ttlval as its argumentThe following does not work as I expect it to.
```
$ grep -n max-cache-ttl named.conf
18: max-cache-ttl 10m;
$ named-checkconf
/home/named/etc/named.conf:18: expected number near '10m'
```The following does not work as I expect it to.
```
$ grep -n max-cache-ttl named.conf
18: max-cache-ttl 10m;
$ named-checkconf
/home/named/etc/named.conf:18: expected number near '10m'
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2049.11.3-S1 ARM doesn't include syntax for ECS options2019-04-25T15:47:32ZBrian Conry9.11.3-S1 ARM doesn't include syntax for ECS options### Summary
The 9.11.3-S1 ARM describes the various options related to recursive ECS support but they are not listed in the options grammar.
They do exist in isccfg, so this seems to be an issue in the (automated?) export of the config...### Summary
The 9.11.3-S1 ARM describes the various options related to recursive ECS support but they are not listed in the options grammar.
They do exist in isccfg, so this seems to be an issue in the (automated?) export of the configuration grammar for the ARM.
```
$ grep ecs doc/arm/*.grammar.xml lib/isccfg/*.c
doc/arm/options.grammar.xml: <command>geoip-use-ecs</command> <replaceable>boolean</replaceable>;
lib/isccfg/aclconf.c: isc_boolean_t setpos, setecs;
lib/isccfg/aclconf.c: setecs = cfg_obj_istype(ce, &cfg_type_ecsprefix);
lib/isccfg/aclconf.c: setpos, setecs);
lib/isccfg/namedconf.c:static cfg_type_t cfg_type_ecsbits;
lib/isccfg/namedconf.c:static cfg_type_t cfg_type_ecszones;
lib/isccfg/namedconf.c: { "geoip-use-ecs", &cfg_type_boolean, 0 },
lib/isccfg/namedconf.c: { "geoip-use-ecs", &cfg_type_boolean, CFG_CLAUSEFLAG_NOTCONFIGURED },
lib/isccfg/namedconf.c: { "ecs-bits", &cfg_type_ecsbits, 0 },
lib/isccfg/namedconf.c: { "ecs-zones", &cfg_type_ecszones, 0 },
lib/isccfg/namedconf.c: { "ecs-forward", &cfg_type_bracketed_aml, 0 },
lib/isccfg/namedconf.c: { "ecs-privacy", &cfg_type_boolean, 0 },
lib/isccfg/namedconf.c: { "ecs-types", &cfg_type_rrtypelist, 0 },
lib/isccfg/namedconf.c: { "ecs", &cfg_type_boolean, 0 },
lib/isccfg/namedconf.c:static keyword_type_t ecs_kw = { "ecs", &cfg_type_netprefix };
lib/isccfg/namedconf.c:LIBISCCFG_EXTERNAL_DATA cfg_type_t cfg_type_ecsprefix = {
lib/isccfg/namedconf.c: &cfg_rep_netprefix, &ecs_kw
lib/isccfg/namedconf.c: (strcasecmp(TOKEN_STRING(pctx), "ecs") == 0)) {
lib/isccfg/namedconf.c: CHECK(cfg_parse_obj(pctx, &cfg_type_ecsprefix, ret));
lib/isccfg/namedconf.c:static cfg_tuplefielddef_t ecszoneelt_fields[] = {
lib/isccfg/namedconf.c:static cfg_type_t cfg_type_ecszoneelt = {
lib/isccfg/namedconf.c: "ecszoneelt", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple,
lib/isccfg/namedconf.c: &cfg_rep_tuple, ecszoneelt_fields
lib/isccfg/namedconf.c:static cfg_type_t cfg_type_ecszones = {
lib/isccfg/namedconf.c: "ecszones", cfg_parse_bracketed_list, cfg_print_bracketed_list,
lib/isccfg/namedconf.c: cfg_doc_bracketed_list, &cfg_rep_list, &cfg_type_ecszoneelt
lib/isccfg/namedconf.c: "ecs_domain_name", parse_name_matchelt, NULL, cfg_doc_terminal,
lib/isccfg/namedconf.c:static cfg_tuplefielddef_t ecsbits_fields[] = {
lib/isccfg/namedconf.c:static cfg_type_t cfg_type_ecsbits = {
lib/isccfg/namedconf.c: "ecsbits", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple,
lib/isccfg/namedconf.c: &cfg_rep_tuple, ecsbits_fields
```
Once this is corrected we will need updated ARM files to provide to our customers.https://gitlab.isc.org/isc-projects/bind9/-/issues/205How to update documentation?2018-04-15T22:35:33ZPaul HoffmanHow to update documentation?Greetings. I want to make a (minor) update to the documentation for `dig`. Do I update `dig.1`, or do I also update `dig.html` and/or `dig.docbook`? What about the ARM?
I'm happy to update the contributor's guide when I know the answer ...Greetings. I want to make a (minor) update to the documentation for `dig`. Do I update `dig.1`, or do I also update `dig.html` and/or `dig.docbook`? What about the ARM?
I'm happy to update the contributor's guide when I know the answer to this.https://gitlab.isc.org/isc-projects/bind9/-/issues/206nslookup accepts any -bogus -option, interpret it as -vc2018-04-20T21:55:33ZGhost Usernslookup accepts any -bogus -option, interpret it as -vc`
} else if (CHECKOPT("recurse", 3)) {
recurse = ISC_TRUE;
} else if (CHECKOPT("norecurse", 5)) {
recurse = ISC_FALSE;
} else if (strncasecmp(opt, "retry=", 6) == 0) {
...`
} else if (CHECKOPT("recurse", 3)) {
recurse = ISC_TRUE;
} else if (CHECKOPT("norecurse", 5)) {
recurse = ISC_FALSE;
} else if (strncasecmp(opt, "retry=", 6) == 0) {
set_tries(&opt[6]);
} else if (strncasecmp(opt, "ret=", 4) == 0) {
set_tries(&opt[4]);
} else if (CHECKOPT("defname", 3)) {
usesearch = ISC_TRUE;
} else if (CHECKOPT("nodefname", 5)) {
usesearch = ISC_FALSE;
} else if (CHECKOPT("vc", 2) == 0) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ BUG, remove " == 0" part (below too for every CHECKOPT)
tcpmode = ISC_TRUE;
tcpmode_set = ISC_TRUE;
} else if (CHECKOPT("novc", 4) == 0) {
tcpmode = ISC_FALSE;
tcpmode_set = ISC_TRUE;
} else if (CHECKOPT("debug", 3) == 0) {
`