ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-12-22T10:28:30Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/23DDoS mitigation2023-12-22T10:28:30ZOndřej SurýDDoS mitigationThis is a placeholder bug for general DDoS mitigation techniques that needs to be introduced into BIND to cope with current DNS landscape.This is a placeholder bug for general DDoS mitigation techniques that needs to be introduced into BIND to cope with current DNS landscape.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/34Mechanism to propagate ACLs and Views to multiple BIND servers2022-05-30T04:17:04ZVicky Riskvicky@isc.orgMechanism to propagate ACLs and Views to multiple BIND serversWhen we introduced catalog zones, we immediate began getting requests to provide centralized configuration for other frequently-updated parts of the configuration, including views and the ACL list.
The suggestion was to extend catalog ...When we introduced catalog zones, we immediate began getting requests to provide centralized configuration for other frequently-updated parts of the configuration, including views and the ACL list.
The suggestion was to extend catalog zones for this purpose, but that may not be an appropriate solution. Any mechanism that is not unnecessarily complex that will facilitate centralized management of the views and ACL list for a server farm is desirable.
* A push rather than a pull mechanism may be preferable, to avoid the notify overhead.
* There must be some way to centrally monitor which servers have successfully updated their configuration via this method, perhaps some versioning system for the configuration.
* It is desirable to be able to create an updated list of views and ACL list and schedule the change to be applied at a later time (e.g. for the case where the ACL is required for regulatory reasons to take effect on a certain day).
See also the related feature request RT# 44546, Extend Catalog zones to provision viewsNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/35RPZ local zone with generic passthrough2024-03-27T13:38:49ZVicky Riskvicky@isc.orgRPZ local zone with generic passthroughSee also related RT feature requests #41833, 44607 and https://datatracker.ietf.org/doc/draft-vixie-dns-rpzSee also related RT feature requests #41833, 44607 and https://datatracker.ietf.org/doc/draft-vixie-dns-rpzNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/36Database backend for storing and managing zone files2018-02-21T22:59:01ZVicky Riskvicky@isc.orgDatabase backend for storing and managing zone filesWhen we implemented dynDB it was thought this could be our generic database backend interface. However the only database module that exists is the RedHat FreeIPA (LDAP) module.
Create a module that works with BIND via the dynDB interfac...When we implemented dynDB it was thought this could be our generic database backend interface. However the only database module that exists is the RedHat FreeIPA (LDAP) module.
Create a module that works with BIND via the dynDB interface, or otherwise enable an ISP (for example) to
* manage BIND zone files in an external database, updating and adding zone records directly in the database
* store them in wire-format so the time to serve them is not significantly slower than native named zone files
* this should enable 'dynamic' zone addition and deletion without restarting BIND
* support using a local database per BIND server with database replication so multiple BIND servers can get updates within ~5 minutes of update on the master
* MariaDB is suggested but the choice of database is flexibleNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/38Statistics System Overhaul2023-07-12T15:30:36ZRay BellisStatistics System OverhaulThe statistics layer in BIND suffers from poor separation of concerns, with several parts of BIND and its libraries each containing code for rendering statistics in XML, JSON, or in plain text. This leads to inconsistencies in the outpu...The statistics layer in BIND suffers from poor separation of concerns, with several parts of BIND and its libraries each containing code for rendering statistics in XML, JSON, or in plain text. This leads to inconsistencies in the output, as well as making it harder to extend. The individual modules that generate statistics should be agnostic to the output format.
With some core parts of BIND likely to be moved into individual hooks modules (#15) we need a way to record and access statistics without them having to be allocated space in static built-in structures.
The proposal then is to replace the existing static statistics structures with an _abstract, extensible data store_ represented as a nested tree of key-value objects. BIND components would _register_ counter variables within the tree of objects, and retain fast access to those variables by retaining copies of an _opaque pointer_ for each variable.
The existing XML and JSON renderers would be replaced with generic code that can serialize the tree (or portions thereof) by enumeration without specific knowledge of the keys and values stored therein.
The supported data types would be:
* gauge
* counter
* timestamp
* text label
with additional structural types to create the tree of:
* object
* array
Wherever possible values should be accessed using atomic operations. Each variable should have a name that would be used in the XML renderer (or an implicit index for array elements). Each variable should have its associated description attached, although in cases where many variables share the same meaning (i.e. multiple entries in an array) we should be careful to avoid memory bloat.
Access to individual variables needs to be an O(1) operation for performance. Enumeration of the tree should be O(total size of tree). If variables are to be dynamically inserted or deleted, this should be O(log n) or better.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/50NSEC3 Aggressive Caching (without opt-out)2022-06-09T13:22:39ZOndřej SurýNSEC3 Aggressive Caching (without opt-out)The NSEC3-without-opt-out should be added to NSEC Aggressive Caching feature.The NSEC3-without-opt-out should be added to NSEC Aggressive Caching feature.https://gitlab.isc.org/isc-projects/bind9/-/issues/53Implement "NXDOMAIN cut" (RFC 8020)2023-11-02T16:32:26ZStéphane BortzmeyerImplement "NXDOMAIN cut" (RFC 8020)BIND has "NSEC aggressive caching" (NSEC-only, see #50) but this requires DNSSEC. For non-DNSSEC zones, "NXDOMAIN cut" could be interesting (RFC 8020).
It is already implemented in Unbound (option "harden-below-nxdomain:")
[Is there a ...BIND has "NSEC aggressive caching" (NSEC-only, see #50) but this requires DNSSEC. For non-DNSSEC zones, "NXDOMAIN cut" could be interesting (RFC 8020).
It is already implemented in Unbound (option "harden-below-nxdomain:")
[Is there a tag "Resolver"? This could be useful for resolver-only features.]Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/63Request: BIND 9 control statement should allow address match list2018-03-13T14:49:02ZCarsten StrotmannRequest: BIND 9 control statement should allow address match listcurrently the BIND 9 control statement to configure the rndc channel takes a single IP-address, or "*" for "all addresses", to configure the interface the BIND 9 process should listen on rndc control messages.
it would be helpful in som...currently the BIND 9 control statement to configure the rndc channel takes a single IP-address, or "*" for "all addresses", to configure the interface the BIND 9 process should listen on rndc control messages.
it would be helpful in some situations to be able to control the interfaces for rndc more finegrained with an address match list (ACL)https://gitlab.isc.org/isc-projects/bind9/-/issues/65Request: rndc function to print zone content over rndc channel2018-03-13T14:48:48ZCarsten StrotmannRequest: rndc function to print zone content over rndc channelSometimes for scripting and debugging purposes it would be helpful to be able to obtain the content of a zone via "rndc" (in cases where zone transfer is restricted or turned off)
example:
```
$ rndc printzone example.com
example.com. ...Sometimes for scripting and debugging purposes it would be helpful to be able to obtain the content of a zone via "rndc" (in cases where zone transfer is restricted or turned off)
example:
```
$ rndc printzone example.com
example.com. 3600 IN SOA ns1.example.com. ...
example.com. 3600 IN NS ns1.example.com.
[...]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/74Encrypt/ pseudonymize IP addresses in log files2018-02-21T18:11:16ZVicky Riskvicky@isc.orgEncrypt/ pseudonymize IP addresses in log filesUsers who need to store log files wish to minimize the possibility of leaking information that easily identifies users. Applying some encrpyption to obfuscate addresses provides some protection. There are several use cases:
1) With the ...Users who need to store log files wish to minimize the possibility of leaking information that easily identifies users. Applying some encrpyption to obfuscate addresses provides some protection. There are several use cases:
1) With the advent of GDPR, operators of public dns services (e.g. ISP resolvers) may require the ability to encrypt these logs as they are created, so the only stored data they have is at least anonymized. If the logs are leaked somehow, it will at least require some effort to de-anonymize them. These operators may need to be able to decrypt to uncover the original IP address, in case their analysis shows abuse that they need to block.
2) Operators of root servers, ccTLDs, gTLDs and other public services may wish to be able to share data for research purposes (e.g. with DNS-OARC's ditl program). In this case, it is preferable that the encryption not be reversible, and it is desirable to be able to run the encryption on an existing log file. This use case is already under discussion in RSSAC.
* It would be ideal to be able to apply this pseudonymization to both native BIND logs and dnstap log files.
* Performance is obviously an important consideration.
* This will need to work for both IPv4 and IPv6 addresses and the result fit into the space in the logs reserved for those addresses (which are obviously different lengths).
Relevant existing work:
* Bert Hubert has created a tool, 'ipcipher' `https://powerdns.org/ipcipher/` for Power DNS. He gave a presentation at NDSS DNS Privacy Workshop that described some of the issues with implementing this. Others have created additional implementations, including one by Frank Denis in C.
* There is also apparently a NIST standard for format-preserving encryption. (Paul Hoffman knows about this)
Other things that are needed:
* Tool you can pipe an existing pcap through that will produce a log file where IP addresses are encrypted (producing output that is irreversible)
* Utility that enables frequent key rotation for this processNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/75Change the CHANGES file format and process of creating the file2023-11-20T11:30:43ZOndřej SurýChange the CHANGES file format and process of creating the fileThe current practice of updating CHANGES file for BIND 9 is:
```
[<num>]. [<tag>] Description that could
span multiple lines [<#bugnumber>]
```
Where <num> is incrementing number that doesn't carry any usefu...The current practice of updating CHANGES file for BIND 9 is:
```
[<num>]. [<tag>] Description that could
span multiple lines [<#bugnumber>]
```
Where <num> is incrementing number that doesn't carry any useful information beyond (`grep -E '^[[:space:]]*[0-9]+\.' CHANGES | wc -l`)
While speaking with @michal about the possibility how to automate the CHANGES file description, I started to doubt what would be the intended audience of current file.
The CHANGES file is a subset of our git log and superset of release notes. It includes all the little details about what has changed in the current release, and I don’t think there’s a user that would be able to checkout git repository, but would look at CHANGES file instead of just doing `git log`.
I came to two conclusions:
1. It is useful to archive the changes in the release tarball generated at the release time
2. It makes no sense to update CHANGES file as we go
As for automatically generating the ChangeLog at the release time, I currently see two options:
a) take approach similar to the Linux kernel, simply exporting all the “Merge commits” into a file https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.4
b) use a specially formatted commits and helper tool like gitchangelog (https://github.com/vaab/gitchangelog) to create a subset of commits into a meaningful ChangeLog file.
Please comment if you know about a sensible reason why keep updating CHANGES file with the information already contained in the git log, please speak now, otherwise add a comment with your preference for either a) or b). Alternatively, you can propose alternative approach for generating ChangeLog file at the release time.
(This issue isn't about *RELEASE NOTES*, just about the CHANGES file.)https://gitlab.isc.org/isc-projects/bind9/-/issues/85Automatic database filename generation2021-08-25T15:37:12ZRay BellisAutomatic database filename generationNSD has the ability to automatically generate a zone's filename based on a template string, instead of requiring them to be specified within each zone's configuration:
```
%s is replaced with the zone name.
...NSD has the ability to automatically generate a zone's filename based on a template string, instead of requiring them to be specified within each zone's configuration:
```
%s is replaced with the zone name.
%1 is replaced with the first character of the zone name.
%2 is replaced with the second character of the zone name.
%3 is replaced with the third character of the zone name.
%z is replaced with the toplevel domain name of the zone.
%y is replaced with the next label under the toplevel domain.
%x is replaced with the next-next label under the toplevel
domain.
```
It would be useful if BIND has a similar feature. This would also work well with Catalog Zones, where it is not expected that the Catalog Zone itself would hold the filename, but where the secondary server would synthesise a filename for itself.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/102[RT#43428] Silence some 'expected' logging messages2018-02-23T19:57:38ZVicky Riskvicky@isc.org[RT#43428] Silence some 'expected' logging messagesThe user is a high volume hosting provider.
Under attack scenarios, the amount of logging BIND is doing can make a difference.
This user would like to be able to silence some sorts of frequently-recurring messages that are 'expected', ...The user is a high volume hosting provider.
Under attack scenarios, the amount of logging BIND is doing can make a difference.
This user would like to be able to silence some sorts of frequently-recurring messages that are 'expected', because they are basically probing behavior from prospective attackers. An example would be an unsuccessful AXFR from a client that is not permitted to AXFR.
things that would ideally be logged at a higher level:
- Successful AXFR
- Terminated AXFR
- Unsuccessful AXFR from an authorized clientNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/104[RT#43640] Tool to gather all necessary files to accompany a core dump2018-05-30T23:53:20ZVicky Riskvicky@isc.org[RT#43640] Tool to gather all necessary files to accompany a core dumpWhen customers or others report a crash to us, they often don't understand what we need to be able to analyze the coredump file.
Evan said 'it would be cool to be able to run a tool that collects all the necessary file and tars them up ...When customers or others report a crash to us, they often don't understand what we need to be able to analyze the coredump file.
Evan said 'it would be cool to be able to run a tool that collects all the necessary file and tars them up ready to be submitted'.
Such a tool would need to be able to identify the binary from the core dump (or, optionally be told which is is), run ldd against the binary, collect all the libs, collect the debug symbols/package if these are separate and so on.
(There may be some contributed scripts around that are more generic we could use as the basis for this?)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/107[RT#45306] RNDC & Views2018-02-23T20:23:34ZVicky Riskvicky@isc.org[RT#45306] RNDC & ViewsIt would be useful if rndc treated views as first-class objects.
Its command syntax has the [view] last, so while several commands act
on "all" when no target is specified, you can't say "all in this view".
There are a number of cases...It would be useful if rndc treated views as first-class objects.
Its command syntax has the [view] last, so while several commands act
on "all" when no target is specified, you can't say "all in this view".
There are a number of cases where one would like to do things to
all zones in a view.
The immediate example is this:
rndc freeze/thaw have the syntax:
freeze [zone [class [view]]]
thaw [zone [class [view]]]
I'm in the unfortunate situation of having to do a bulk renumbering
of a view that contains a lot (well, for me) of zones..., and I need
to do an atomic update, while not freezing other views.
For the next round, it would be useful to have something like:
rndc freeze -view internal # Freeze all zones in the "internal" view
...
rndc thaw -view internal
Other cases where a view as a whole seems to be a sensible target:
rndc flush
rndc notify
rndc refresh
rndc reload
rndc retransfer
rndc sync
Thanks.
--
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Download smime.p7s
application/pkcs7-signature 4.4KiBNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/152auto-insert child DS records into parent zones when both are being mastered l...2022-06-05T19:00:48ZBrian Conryauto-insert child DS records into parent zones when both are being mastered locally and having DNSSEC maintained by BIND### Description
Coming from an ops ticket:
On Thu Mar 15 07:28:34 2018, michal@isc.org wrote:
[...]
> There is a DS for 57.20.149.in-addr.arpa. at 20.149.in-addr-arpa., but
> 57.20.149.in-addr.arpa. is not signed:
[...]
> Thus, everythi...### Description
Coming from an ops ticket:
On Thu Mar 15 07:28:34 2018, michal@isc.org wrote:
[...]
> There is a DS for 57.20.149.in-addr.arpa. at 20.149.in-addr-arpa., but
> 57.20.149.in-addr.arpa. is not signed:
[...]
> Thus, everything beneath 57.20.149.in-addr.arpa. is currently bogus.
On Thu Mar 15 08:34:28 2018, dmahoney wrote:
[...]
> I should note that we're still dependent on old-ass perl scripts
> because BIND still lacks the ability to auto-insert child DS records
> into parent zones when both are managed by BIND. This is the missing
> link in all the key-management magic we keep offering up.
### Request
Create the missing link.
I should think that it would even be possible if the child zone is a secondary but with inline signing.
I'm less certain, but wonder if it might be permissible even if the parent is secondary but with inline signing.
### Links / referenceshttps://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/170Affinity for Notifies and Updates2021-10-04T18:08:17ZVicky Riskvicky@isc.orgAffinity for Notifies and Updates### Description
For large authoritative implementations with a large matrix of multiple layers of transfer servers and slaves with multiple alternative masters, it is possible that a slave will get a notify message, and the master they ...### Description
For large authoritative implementations with a large matrix of multiple layers of transfer servers and slaves with multiple alternative masters, it is possible that a slave will get a notify message, and the master they contact for an update may not yet have received that update.
### Request
Ensure that slaves only request update transfers from one of the servers that have sent them a notify message.
### Links / referencesOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/172rrl tests fail intermittently2023-08-23T12:50:45ZOndřej Surýrrl tests fail intermittentlyWe have one occurrence here:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/5453
```
S:rrl:Mon Mar 19 16:25:54 UTC 2018
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTRANGE:11400 - 11499
I:rrl:0 instead of 50 '192.0.2.8' responses for a*...We have one occurrence here:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/5453
```
S:rrl:Mon Mar 19 16:25:54 UTC 2018
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTRANGE:11400 - 11499
I:rrl:0 instead of 50 '192.0.2.8' responses for a*.a9.tld2
I:rrl:60 instead of 10 dropped responses for a*.a9.tld2
I:rrl:0 instead of 50 NOERROR responses for a*.a9.tld2
I:rrl:exit status: 1
R:rrl:FAIL
E:rrl:Mon Mar 19 16:26:13 UTC 2018
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/211Feature Request to Allow Dynamic Addition/Removal of Forwarders (similar to r...2024-02-14T14:23:14ZCathy AlmondFeature Request to Allow Dynamic Addition/Removal of Forwarders (similar to rndc addzone)[ISC-support #12719]
Originally submitted to BUGs as https://bugs.isc.org/Ticket/Display.html?id=35890
An ISC Support customer expressed surprise at the failure, after trying, and failing (but with side-effects) to add a zone of type "forward" using rndc a...
Originally submitted to BUGs as https://bugs.isc.org/Ticket/Display.html?id=35890
An ISC Support customer expressed surprise at the failure, after trying, and failing (but with side-effects) to add a zone of type "forward" using rndc addzone.
Per discussion with engineering at the time, addzone isn't intended to support addition of zone type forward AND forward zones aren't really traditionally zone-like so it does not work. The ARM is/was incorrect to suggest that it does.
Further information around this is available on bind-users:
https://lists.isc.org/pipermail/bind-users/2016-November/098007.html
This feature is still wished-for.
Also
'"rndc addzone" does not handle zones of all types which can be defined
in named.conf. this is intended, but not documented in the ARM or elsewhere.
It would be good if the behavior were documented and clear error messages
were emitted when a zone of the wrong type was attempted'
From [Support ticket #6898](https://support.isc.org/Ticket/Display.html?id=6898)
Also from [Support ticket #12719](https://support.isc.org/Ticket/Display.html?id=12719)
And others have asked too..Not planned