ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-10-22T11:39:06Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/99CB: Add capability to merge DHCPv4 configuration from database and from a file2021-10-22T11:39:06ZMarcin SiodelskiCB: Add capability to merge DHCPv4 configuration from database and from a filePart of the Config Backend feature is to change the logic of the DHCPv4 server during startup or reconfiguration to first read the partial config from a file and then connect to the database and fetch the rest of the configuration. Both ...Part of the Config Backend feature is to change the logic of the DHCPv4 server during startup or reconfiguration to first read the partial config from a file and then connect to the database and fetch the rest of the configuration. Both configurations have to be merged into a single configuration. This ticket covers such a merge of the data fetched from the database into the CfgMgr. It doesn't cover the changes in the server logic to trigger such merge. This will be done in a separate issue.Kea1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/94CB: Implement MySQLConfigBackendDHCPv62019-02-22T22:59:34ZMarcin SiodelskiCB: Implement MySQLConfigBackendDHCPv6The MySQLConfigBackendDHCPv6 class implements Config Backend for MySQL as described in https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-designThe MySQLConfigBackendDHCPv6 class implements Config Backend for MySQL as described in https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-designKea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/82Improve Kea test capabilities2019-01-25T19:18:24ZGhost UserImprove Kea test capabilitiesKea accepts the "-p" switch to change the port on which it listens. However, there appears to be no way to alter the port to which it sends replies. Similarly perfdhcp accepts the "-L" switch to alter the local port (the port on which ...Kea accepts the "-p" switch to change the port on which it listens. However, there appears to be no way to alter the port to which it sends replies. Similarly perfdhcp accepts the "-L" switch to alter the local port (the port on which it listens for responses? - this is not clear), but there appears to be no way to alter the port to which it sends packets.
Although full testing on the privileged ports using multiple systems would still need to be carried out before release, it would simplify a lot of development testing if Kea and perfdhcp could (with suitable switch settings) communicate via unprivileged ports on the loopback interface.Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/71User Documentation for Config Backend2019-05-27T13:54:24ZGhost UserUser Documentation for Config BackendThis ticket is going to cover updates to the User's Guide for Kea Config Backend in 1.5.0 release.This ticket is going to cover updates to the User's Guide for Kea Config Backend in 1.5.0 release.Kea1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/56premium config/build fixes and cleanups2019-02-04T19:24:35ZGhost Userpremium config/build fixes and cleanupsSet `SHARE_DIR` (cf #5639 3. **bug**)
Made freeradius checks conditional on the radius hook existence.
Find an usage or remove config.setup
Move `m4_sinclude` calls to top-level (it is an illusion to believe they can be conditional)
...Set `SHARE_DIR` (cf #5639 3. **bug**)
Made freeradius checks conditional on the radius hook existence.
Find an usage or remove config.setup
Move `m4_sinclude` calls to top-level (it is an illusion to believe they can be conditional)
Cleanup `Makefile.in`
Investigate if distcheck with and without autoreconf works (aka Marcin's test). If not either fix and document as not working.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/40check what happens on empty hostname options2019-01-17T14:36:47ZGhost Usercheck what happens on empty hostname optionsCf ISC DHCP 43786 ticket where a specific handling was added to handle empty host-name (code 12) DHCPv4 options sent by not compliant (but existing in the real world) clients. Verify Kea code and if there is not yet a unit test about it ...Cf ISC DHCP 43786 ticket where a specific handling was added to handle empty host-name (code 12) DHCPv4 options sent by not compliant (but existing in the real world) clients. Verify Kea code and if there is not yet a unit test about it create a new one.Kea1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/33CB: Add support for 'reload-subnets' command2019-02-19T12:25:11ZGhost UserCB: Add support for 'reload-subnets' commandOnce all other configuration scaling tickets are done (#3579-#3584), a command that triggers the server to reload subnet configuration would be useful.Once all other configuration scaling tickets are done (#3579-#3584), a command that triggers the server to reload subnet configuration would be useful.Kea1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/30Implement control socket for DDNS2019-01-11T16:33:25ZGhost UserImplement control socket for DDNSAfter the design (#3540) is done, we should implement control socket in DDNS server.
D2, our DHCP-DDNS update daemon, does not support control channel. CA does support it and has a section for D2 communication, tries to open a socket et...After the design (#3540) is done, we should implement control socket in DDNS server.
D2, our DHCP-DDNS update daemon, does not support control channel. CA does support it and has a section for D2 communication, tries to open a socket etc, but fails ultimately, because D2 is not able to listen on that socket.
The absolute minimum required are the following commands:
version-get
build-report
shutdown
Since it is unclear whether we'll be able to squeeze this into 1.3, adding this with low priority.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/21flex-id - Better printing of non-printable charaters. (FLEX_ID_EXPRESSION_EVA...2019-02-04T16:22:50ZGhost Userflex-id - Better printing of non-printable charaters. (FLEX_ID_EXPRESSION_EVALUATED)---
name: Bug report
about: flex-id
---
**Describe the bug**
when the result of the flex-id hook is a mac address the log file display the result bad.
**To Reproduce**
configure flex-id with the following config:
"identi...---
name: Bug report
about: flex-id
---
**Describe the bug**
when the result of the flex-id hook is a mac address the log file display the result bad.
**To Reproduce**
configure flex-id with the following config:
"identifier-expression": "substring(relay4[2].hex,0,18)"
this is the result:
INFO [kea-dhcp4.flex-id/7886] FLEX_ID_EXPRESSION_EVALUATED Expression evaluated for packet to "¨^Qü<98>íÉ" (size: 6)
**Expected behavior**
the mac address will be logged currectly
**Environment:**
kea 1-4-0_p1
centos 7Kea1.6Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/16Make Cassandra connection parameters configurable [ISC-support #13376]2019-04-11T15:21:22ZBrian ConryMake Cassandra connection parameters configurable [ISC-support #13376]The request from the customer:
> I have been spending some time setting Kea up with Cassandra across multiple datacenters, and I believe there is a configuration issue with the current CQL connection manager. It forces consistency to CA...The request from the customer:
> I have been spending some time setting Kea up with Cassandra across multiple datacenters, and I believe there is a configuration issue with the current CQL connection manager. It forces consistency to CASS_CONSISTENCY_QUORUM (and I believe it does so for both reads and writes).
>
> Cassandra considers a "cluster" to include all servers across all datacenters. In a deployment with 3 servers in Site1, 3 servers in Site2, and a replication factor of 3 at each site (each node holding a copy of all data), a quorum is 4 servers. This means that any read or write to Site1 must cross the country from Site1 to at least one node in Site2. This ensures strong consistency but doesn't work well with multi-datacenter latency. Worse yet, it means that a datacenter-wide failure of Site2 creates a failure of Site1 because a quorum can't be achieved, as only 3 servers would be available.
>
> I think CASS_CONSISTENCY_LOCAL_QUORUM is probably a better default- it still requires a quorum but is aware of the Cassandra network topology when calculating the servers required for a quorum. In this case, a write to Site1 would require 2 of the 3 servers at that site. This also works with Cassandra's 'SimpleStrategy' if multiple data centers aren't being used- and it would be equivalent to CASS_CONSISTENCY_QUORUM in SimpleStrategy. Replication across datacenters would be eventually consistent, but there would be strong consistency within a datacenter.
>
> Ideally, the consistency for reads and writes would be independently configurable via the backend configuration. This would let the user assess the risk of conflicts and pick the consistency that makes the most sense for their deployment.
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlConfigConsistency.htmlKea1.6https://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/1054Release Checklist for 9.11.8, 9.12.4-P2, 9.14.3, 9.11.8-S12019-06-24T17:08:18ZStephen MorrisRelease Checklist for 9.11.8, 9.12.4-P2, 9.14.3, 9.11.8-S1## Release Checklist
- [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/Mark...## Release Checklist
- [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 CHANGES.SE (subscription branch only).
- [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] (QA) Run the "make release" Jenkins job to produce the tarballs and zips.
- [x] (QA) Sanity check the tarball and zips.
- [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.14.3Michael McNallyMichael McNallyhttps://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 Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/999Cannot build BIND 9.11.6-P1 on Solaris 11.3 / sparc with Developer Studio 12....2019-05-10T13:47:38ZGhost UserCannot build BIND 9.11.6-P1 on Solaris 11.3 / sparc with Developer Studio 12.5 compiler### Summary
Cannot build BIND 9.11.6-P1 on Oracle Solaris 11.3 on sparc architecture with Developer Studio 12.5 compiler.
### BIND version used
9.11.6-P1
### Steps to reproduce
Tried on Oracle Solaris 11.3 on sparc architecture with...### Summary
Cannot build BIND 9.11.6-P1 on Oracle Solaris 11.3 on sparc architecture with Developer Studio 12.5 compiler.
### BIND version used
9.11.6-P1
### Steps to reproduce
Tried on Oracle Solaris 11.3 on sparc architecture with Developer Studio 12.5 compiler.
- export PATH=/usr/bin:/opt/developerstudio12.5/bin
- ./configure --without-gssapi CC=/opt/developerstudio12.5/bin/cc CFLAGS='-xtarget=native -m64 -O' CXX=/opt/developerstudio12.5/bin/CC CXXFLAGS='-xtarget=native -m64 -O'
- make
### What is the current *bug* behavior?
The build was failed on link phase with the following error.
```
Undefined first referenced
symbol in file
isc_atomic_xadd client.o
ld: fatal: symbol referencing errors
*** Error code 1
make: Fatal error: Command failed for target `named'
Current working directory /var/share/tmp/bind-9.11.6-P1/bin/named
*** Error code 1
```
It seems BIND 9.11.6-P1 introduce new requirement "atomic".
BIND 9.11.6 was able to build on the same environment successfully.
Developer Studio 12.5 compiler has stdatomic but BIND configure rejects this stdatomic because ATOMIC_INT_LOCK_FREE is defined as "1" on /opt/developerstudio12.5/lib/compilers/include/cc/stdatomic.h file.
The configure said that:
```
checking for usable stdatomic.h... no
checking architecture type for atomic operations... noatomic
```
On x86_64 architecture, the configure said that:
```
checking for usable stdatomic.h... no
checking size of void *... 8
checking architecture type for atomic operations... x86_64
```
### What is the expected *correct* behavior?
build successfully
### Relevant configuration files
```
$ uname -psvri
SunOS 5.11 11.3 sparc sun4v
$ cc -V
cc: Studio 12.5 Sun C 5.14 SunOS_sparc 2016/05/31
```
### Relevant logs and/or screenshots
Attached config.log file.[config.log](/uploads/58d3d7c79bb3ab309013084c47eecfc2/config.log)BIND 9.11.7