ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-10-04T12:56:42Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/380Check the minimal key sizes in tests that might break some HSMs2021-10-04T12:56:42ZOndřej SurýCheck the minimal key sizes in tests that might break some HSMshttps://gitlab.isc.org/isc-projects/bind9/-/issues/374oss-fuzz integration2021-10-04T12:55:20ZBhargava Shastryoss-fuzz integration### Description
Continual fuzzing may help catch potential security vulnerabilities in bind at an early stage. To this end, it might be useful to enrol bind in oss-fuzz, a free continual fuzzing initiative offered by Google. I have a te...### Description
Continual fuzzing may help catch potential security vulnerabilities in bind at an early stage. To this end, it might be useful to enrol bind in oss-fuzz, a free continual fuzzing initiative offered by Google. I have a test case (see below) that can be used as a starting point for this integration. The short-term plan would be to augment this test case or write new ones using the libFuzzer API.
```
#include <stddef.h>
#include <stdint.h>
#include <isc/buffer.h>
#include <dns/fixedname.h>
#include <dns/name.h>
int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
{
isc_buffer_t buf;
isc_result_t result;
dns_fixedname_t origin;
if (size < 5) return 0;
dns_fixedname_init(&origin);
isc_buffer_init(&buf, (void *)data, size);
isc_buffer_add(&buf, size);
result = dns_name_fromtext(dns_fixedname_name(&origin), &buf, dns_rootname, 0, NULL);
return 0;
}
```
### Request
Ideally, oss-fuzz integration would create a sub-folder like `tests/oss-fuzz` that would house oss-fuzz specific test harnesses such as above. Once this test harness is approved and merged into the bind repo, I can send a pull request to oss-fuzz to fetch bind sources, build and run bind fuzzers on a continual basis.
For this to happen, the following is required:
- The oss-fuzz test harness (such as the one shown above) is merged into bind source tree
- one person from Bind development team would serve as the primary contact
- one Google linked ID (e.g., from a Bind dev team) to view bug reports needs to be provided
- [optional] one or more additional people may be CCed
### Links / references
- https://github.com/google/oss-fuzz
- http://libfuzzer.info/
- https://opensource.google.com/projects/oss-fuzzhttps://gitlab.isc.org/isc-projects/bind9/-/issues/368Certain named builds improperly check writability of some directories when -u...2021-10-04T12:54:47ZMichał KępieńCertain named builds improperly check writability of some directories when -u is usedBIND 9.12 [introduced](16d6fab2e59f1fdf63eb71fc59e138031f5c5005) mandatory checks for writability of certain directories. Certain build types perform some of these checks in incorrect order when `-u` is used.
Here is what happens for n...BIND 9.12 [introduced](16d6fab2e59f1fdf63eb71fc59e138031f5c5005) mandatory checks for writability of certain directories. Certain build types perform some of these checks in incorrect order when `-u` is used.
Here is what happens for non-threaded Linux builds with support for capabilities:
1. `named` drops capabilities to the initial set,
2. `directory` and potentially `managed-keys-directory` are checked for writability,
3. `setuid()` is called.
This means the checks in step 2 are made with the root user's privileges, albeit severely diminished by the limited capabilities which are in effect after step 1 (namely, `CAP_DAC_OVERRIDE` is no longer set). So if e.g. `directory` is set to a path which is writable by the user specified with `-u`, but not for the root user (stripped of its superuser privileges), `named` will (wrongly) refuse to start.
These same checks are differently broken for non-threaded Linux builds without support for capabilities *and* **all** builds on other platforms because step 1 above is never executed. This means that writability checks from step 2 always succeed, because they are performed with full superuser privileges rather than `-u` user's privileges.
The only type of build where the problem does not exist are threaded Linux builds, because in their case, `setuid()` is called between steps 1 and 2 above.
Fixing the problem likely requires moving the directory checks from the view configuration routines until after the last possible call to `named_os_changeuser()`, similarly to how the current working directory is checked.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/294Follow cname/dname when resolving NSes2021-10-04T12:53:17ZWitold KrecickiFollow cname/dname when resolving NSesAlthough 1034 states that NS should not be a CNAME there's no practical reason why we shouldn't follow NSes that are CNAME/DNAME records.Although 1034 states that NS should not be a CNAME there's no practical reason why we shouldn't follow NSes that are CNAME/DNAME records.Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/352Refactored RPZ has a scalability design problem2021-10-04T12:50:35ZGhost UserRefactored RPZ has a scalability design problem(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default u...(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default update rate plus the fact that RPZ does a full iteration of the DB will not work for them as their data is not latency tolerant and their policy zones are large.
There was a separate bug ticket by a popular reporter from another ISC customer in the last 1-2 months that asked whether this 60s update time could be improved to match the old RPZ behavior.
I feel this can be addressed. BIND RPZ would need to hook not just into `dns_db_updatenotify_register()`, but also into a `newdbversion` signal and every `add` and `del` update to the DB. Note that the RPZ view summary datastructure is still not versioned, so RPZ code would have to separately batch and keep aside a copy of the update diffs until the DB version commit passes, and then apply just the diffs to the RPZ view summary data structure instead of iterating the zone. I think versioning the view summary datastructure would be too much work and complicate the structure.. as long as the diff is applied to it after the DB version commit passes, there should be no problem of inconsistent data.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/318Add a warnings about changed options in 9.16 ESV to 9.11 ESV2021-10-04T12:49:00ZOndřej SurýAdd a warnings about changed options in 9.16 ESV to 9.11 ESVThis is just a placeholder for any configuration options where we either change the defaults or remove the configuration option in the next ESV. For those options, we need to add a warning to the current ESV.
Here's the not-complete li...This is just a placeholder for any configuration options where we either change the defaults or remove the configuration option in the next ESV. For those options, we need to add a warning to the current ESV.
Here's the not-complete list:
[ ] ECS Authoritativehttps://gitlab.isc.org/isc-projects/bind9/-/issues/303Improve const correctness2021-10-04T12:47:58ZOndřej SurýImprove const correctness@bind-team, this is 3 years old review of BIND code by Errata Security: https://blog.erratasec.com/2015/07/a-quick-review-of-bind9-code.html and he is right.
We need to start using `const` more extensively _and_ internalise it when writ...@bind-team, this is 3 years old review of BIND code by Errata Security: https://blog.erratasec.com/2015/07/a-quick-review-of-bind9-code.html and he is right.
We need to start using `const` more extensively _and_ internalise it when writing new code and doing reviews.
It is a long term goals, so we will just keep this open, and I'll list major components that should be reviewed:
* [ ] libisc
* [ ] libdns
* [ ] libns
* [ ] libisccfg
* [ ] libiscccc
* [ ] bin/namedLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/270Add make rules to build Kyuafile and Atffile files to tests directories2021-10-04T12:45:09ZMark AndrewsAdd make rules to build Kyuafile and Atffile files to tests directorieshttps://gitlab.isc.org/isc-projects/bind9/-/issues/268create system test for request-nsid which checks the log level is info.2021-10-04T12:44:56ZMark Andrewscreate system test for request-nsid which checks the log level is info.https://gitlab.isc.org/isc-projects/bind9/-/issues/265Silent install2021-10-04T12:43:34ZGhost UserSilent install### Description
I maintain the Chocolatey package for this software. Chocolatey is a Windows application package manager and works best when everything is silent and command-line driven. I've had to write a fairly custom script for each...### Description
I maintain the Chocolatey package for this software. Chocolatey is a Windows application package manager and works best when everything is silent and command-line driven. I've had to write a fairly custom script for each new version to account for the fact that I can't find a silent install flag for `BINDInstall.exe`.
### Request
Silent install flags for the installer, supporting the different modes of install (like "tools only").
### Links / references
https://chocolatey.org/packages/bind-toolsonlyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/257`min-update-interval` option for catalog zones is not described in ARM2021-10-04T12:43:11ZGhost User`min-update-interval` option for catalog zones is not described in ARM`min-update-interval` option for catalog zones is not described in ARM`min-update-interval` option for catalog zones is not described in ARMhttps://gitlab.isc.org/isc-projects/bind9/-/issues/255Remove unnecessary log messages in dns_db_updatenotify_register()/unregister()2021-10-04T12:42:38ZGhost UserRemove unnecessary log messages in dns_db_updatenotify_register()/unregister()These log messages don't exist in `master`.. it seems to be a backporting issue.These log messages don't exist in `master`.. it seems to be a backporting issue.https://gitlab.isc.org/isc-projects/bind9/-/issues/241dnssec system test fails consistently2021-10-04T12:41:32ZCurtis Blackburndnssec system test fails consistentlyon centos 7 and fedora 26 in jenkins, the dnssec system test fails at
```
I:dnssec:check dnskey-sig-validity sets longer expiry for DNSKEY (199)
I:dnssec:failed
```on centos 7 and fedora 26 in jenkins, the dnssec system test fails at
```
I:dnssec:check dnskey-sig-validity sets longer expiry for DNSKEY (199)
I:dnssec:failed
```https://gitlab.isc.org/isc-projects/bind9/-/issues/230Add *.user to .gitignore2021-10-04T12:39:44ZGhost UserAdd *.user to .gitignoreThe .user extension is used by Visual Studio and those files are not required to build BIND on Windows.The .user extension is used by Visual Studio and those files are not required to build BIND on Windows.https://gitlab.isc.org/isc-projects/bind9/-/issues/228win32utils/Configure needs improvement2021-10-04T12:39:23ZBrian Conrywin32utils/Configure needs improvement### Description
win32utils/Configure isn't written in "good" Perl
### Request
- [ ] General rewritting for clarity
- [ ] Refactoring for maintainability
- [ ] add ```use warnings``` (and fix all of the spewage that's sure to create)
-...### Description
win32utils/Configure isn't written in "good" Perl
### Request
- [ ] General rewritting for clarity
- [ ] Refactoring for maintainability
- [ ] add ```use warnings``` (and fix all of the spewage that's sure to create)
- [ ] other errors, as discovered
- [ ] only explicitly requires Perl 5.0.0 but uses the smartmatch operator (```~~```) which wasn't introduced until 5.10.0. Note that this is effectively inconsequential because Perl 5.10.0 was released almost nine years ago.
- [ ] when attempting to infer the VCRedist path, ```@vcpaths``` is initialized as a list containing a hashref, which is then later treated as a string. This is almost certainly just an initialization error rather than an indirect way of getting a 'HASH(0x.........)' string onto the list.
### Links / referencesBrian ConryBrian Conryhttps://gitlab.isc.org/isc-projects/bind9/-/issues/220ISC_SOCKET_MAXEVENTS is too small by default2021-10-04T12:38:29ZCathy AlmondISC_SOCKET_MAXEVENTS is too small by defaultIn a couple of KB articles, we recommend increasing it if necessary. (See: https://kb.isc.org/article/AA-00508/0). When building BIND with `--with-tuning=large` we increase it significantly.
Enough environments encounter the error mes...In a couple of KB articles, we recommend increasing it if necessary. (See: https://kb.isc.org/article/AA-00508/0). When building BIND with `--with-tuning=large` we increase it significantly.
Enough environments encounter the error message *"maximum number of FD events ... received"* that we have considered increasing the default from 64 to 256 in newer versions of BIND - but have yet to do so.
Is now perhaps the time to do this?
References:
* https://bugs.isc.org/Ticket/Display.html?id=28438
* https://bugs.isc.org/Ticket/Display.html?id=29538
* https://support.isc.org/Ticket/Display.html?id=4760
* https://support.isc.org/Ticket/Display.html?id=4963https://gitlab.isc.org/isc-projects/bind9/-/issues/155add version flag to all tools2021-10-04T12:35:42ZCarsten Strotmannadd version flag to all tools### Description
some BIND 9 tools (such as arpaname, named-checkconf, named-checkzone, named-rrchecker, maybe more) don't have a version information that can be printed out.
That makes it harder to identify old versions in the path (i...### Description
some BIND 9 tools (such as arpaname, named-checkconf, named-checkzone, named-rrchecker, maybe more) don't have a version information that can be printed out.
That makes it harder to identify old versions in the path (it would have helped me to identify the problem in issue #151 faster).
### Request
Give all BIND 9 tools / commandline commands a "-V" switch that prints out the BIND 9 release version the binary originated from.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/141RT 43435 - Upload BIND Python module to pypi, package for BIND users2021-10-04T12:33:06ZVicky Riskvicky@isc.orgRT 43435 - Upload BIND Python module to pypi, package for BIND usersRT 43435 - text below is migrated from bugsRT
On Wed, May 3, 2017 at 1:04 PM, Vicky Risk via RT <bind9-bugs@isc.org> wrote:
We discussed uploading a python module for BIND to the pypi repository in our development meeting today. ... ...RT 43435 - text below is migrated from bugsRT
On Wed, May 3, 2017 at 1:04 PM, Vicky Risk via RT <bind9-bugs@isc.org> wrote:
We discussed uploading a python module for BIND to the pypi repository in our development meeting today. ... The open question we are considering is whether to submit just the RNDC components, or <more>. I think Evan is wondering whether it might cause user confusion having multiple different copies of the python library (assuming they are also running BIND).
.......
I wasn't aware the python library was going to be distributed with BIND... but here are some thoughts on that:
A very common (nearly standard) way of operating with python is to work inside what's referred to as a "python virtual environment," or virtualenv/venv. In this environment, libraries and other python packages required by one's work can be installed without interfering with the system packages.. this is very important, for example, when working on tools that have conflicting package (version) requirements.
The packages inside a venv are typically installed using 'pip'.. the python package manager that uses pypi as its back-end.
Getting something installed into a venv that is not on pypi is irritating at best, and occasionally difficult to do. This is especially true for automated deployments where the virtualenv is used in production operations.
For a real-world example, the ldns python bindings are only shipped with the ldns source code, and not in pypi, and as a result I need to have a very compelling reason to need them over any other DNS library (and over just shelling out to an ldns binary) in order to deal with the complexities of working with them.
To view this from another angle: If BIND's 'make install' places the RNDC python libraries on the system in such a way that they're visible to/registered with pip, then end users aren't going to find anything confusing .. because as far as pip is concerned it doesn't matter where the library came from. If the RNDC python library is not visible to/registered with pip, then BIND shouldn't be installing it that way.. it will cause confusion regardless of whether the library is available on pypi or not.
--------
Adding Matt Pounsett as stakeholder, because he has offered us a package that includes just the python RNDC stuff that is ready to upload.
Matt, I can’t find the email from you about the Python package for the BIND RNDC interface. Did you submit it to bind-bugs@isc.org? If you want to reply to this ticket and attach it, it will be easier for us to find it to work on.
I didn't.. this started as a conversation with Ray, and so I emailed him about it. The work I've done so far is in a private repo on github. Github, because it seemed a reasonable place to work on it, and private so that I don't inadvertently share it with anyone other than ISC prior to ISC applying a license to it.
My email to Ray included an offer to add ISC employees' accounts to access the repository and/or hand over full ownership of the repository. Whichever you like. The repo is at <https://github.com/mpounsett/rndc> but that won't be accessible until we do something with access.
There are still a few small steps to be taken before it's ready for upload: notably decisions I couldn't make on behalf of ISC about licensing, development status indicators, etc.https://gitlab.isc.org/isc-projects/bind9/-/issues/140Add safeguards to dnssec key utilities2021-10-04T12:31:48ZBrian ConryAdd safeguards to dnssec key utilitiesWarn when generating DS records for new keys with a different set of algorithm types than the current set of DS recordsWarn when generating DS records for new keys with a different set of algorithm types than the current set of DS recordshttps://gitlab.isc.org/isc-projects/bind9/-/issues/89New Geolocation protocol with greater privacy protection for end user2021-10-04T12:26:02ZVicky Riskvicky@isc.orgNew Geolocation protocol with greater privacy protection for end userCan we try to design a new way to specify the end-users geographic location, for purposes of sending them to an efficient, local content source (as an alternative to EDNS client-subnet-identifier)?
Goals
* Provide authority with informa...Can we try to design a new way to specify the end-users geographic location, for purposes of sending them to an efficient, local content source (as an alternative to EDNS client-subnet-identifier)?
Goals
* Provide authority with information about client geography suitable for routing purposes
* Minimize excessive cache bloating by only carving out caches at a level of specificity actually useful for content routing
* Avoid identifying the client by IP address or other specific identifier (preserving privacy)
Ideas
* The resolver could tag the query with a geo location, rather than forwarding client ID to the authority
* We could consider using the LOC rr (type 29)
* The IATA code (closest airport) is probably granular enough for content routing
* Adding the AS of the network the user is on might also be relevant and useful
We should discuss with the other open source DNS developers, perhaps in our usual get-together at the next IETFNot planned