BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2019-06-11T01:56:57Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1082Detecting conflicts between static and initializing keys is unreliable2019-06-11T01:56:57ZMichał KępieńDetecting conflicts between static and initializing keys is unreliableThe code checking for both static keys and initializing keys being configured for the same domain is unreliable because it [calls][1] `isc_symtab_define()` with the `key` parameter pointing to a stack-allocated variable. Meanwhile, symt...The code checking for both static keys and initializing keys being configured for the same domain is unreliable because it [calls][1] `isc_symtab_define()` with the `key` parameter pointing to a stack-allocated variable. Meanwhile, symtab docs [say][2]:
> The symbol table library does not make a copy the key field, so the
> caller must ensure that any key it passes to isc_symtab_define() will not
> change until it calls isc_symtab_undefine() or isc_symtab_destroy().
This issue manifests itself e.g. by `named-checkconf` [failing to raise a configuration error][3] for at least some configurations which intentionally contain both static and initializing keys for the same domain (e.g. `bin/tests/system/checkconf/bad-duplicate-key.conf`). If the `namebuf` local variable in `record_static_keys()` has a close, but not identical address as the `namebuf` local variable in `check_initializing_keys()`, lookups for previously defined symtab entries will fail when they should succeed - but this is just one possible failure mode.
The solution here is to ensure what the docs ask the developer to ensure (e.g. use `isc_mem_strdup()` for the keys passed to `isc_symtab_define()` and then clean the copies up properly when `isc_mem_destroy()` is called).
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/90ff5a551aa6ba4340ae45f6ff3a97b3141d8b5c/lib/bind9/check.c#L3288-3289
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/90ff5a551aa6ba4340ae45f6ff3a97b3141d8b5c/lib/isc/include/isc/symtab.h#L45-47
[3]: https://jenkins.isc.org/job/bind9-test-release-tarball/label=fedora-32-latest/22/testReport/junit/bind/system/checkconf/BIND 9.15.1https://gitlab.isc.org/isc-projects/bind9/-/issues/1073Release Checklist for 9.15.12019-06-24T17:08:22ZStephen MorrisRelease Checklist for 9.15.1## Release Checklist for 9.15.1
- [x] (Manager) Check for the presence of a milestone for the release:
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist).
- [x] (Manager) Inform S...## Release Checklist for 9.15.1
- [x] (Manager) Check for the presence of a milestone for the release:
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist).
- [x] (Manager) Inform Support/Marketing of impending release (and give estimated release dates).
- (SwEng) Prepare the sources for tarball generation:
- [x] Check perflab to ensure there has been no unexplained drop in performance for the version being released.
- [x] Ensure that there are no outstanding merge requests in the private repository (subscription version only).
- [x] Update API files for libraries with new version information.
- [x] Change software version and library versions in configure.in (new major release only).
- [x] Rebuild configure using autoconf on docs.isc.org.
- [x] Update CHANGES.
- [x] Update "version".
- [x] Update "readme.md".
- Check the release notes are correct:
- [x] Compare content with merge requests for the release.
- [x] Check formatting.
- [x] Build documentation on docs.isc.org.
- [x] Commit changes and make sure the gitlab-ci tests are passing.
- [x] Push the changes and tag ("alphatag" is an optional string such as "b1", "rc1" etc.). (```git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]```)
- [x] If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` (this allows development to continue on the release branch whilst release engineering continues).
- [x] (SwEng) Run the "make release" Jenkins job to produce the tarballs and zips.
- [x] (SwEng) Ask QA to sanity check the tarball and zips (passing to them the number of the Jenkins job).
- [x] (QA) Sanity check the tarballs.
- [x] (QA) Request the signature on the tarballs.
- [x] (QA) Check signatures on tarballs.
- [x] (QA) Tell Support to handle notification of release.
- [x] (Manager) Inform Marketing of the release
- [x] (Manager) Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] (SwEng) Update DEB and RPM packages
- [x] (SwEng) Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`)
## Support
- [x] Make tarballs and signatures available to download.
- [x] Write release email to bind9-announce.
- [x] Write email to bind9-users (if a major release).
- [x] Update tickets in case of waiting support customers.
## Marketing
- [x] Post short note to Twitter.
- [x] Update [Wikipedia entry for BIND](http://en.wikipedia.org/wiki/BIND).
- [x] Write blog article (if a major release).BIND 9.15.1Michael McNallyMichael McNallyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1064Adding --enable-pthread-rwlock broke Windows build2019-06-05T18:29:42ZMichał KępieńAdding --enable-pthread-rwlock broke Windows build!1397 broke the Windows build:
https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/306/console
(Here is a build of the same commit as above, but with !1397 reverted: https://jenkins.isc.org/view/BIND_Par...!1397 broke the Windows build:
https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/306/console
(Here is a build of the same commit as above, but with !1397 reverted: https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/307/console)
This needs to be fixed before 9.15.1 is tagged (i.e. within the next week).BIND 9.15.1Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1044gen fails to generate headers on Debian buster2019-05-29T11:34:39ZOndřej Surýgen fails to generate headers on Debian buster`./gen` utility fails to go through all the files it should generating almost empty header files because it's missing the defines from `config.h`.`./gen` utility fails to go through all the files it should generating almost empty header files because it's missing the defines from `config.h`.BIND 9.15.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1028dig +trace should not set RD=0 (+norecurse) for the initial root hints query2019-05-22T03:13:20ZTore Andersondig +trace should not set RD=0 (+norecurse) for the initial root hints queryWhen running, e.g., `dig +trace gitlab.isc.org`, recursion is automatically disabled. This is documented in the manual page:
```
+[no]recurse
Toggle the setting of the RD (recursion desired) bit in the query.
...When running, e.g., `dig +trace gitlab.isc.org`, recursion is automatically disabled. This is documented in the manual page:
```
+[no]recurse
Toggle the setting of the RD (recursion desired) bit in the query.
This bit is set by default, which means dig normally sends
recursive queries. Recursion is automatically disabled when the
+nssearch or +trace query options are used.
```
This makes perfect sense, *except* for the initial query for the NS records of the `.` root zone.
Setting `RD=0` in the initial `IN NS .` query prevents `dig +trace` from functioning correctly when the configured upstream nameserver of the system (e.g., the `nameserver` line(s) found in `/etc/resolv.conf` on Linux systems) is a DNS forwarder/proxy - because it will refuse to answer the query.
This example shows this happening on a modern Linux system (Fedora 30) using the `systemd-resolved` DNS forwarder:
```console
$ ./dig +trace gitlab.isc.org.
; <<>> DiG 9.15.0 <<>> +trace gitlab.isc.org.
;; global options: +cmd
;; Received 51 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
$ ./dig . IN NS +norecurse
; <<>> DiG 9.15.0 <<>> . IN NS +norecurse
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 35753
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;. IN NS
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: må. mai 13 20:56:57 CEST 2019
;; MSG SIZE rcvd: 28
```
When querying for the root hints with `RD=1`, the desired answer is given:
```console
$ ./dig . IN NS +recurse
; <<>> DiG 9.15.0 <<>> . IN NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49484
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 81613 IN NS b.root-servers.net.
. 81613 IN NS d.root-servers.net.
. 81613 IN NS f.root-servers.net.
. 81613 IN NS a.root-servers.net.
. 81613 IN NS k.root-servers.net.
. 81613 IN NS c.root-servers.net.
. 81613 IN NS j.root-servers.net.
. 81613 IN NS i.root-servers.net.
. 81613 IN NS m.root-servers.net.
. 81613 IN NS l.root-servers.net.
. 81613 IN NS h.root-servers.net.
. 81613 IN NS g.root-servers.net.
. 81613 IN NS e.root-servers.net.
;; Query time: 138 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: må. mai 13 20:57:00 CEST 2019
;; MSG SIZE rcvd: 239
```
As I understand it, the DNS forwarder correctly implements the DNS protocol when it answers this query with `REFUSED`.
This understanding is based on the following specification from [RFC 8499](https://tools.ietf.org/html/rfc8499):
```
Non-recursive query: A query with the Recursion Desired (RD) bit set
to 0 in the header. A server can answer non-recursive queries
using only local information: the response contains either an
error, the answer, or a referral to some other server "closer" to
the answer. (See Section 4.3.1 of [RFC1034].)
```
Since the forwarder does not contain a built-in root hints zone file, it simply cannot *«answer [dig +trace's] no-recursive queries using only local information»*; thus answering with a `REFUSED` error is the only real option: it does not have the answer, nor would it be possible to give a *«a referral to some other server "closer" to the answer»* (at least I cannot imagine how such a referral would look like).
I therefore propose that the `dig` tool delays setting `+norecurse`/`RD=0` until the *second* query, i.e., *after* the root hints have been obtained.BIND 9.15.1https://gitlab.isc.org/isc-projects/bind9/-/issues/1023Make lib/isc/<platform>/app.c TSAN clean2019-05-20T17:00:21ZOndřej SurýMake lib/isc/<platform>/app.c TSAN cleanThreadSanitizer reports couple of problems in `app.c`, let's clean and refactor the file.ThreadSanitizer reports couple of problems in `app.c`, let's clean and refactor the file.BIND 9.15.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1011Use proper linker (config) on HP-UX2019-05-30T00:30:01ZMichael OsipovUse proper linker (config) on HP-UXIn `configure.ac` the config is still tuned for HP-UX on PA-RISC which is dead for many many years. Attached you'll find a patch to properly link with HP-UX on IA64:
* Shared libs on IA64 are -- by default -- `.so`
* The default way to ...In `configure.ac` the config is still tuned for HP-UX on PA-RISC which is dead for many many years. Attached you'll find a patch to properly link with HP-UX on IA64:
* Shared libs on IA64 are -- by default -- `.so`
* The default way to link is to use the compiler -- as advised by HPE support
The patch has been produced against 9.11.6.[bind9.patch](/uploads/f70f00ceed7144c57f14653147c3b9b0/bind9.patch)BIND 9.15.1Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/942BIND 9.12.3-P4 crash at dispatch.c:3426: REQUIRE(resp->item_out == 1)2019-06-19T21:56:10ZVeroniqueBIND 9.12.3-P4 crash at dispatch.c:3426: REQUIRE(resp->item_out == 1)```
dispatch.c:3426: REQUIRE(resp->item_out == 1) failed, back trace
#0 0x426970 in assertion_failed()+0x60
#1 0x61279a in isc_assertion_failed()+0xa
#2 0x4a5862 in dns_dispatch_getnext()+0x352
#3 0x57292a in rctx_done()+0x17a
#4 0x572db...```
dispatch.c:3426: REQUIRE(resp->item_out == 1) failed, back trace
#0 0x426970 in assertion_failed()+0x60
#1 0x61279a in isc_assertion_failed()+0xa
#2 0x4a5862 in dns_dispatch_getnext()+0x352
#3 0x57292a in rctx_done()+0x17a
#4 0x572db4 in resquery_response()+0x204
#5 0x63606b in run()+0x2bb
#6 0x7f8458968e25 in __do_global_dtors_aux_fini_array_entry()+0x7f8458063c95
#7 0x7f8458692bad in __do_global_dtors_aux_fini_array_entry()+0x7f8457d8da1d
exiting (due to assertion failure)
```
Please tell me if you need more info. This is running on Centos7, with dnssec-validation = auto.
Thanks.BIND 9.15.1Mark AndrewsMark Andrews