ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2018-06-28T11:53:57Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/33Root Zone local copy, similar to RFC 77062018-06-28T11:53:57ZVicky Riskvicky@isc.orgRoot Zone local copy, similar to RFC 7706Enable a resolver to download, validate, cache and update the entire root zone, obviating the need for queries to the root zone.
ICANN is sponsoring ISC to add this feature.
* [x] Refactor zone logging functions #269
* [x] constify dn...Enable a resolver to download, validate, cache and update the entire root zone, obviating the need for queries to the root zone.
ICANN is sponsoring ISC to add this feature.
* [x] Refactor zone logging functions #269
* [x] constify dns_rdata_tostruct #341
* [x] Convert verifyzone() to a libdns function #266
* [x] Unify keyfile-to-configuration conversions in system tests #284
* [x] Implement mirror zones #33BIND-9.13.2Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/32Remove ECS authoritative implementation from BIND2020-03-06T23:31:02ZVicky Riskvicky@isc.orgRemove ECS authoritative implementation from BINDWe have an auth implementation of ECS in BIND that we know is broken.
We have decided in #146 to remove the functionality from BIND. It was always marked as EXPERIMENTAL, and it can't be fixed beyond a prototype.We have an auth implementation of ECS in BIND that we know is broken.
We have decided in #146 to remove the functionality from BIND. It was always marked as EXPERIMENTAL, and it can't be fixed beyond a prototype.BIND-9.13.1Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/30Update the default for dnssec-validation to auto2018-05-31T16:40:45ZOndřej SurýUpdate the default for dnssec-validation to autoOr even better make the `yes` behave like `auto` and deprecate `auto`.
Also related to #6.Or even better make the `yes` behave like `auto` and deprecate `auto`.
Also related to #6.BIND-9.13.1Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/24Remove compilation without DNSSEC2023-12-22T10:28:30ZOndřej SurýRemove compilation without DNSSECRemove support to compile without DNSSEC. Either OpenSSL or PKCS11 would be mandatory to compile BIND.Remove support to compile without DNSSEC. Either OpenSSL or PKCS11 would be mandatory to compile BIND.BIND-9.13.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/16QNAME Minimization2023-12-22T10:28:30ZOndřej SurýQNAME MinimizationImplement QNAME minimization and enable it by default.
Ensure that nothing breaks, by:
* [x] Have a proper fallbacks when QNAME minimization fails
* [ ] Introduce inter-resolver comparison testing
* [ ] Add a workarounds module that wo...Implement QNAME minimization and enable it by default.
Ensure that nothing breaks, by:
* [x] Have a proper fallbacks when QNAME minimization fails
* [ ] Introduce inter-resolver comparison testing
* [ ] Add a workarounds module that would allow disabling various features for DNS subtreesBIND-9.13.2Witold KrecickiWitold Krecicki2018-12-19https://gitlab.isc.org/isc-projects/bind9/-/issues/517Release checklist for 9.11.4-S12018-09-25T09:51:26ZVicky Riskvicky@isc.orgRelease checklist for 9.11.4-S1## 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 meta information 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
XXXXX Create the Windows zips (we don't do this for -S, do we?)
- [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 on a hidden ftp directory
- [x] Edit the release https://gitlab.isc.org/isc-private/bind9/tags and the NEWS snippet + links to the tarballs (in the -S repo)
## Communication
- [x] Inform support to Deliver to support customers in a ticket (nice to give them a heads-up in advance)BIND-9.11.4-SMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/306backport multiple cookie-secrets to 9.11.4-S2018-06-05T02:44:26ZVicky Riskvicky@isc.orgbackport multiple cookie-secrets to 9.11.4-SWe should discuss if it would be ok to also backport this to 9.11. This was added in 9.12 because of concerns about how to introduce a new cookie secret in a large installation.
ref: https://bugs.isc.org/Ticket/Display.html?id=45672We should discuss if it would be ok to also backport this to 9.11. This was added in 9.12 because of concerns about how to introduce a new cookie secret in a large installation.
ref: https://bugs.isc.org/Ticket/Display.html?id=45672BIND-9.11.4-Shttps://gitlab.isc.org/isc-projects/bind9/-/issues/229Forward to OpenDNS, with non-standard tags (aka Cisco Umbrella)2023-08-02T15:41:17ZVicky Riskvicky@isc.orgForward to OpenDNS, with non-standard tags (aka Cisco Umbrella)### Description
1) Customer would like to use BIND resolvers to resolve queries for internal zones and any that the Customer are authoritative for, and forward all queries for external addresses to the hosted OpenDNS resolver service (a...### Description
1) Customer would like to use BIND resolvers to resolve queries for internal zones and any that the Customer are authoritative for, and forward all queries for external addresses to the hosted OpenDNS resolver service (aka Cisco Umbrella). The object is to use OpenDNS to filter these external queries and control responses to the client.
### Request
2) ISC will develop an OpenDNS-filtering feature in BIND that will add three additional bit of information required by OpenDNS to queries forwarded to the OpenDNS system. These three fields are: Virtual ApplianceID (a numeric ID the Customer will statically configure into the BIND server used to identify the geographical site), an Organizational ID (also statically configured by the Customer, used to identify the Customer's resolvers), and a ClientIP address (IPv4 or IPv6 address, can be RFC 1918, which BIND will get from the DNS query and pass through to OpenDNS in the forwarded query).
3) The additional information sent to OpenDNS will be encoded in a ‘Protoss’ format EDNS option specified by OpenDNS.
4) ISC will minimize caching of responses from the OpenDNS resolver in BIND, although caching of approximately a second is unavoidable. In case of caching, ISC will cache responses per client.
5) ISC will perform interoperability testing with OpenDNS by accessing a test OpenDNS account provided by Cisco.
6) This new feature will be provided to the customer in a BIND 9.11.x-S subscriber-only release. These are stable releases supported by ISC for subscribers, but are not part of the public open source. There will be some minimal documentation provided about how to enable the feature and configure the two new options.
### Links / references
Evan has been in communication with the OpenDNS development staff about the format of the proprietary options.BIND-9.11.4-SEvan HuntEvan Hunt2018-06-13https://gitlab.isc.org/isc-projects/bind9/-/issues/576BIND 9.11.5 Release Checklist2018-10-22T13:59:58ZVicky Riskvicky@isc.orgBIND 9.11.5 Release Checklist## 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
## Support
- [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
- Update tickets in case of waiting support customers
## Marketing
- [x] Inform marketing to announce the release
- Post short note to Twitter
- Update http://en.wikipedia.org/wiki/BIND (mktg)BIND-9.11.5https://gitlab.isc.org/isc-projects/bind9/-/issues/575BIND 9.12.3 Release Checklist2018-10-22T13:59:54ZVicky Riskvicky@isc.orgBIND 9.12.3 Release Checklist## 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
## Support
- [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
- Update tickets in case of waiting support customers
## Marketing
- [x] Inform marketing to announce the release
- Post short note to Twitter
- Update http://en.wikipedia.org/wiki/BIND (mktg)BIND-9.12.3https://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/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/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/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/448trust-anchor-telemetry option is misspelled2018-07-31T11:26:16ZAnand Buddhdevtrust-anchor-telemetry option is misspelledThe BIND 9.11.4 manual talks about the "trust-anchor-telemetry" option
and category.
I wanted to disable logging for it, so I added:
```
category trust-anchor-telemetry { null; };
```
to my logging config. But then BIND complained:
`...The BIND 9.11.4 manual talks about the "trust-anchor-telemetry" option
and category.
I wanted to disable logging for it, so I added:
```
category trust-anchor-telemetry { null; };
```
to my logging config. But then BIND complained:
```
31-Jul-2018 09:53:59.962 config: /etc/named/named.conf:24: undefined
category: 'trust-anchor-telemetry'
```
I only then realised that the BIND code itself has a typo. It's logging:
```
31-Jul-2018 09:53:58.972 trust-anchor-telementry: trust-anchor-telemetry
'_ta-4a5c-4f66/IN' from 193.0.14.129
```
Note that the category is misspelled as telemeNtry, with an N in the middle.BIND-9.11.5https://gitlab.isc.org/isc-projects/bind9/-/issues/447telemetry is mis-spelled2018-07-31T11:26:23ZRay Bellistelemetry is mis-spelledIn several places (including the actual log channel name) it was spelled "telementry".
Reported in the 9.11.4 release (and perhaps found elsewhere?)In several places (including the actual log channel name) it was spelled "telementry".
Reported in the 9.11.4 release (and perhaps found elsewhere?)BIND-9.11.5https://gitlab.isc.org/isc-projects/bind9/-/issues/440Root zone performance regression since 9.12.2rc2 and 9.13.12018-08-07T08:02:04ZRay BellisRoot zone performance regression since 9.12.2rc2 and 9.13.1Sometime around 26th June something has changed BIND's root zone performance for the worse (*much* worse in 9.12.2rc2).
9.13.1
https://perflab.isc.org/#/config/run/56b0925d6e2121101760eac6/
9.12.2rc2
https://perflab.isc.org/#/config/ru...Sometime around 26th June something has changed BIND's root zone performance for the worse (*much* worse in 9.12.2rc2).
9.13.1
https://perflab.isc.org/#/config/run/56b0925d6e2121101760eac6/
9.12.2rc2
https://perflab.isc.org/#/config/run/5a326d0249902c8a028b9ced/
The (much slower) 9.11.4rc1 release around the same time appears unaffected.BIND-9.12.3Mark AndrewsMark Andrewshttps://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/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ń