BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-01-03T14:09:50Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/9Replace custom datatypes (isc_<foo>_t) with C11 equivalents2024-01-03T14:09:50ZOndřej SurýReplace custom datatypes (isc_<foo>_t) with C11 equivalentsCurrently there are datatypes available from the libisc headers. Replace these with C11 equivalents for better readability for external contributors.Currently there are datatypes available from the libisc headers. Replace these with C11 equivalents for better readability for external contributors.BIND-9.13.3Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/8Update the used C standard to C112024-01-03T14:09:50ZOndřej SurýUpdate the used C standard to C11Require C11 (or rather gnu11) support from compiler, and there are some next relevant steps:
* [ ] Use C11 data types (uintXX_t, boolean, etc...) #9
* [ ] Use and require atomic primitives support #10
* [ ] Benefit from better multi-th...Require C11 (or rather gnu11) support from compiler, and there are some next relevant steps:
* [ ] Use C11 data types (uintXX_t, boolean, etc...) #9
* [ ] Use and require atomic primitives support #10
* [ ] Benefit from better multi-threading support in the language #11BIND-9.13.3Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/399Do not use Net::DNS::Nameserver in the "serve-stale" system test2023-03-16T11:03:02ZMichał KępieńDo not use Net::DNS::Nameserver in the "serve-stale" system testReturning `undef` from a `Net::DNS::Nameserver` `ReplyHandler` only prevents sending a response in `Net::DNS` 0.67+ (see changes introduced in upstream revision 921). In older versions, a response is sent anyway, causing the "serve-stal...Returning `undef` from a `Net::DNS::Nameserver` `ReplyHandler` only prevents sending a response in `Net::DNS` 0.67+ (see changes introduced in upstream revision 921). In older versions, a response is sent anyway, causing the "serve-stale" system test to fail as it takes advantage of the newer behavior:
```sh
$ PORT=5300 PERL5LIB=/path/to/Net-DNS/0.66/lib perl bin/tests/system/serve-stale/ans2/ans.pl > /dev/null 2>&1 &
$ dig @10.53.0.2 -p 5300 disable txt +short
"0"
$ dig @10.53.0.2 -p 5300 ns.example +short
$ kill $!
$ PORT=5300 PERL5LIB=/path/to/Net-DNS/0.67/lib perl bin/tests/system/serve-stale/ans2/ans.pl > /dev/null 2>&1 &
$ dig @10.53.0.2 -p 5300 disable txt +short
"0"
$ dig @10.53.0.2 -p 5300 ns.example +short
; <<>> DiG 9.13.2 <<>> @10.53.0.2 -p 5300 ns.example +short
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
```
Since the latest `Net::DNS` version available with stock RHEL/CentOS 6 packages is 0.65 and we officially support that operating system, `bin/tests/system/serve-stale/ans2/ans.pl` should be reworked not to use `Net::DNS::Nameserver` to ensure it behaves consistently across all `Net::DNS` versions.BIND-9.13.3Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/392Trust anchor telemetry queries are not sent for locally served zones2023-03-16T11:03:02ZMichał KępieńTrust anchor telemetry queries are not sent for locally served zonesCalling `dns_resolver_createfetch()` [with NULL `domain` and `nameservers` arguments](https://gitlab.isc.org/isc-projects/bind9/blob/4f6ef2f3e5bacd74da2cf2e4f8e51f3d7682b9a1/bin/named/server.c#L6598) will not cause upstream queries to be...Calling `dns_resolver_createfetch()` [with NULL `domain` and `nameservers` arguments](https://gitlab.isc.org/isc-projects/bind9/blob/4f6ef2f3e5bacd74da2cf2e4f8e51f3d7682b9a1/bin/named/server.c#L6598) will not cause upstream queries to be sent for a TAT query for a zone which is configured locally since the response will be determined just by consulting local data.
This issue is of particular importance for root zone mirroring.
Sparked by [a tweet from Marco Davids](https://twitter.com/marcodavids/status/1012816801074380802).BIND-9.13.3Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/300Upgrade Jenkins Windows builders to VS20172023-03-16T11:03:02ZOndřej SurýUpgrade Jenkins Windows builders to VS2017With !325, we now officially need stdint.h/inttypes.h support. Therefore, we need Jenkins Windows build machines to bump to VS2017.With !325, we now officially need stdint.h/inttypes.h support. Therefore, we need Jenkins Windows build machines to bump to VS2017.BIND-9.13.3Curtis BlackburnCurtis Blackburnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/237dnssec-validation exception domains2022-01-26T07:43:51ZEvan Huntdnssec-validation exception domainsWe've had a feature request on the back burner list for a long while: The ability to permanently configure the equivalent of a negative trust anchor so that local fake TLDs like "corp" or "home" can be used without triggering validation ...We've had a feature request on the back burner list for a long while: The ability to permanently configure the equivalent of a negative trust anchor so that local fake TLDs like "corp" or "home" can be used without triggering validation failures due to their nonexistence at the root.
I implemented this over the weekend. No particular urgency about it, we might even decide it's not a good idea, but I'm opening an issue so I can push an associated MR for further discussion.BIND-9.13.3https://gitlab.isc.org/isc-projects/bind9/-/issues/514Release Checklist for 9.13.32018-09-25T16:06:26ZVicky Riskvicky@isc.orgRelease Checklist for 9.13.3## Release Checklist
- [x] 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] Prepare the sources for tarball generatio...## Release Checklist
- [x] 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] Prepare the sources for tarball generation
- [x] Change software version and library versions in configure.in
- [x] Update CHANGES
- [x] Ensure the release notes are correct for this release
- [x] Ensure the metainformation is correct for this release
- [x] Make sure the tests are passing
- [x] Create a tag (name vX_Y_Z[-alphatag], content BIND X.Y.Z[-alphatag], signed with a developer's GPG key): git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z
- [x] Push the changes and tag
- [x] Create the tarball
- [x] Create the Windows zips
- [x] Ask QA to sanity check the tarball and zips
- [x] Request the signature on the tarballs
- [x] Make tarballs and signatures available to download
- [x] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
- [x] Update DEB and RPM packages
## Communication
- [x] Inform support to upload to the web site (nice to give them a heads-up in advance)
- Write release e-mail to bind9-announce, bind-users in case of a major release
- [x] Inform marketing to announce the release
- Post short note to Twitter
- Update http://en.wikipedia.org/wiki/BIND
- Blog post if a major releaseBIND-9.13.3Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/523Add release note on "IPv6 now required" and "old quirks removed"2018-09-04T01:51:38ZOndřej SurýAdd release note on "IPv6 now required" and "old quirks removed"BIND-9.13.3Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/452isc_refcount_init() return value is checked inconsistently2018-08-30T19:31:39ZOndřej Surýisc_refcount_init() return value is checked inconsistently`isc_refcount_init()` should be changed to never fail and the places where result is checked should be cleaned up.`isc_refcount_init()` should be changed to never fail and the places where result is checked should be cleaned up.BIND-9.13.3Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/473stdint/stdboolean MR caused performance regression in master2018-08-27T12:26:58ZOndřej Surýstdint/stdboolean MR caused performance regression in masterThere has been drop in performance after stdint/stdbool MR has been merged to master.There has been drop in performance after stdint/stdbool MR has been merged to master.BIND-9.13.3https://gitlab.isc.org/isc-projects/bind9/-/issues/460Improved, comprehensive logging of NTA additions and removals [ISC-Support #8...2018-08-14T23:17:36ZVicky Riskvicky@isc.orgImproved, comprehensive logging of NTA additions and removals [ISC-Support #8279]user request is for a log message *at the time when an NTA is expired*, ideally with a reason.
> What we would really like to see is just a message at the
> expired point. Something we can trigger on predictably.
> "<zone> NTA expired d...user request is for a log message *at the time when an NTA is expired*, ideally with a reason.
> What we would really like to see is just a message at the
> expired point. Something we can trigger on predictably.
> "<zone> NTA expired due to time"
> "<zone> NTA expired due to zone revalidating"
> "<zone> NTA removed at user request" (rndc nta -remove)
> "<zone> NTA expired due to <other reasons>"
This was discussed at the weekly meeting, and Mukund said
that a timer might need to be added to the NTA code, so as
to watch/track NTAs.
<muks>
Note that we do log NTA expiry before a "resolution fails because the
NTA has been removed". But it isn't logged at the exact second the NTA
expires.. it is cleaned up lazily when we attempt to use it next.
--------------
The customer's use case:
> The main purpose would be for Tier I helpdesk awareness. We would incorporate this into our existing log analysis system to generate reports that detail why an NTA was removed and when. The most immediate use case I can think of is a signed domain whose signatures have expired that requested an NTA and is now getting complaints about resolution failing. As we talked about we would want to get the current status through real-time queries but knowing the cause of the removal would help reduce call escalation.
>
> It occurs to me that our use case may be different from an external recursive server so this may seem like an odd request. The recursive servers where we will utilize NTA are at the enterprise level and provide recursion for the internal namespace. That internal namespace is very fractured and maintained by over a thousand different groups. So the support structure for those enterprise recursive servers need to be able to answer when there are problems in any of that namespace. Knowing resolution is failing because the NTA has been removed and why will help overall understanding and ticket routing.
Tagging with 9.13.3, hoping to get this into 9.14.0BIND-9.13.3https://gitlab.isc.org/isc-projects/bind9/-/issues/434After isc_safe merge, the Windows build fails due missing OPENSSL_LIBS in pro...2018-08-11T10:22:11ZOndřej SurýAfter isc_safe merge, the Windows build fails due missing OPENSSL_LIBS in project filesBIND-9.13.3Ondřej SurýOndřej Surý2018-07-25https://gitlab.isc.org/isc-projects/bind9/-/issues/384Rework IDN support in dig2018-07-13T06:37:51ZMichał KępieńRework IDN support in digIDN support in `dig` currently suffers from a number of issues:
* IDNA2003 fallbacks [are still present](https://gitlab.isc.org/isc-projects/bind9/blob/4f6ef2f3e5bacd74da2cf2e4f8e51f3d7682b9a1/bin/dig/dighost.c#L4291-4293), despite our...IDN support in `dig` currently suffers from a number of issues:
* IDNA2003 fallbacks [are still present](https://gitlab.isc.org/isc-projects/bind9/blob/4f6ef2f3e5bacd74da2cf2e4f8e51f3d7682b9a1/bin/dig/dighost.c#L4291-4293), despite our test comments claiming that BIND made a hard transition to IDNA2008 non-transitional processing,
* confusing ([passing flags which are ignored by the callee](https://gitlab.isc.org/isc-projects/bind9/blob/4f6ef2f3e5bacd74da2cf2e4f8e51f3d7682b9a1/bin/dig/dighost.c#L4335)) and fragile ([locale-dependent](https://gitlab.com/libidn/libidn2/blob/6a5fce9848bf76102cb62a314b69d422125a14e1/lib/decode.c#L365-376)) libidn2 calls are used when decoding Punycode found in upstream DNS responses,
* leftover Autoconf macros from previous IDN implementations are still present,
* redundant code is present.BIND-9.13.3Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/393Fix a Net::DNS version quirk in the "resolver" system test2018-07-10T13:09:34ZMichał KępieńFix a Net::DNS version quirk in the "resolver" system test`new Net::DNS::Packet()->data()` only returns a DNS packet with an empty QUESTION section in `Net::DNS` 0.68+ (see changes introduced in upstream revision 968). In older versions, the same method inserted a `./ANY` RR into the QUESTION ...`new Net::DNS::Packet()->data()` only returns a DNS packet with an empty QUESTION section in `Net::DNS` 0.68+ (see changes introduced in upstream revision 968). In older versions, the same method inserted a `./ANY` RR into the QUESTION section if the latter was empty:
```sh
$ PERL5LIB=/path/to/Net-DNS/0.67/lib perl -MNet::DNS -e 'print(unpack("H*", new Net::DNS::Packet()->data()) . "\n") for (1..3);'
a027010000010000000000000000ff00ff
3d68010000010000000000000000ff00ff
a740010000010000000000000000ff00ff
$ PERL5LIB=/path/to/Net-DNS/0.68/lib perl -MNet::DNS -e 'print(unpack("H*", new Net::DNS::Packet()->data()) . "\n") for (1..3);'
01be01000000000000000000
85a101000000000000000000
2c1e01000000000000000000
```
Since the latest `Net::DNS` version available with stock RHEL/CentOS 6 packages is 0.65 and we officially support that operating system, `bin/tests/system/resolver/ans8/ans.pl` should be tweaked to ensure it returns consistent responses across all `Net::DNS` versions.BIND-9.13.3Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/371Remove dns_rdataslab_tordataset() and its related dns_rdatasetmethods_t callb...2018-07-04T11:04:34ZMichał KępieńRemove dns_rdataslab_tordataset() and its related dns_rdatasetmethods_t callbacks`lib/dns/rdataslab.c` contains `dns_rdataslab_tordataset()`, a function which allows an RDATA slab to be converted to a `dns_rdataset_t` backed by a set of methods which are almost exact duplicates of `rdataset_*()` routines found in `li...`lib/dns/rdataslab.c` contains `dns_rdataslab_tordataset()`, a function which allows an RDATA slab to be converted to a `dns_rdataset_t` backed by a set of methods which are almost exact duplicates of `rdataset_*()` routines found in `lib/dns/rbtdb.c`. Since `dns_rdataslab_tordataset()` is not used anywhere in the tree and, as of BIND 9.13, libdns is no longer considered a public library, that function and its related set of `dns_rdatasetmethods_t` callbacks can be removed.
As an aside, note that the story is entirely different when it comes to `dns_rdataslab_fromrdataset()` which `lib/dns/rbtdb.c` uses for inserting data into memory. But the slabs created using that method are never "exported" using `dns_rdataslab_tordataset()` - `bind_rdataset()` is used for that purpose.BIND-9.13.3Michał KępieńMichał Kępień