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 Andrews