BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-12-22T10:28:30Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/15Modules and hooks2023-12-22T10:28:30ZOndřej SurýModules and hooksAdd support for externally loaded modules to hook into query-response processing.
Requirements
============
* Implement an pluggable interface to add a module that would access and possibly modify the query-response processing
* The mod...Add support for externally loaded modules to hook into query-response processing.
Requirements
============
* Implement an pluggable interface to add a module that would access and possibly modify the query-response processing
* The modules would be using versioned API
* The modules could be dynamically loaded or statically compiled in
* Only C modules would be supported in 1st phase
* More programming languages could be added later (Rust, Go, Lua)
* There would be a multiple entry points as the query-response gets processed by BIND
* Before reading any data from the socket
* After reading DNS message from the socket
* Before entering view
* After entering view
* Before ACL
* After ACL
* (Authoritative) Before reading the zone data
* (Authoritative) After reading the zone data
* (Recursive) Before sending each recursive query
* (Recursive) After receiving each recursive query
* Before sending a reply to a socket
* After sending a reply to a socket
* Before stats are produced (finalized?)
* On module load
* On module unload
* RNDC should probably also include multiple entry points, so module can add new commands, extend/modify existing command, and/or modify the processing of existing commands.
* The module should have access to most context data related to query, parent query, subqueries, answer and internal state
* The module should be able to specify its entry points from within the module
* The module should be able to specify module dependencies and load order for each entry point
* It must be possible to load multiple instances of a single module
Technical Specification
=======================
* Plugin API will be specified, there are number of other projects that utilize loadable dynamic and/or static plugins
* Apache
* Kea
* PHP
* SASL
* The API needs to use opaque pointers and the API should be kept as stable as possible
* ...
Sample Configuration Syntax
===========================
```
acl exempt { 10.53.0.7; };
options {
directory "/etc/bind";
recursion yes;
dnssec-validation auto;
};
hooks {
path "/usr/local/lib:/etc/hooks:";
query rebound.so; // no options; use default settings
query filter-aaaa.so {
filter-on-v4 yes;
filter-on-v6 no;
};
query rpz.so {
response-policy {
zone "policy1"; // note this is defined outside the hooks block
zone "policy2";
} qname-wait-recurse no
nsdname-enable yes
nsip-enable yes;
};
};
query rrl.so {
responses-per-second 10;
all-per-second 50;
slip 3;
exempt-clients {
exempt; // note this is defined outside the hooks block
};
};
};
zone policy1 {
type master;
file "policy1.db";
};
zone policy2 {
type slave;
masters { 10.53.0.1; };
file "policy2.db";
};
```
Notes on Configuration
======================
* Initially, hook modules will probably be limited to query processing, but there could also be hooks, for example, for update, notify, or xfr. This is why "query" is specified for each hook module above. This is probably not strictly necessary - the names of the modules should be sufficient to disambiguate them - but it may be necessary for query modules to be initialized differently from update modules. It should in any case help with readability for the user.
* Just as with `zone`, a `hooks` block can be at the top level of `named.conf` or it can be under `view`. A server with multiple views cannot have a global-level `hooks` block.
* The configuration options are passed to hooks as bracketed_text (same as with `dyndb` and `dnsrps`). The hook module itself will parse the options. This means the `named` parser doesn't have to understand the module's configuration syntax. A pointer to the parser context must be provided to the module at initialization time so it can reference names that are defined elsewhere (such as the `exempt` ACL in the above sample).
* Hook modules will need to share an address space with `named` and be initialized with pointers to the view, zone table, server context, etc.
* Hook modules will specify their own entry/callback points. In other words, it would not be necessary for the user to specify that filter-aaaa taps in at the "pre-response" entry point; it can do that by itself.
* If more than one hook uses the same entry/callback point, the order in which they are listed in `hooks` sets priority. (In the above example, rebound would precede filter-aaaa.) We can add syntax to override default priorities for certain entry points if that turns out to be necessary.
BIND-9.13.6Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/22Do an crypto algorithm audit and remove obsolete / insecure crypto algorithms2023-12-22T10:28:30ZOndřej SurýDo an crypto algorithm audit and remove obsolete / insecure crypto algorithmsThis is like a general and recurring issue. For each release we should review the used crypto algorithms and remove/deprecate the insecure and obsolete algorithms (RSAMD5 was a fine example)? Perhaps also change the recommended and def...This is like a general and recurring issue. For each release we should review the used crypto algorithms and remove/deprecate the insecure and obsolete algorithms (RSAMD5 was a fine example)? Perhaps also change the recommended and default algorithms.BIND-9.13.6Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/101[Support#12071] [RT#46548] Output stale/expired data with 'rndc dumpdb'2020-05-22T14:11:01ZVicky Riskvicky@isc.org[Support#12071] [RT#46548] Output stale/expired data with 'rndc dumpdb'Now that there are ways to serve stale data from the cache, it would be
good to be able to see with dumpdb what records there are that might end
up being served, even though those records wouldn't show up in a regular
dumpdb.
Update 201...Now that there are ways to serve stale data from the cache, it would be
good to be able to see with dumpdb what records there are that might end
up being served, even though those records wouldn't show up in a regular
dumpdb.
Update 2018-12-13: Stale data is actually already included in the `dumpdb` output. In addition to the stale RRsets it would be nice to also output for how long this stale data is still available in the cache. This needs to be determined by the configuration option 'serve-stale-max-ttl'.BIND-9.13.6https://gitlab.isc.org/isc-projects/bind9/-/issues/315'forward first' configuration can forward much more often than just 'first'2019-01-08T10:00:04ZBrian Conry'forward first' configuration can forward much more often than just 'first'<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
With 'forward first' it seems that named sometimes asks the forwarder(s) more often than just 'first'.
### Steps to reproduce
This requires a non-responding forwarder (e.g. silent failure / timeout, but any other failure mode that triggers fallback to iterative recursion may also behave the same way (untested))
Configure the server for 'forward first'.
With an empty cache, query for a name that will require named to follow several delegation trails, e.g. through delegation or through CNAMEs.
www.amazon.co.uk/A is a good example.
### What is the current *bug* behavior?
named (correctly) first sends the original question to the forwarder(s), then asks one of the root servers (using hints to find the address).
After receiving the referral (e.g. to the servers for 'uk'), before sending the original query to any of the referred-to servers named will send *another* copy of the original question to all of the forwarders. This is believed to be an error.
At each new referral (e.g. from 'uk' to 'co.uk' and from 'co.uk' to 'amazon.co.uk') named will send yet another copy of the original question to all of the forwarders before asking any of the new referrals. This is again believed to be an error.
### What is the expected *correct* behavior?
The expected behaviour is that, in the process of resolving a query, in a 'forward first' configuration named will give each forwarder one, and only one, chance to provide an answer to each distinct query before falling back to recursion.
Learning the list of servers that the root zone delegates 'uk' to should not be sufficient cause to expect that the forwarders may have a better answer to the same question they failed to answer previously
It does make sense for the forwarders to be given a chance to answer new questions (such as resolving the addresses of the delegated-to servers), but we don't need to be sending them the same questions repeatedly. The option is 'forward first', not 'forward first-and-alternating-thereafter'.
### Relevant logs and/or screenshots
```named.conf
options {
forward first;
forwarders {
8.8.8.8;
8.8.4.4;
};
};
```
This is sufficient to demonstrate as long as both 8.8.8.8 and 8.8.4.4 are null routed (e.g. static routes exist that forward the packets to a host that will drop them silently).
I have an ```rr``` recording of this that can be examined. Will be attached once the issue number is known.
### Notes
This issue was observed as part of a customer-reported issue, but only contributed indirectly to the customer issue.BIND-9.13.6Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/364RPZ Ignored When RRL Enabled2019-01-23T13:37:34ZThomas JachRPZ Ignored When RRL EnabledWhen RRL (Response Rate Limiting) is enabled (i.e. on an authoritative server) and the response rate limit is reached, BIND still returns responses for queries that would have been dropped via RPZ (Response Policy Zones) otherwise. The e...When RRL (Response Rate Limiting) is enabled (i.e. on an authoritative server) and the response rate limit is reached, BIND still returns responses for queries that would have been dropped via RPZ (Response Policy Zones) otherwise. The expected behavior certainly is that BIND skips RRL checking if the query matches an RPZ item.
For example, if
`rate-limit { responses-per-second 15; window 15; }`
is set in named.conf, queries for 'test.example.com' should be dropped if
`*.example.com CNAME rpz-drop.`
is set in the RPZ zone.
However, if the rate limit is reached, BIND ignores RPZ and returns a response (slip through) for 'test.example.com'.BIND-9.13.6https://gitlab.isc.org/isc-projects/bind9/-/issues/628Remove support for insecure RSAMD52018-12-11T14:21:09ZOndřej SurýRemove support for insecure RSAMD5BIND-9.13.6Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/674Abort when memory allocation or other mandatory resource allocation fails2019-01-09T21:03:29ZEvan HuntAbort when memory allocation or other mandatory resource allocation failsIn discussion at the group meeting in Amsterdam, we decided that going forward, we should have `isc_mem_get()` and `isc_mem_allocate()` abort rather than returning NULL when the system is out of memory.
We should expand this to other re...In discussion at the group meeting in Amsterdam, we decided that going forward, we should have `isc_mem_get()` and `isc_mem_allocate()` abort rather than returning NULL when the system is out of memory.
We should expand this to other resources like:
* pthread mutexBIND-9.13.6https://gitlab.isc.org/isc-projects/bind9/-/issues/735Remove ability to disable DBC assertions2019-01-31T10:37:20ZOndřej SurýRemove ability to disable DBC assertionsThere's a strong rationale for removing the ability to disable REQUIRE/ENSURE/INSIST assertions:
1) we don't write the code in a way that allows the assertions to be disable;
2) we don't really test the code with disabled assertionsThere's a strong rationale for removing the ability to disable REQUIRE/ENSURE/INSIST assertions:
1) we don't write the code in a way that allows the assertions to be disable;
2) we don't really test the code with disabled assertionsBIND-9.13.6Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/787RTLD_DEEPBIND and AddressSanitizer aren't compatible2018-12-19T11:48:50ZOndřej SurýRTLD_DEEPBIND and AddressSanitizer aren't compatibleMixing AddressSanitizer and `RTLD_DEEPBIND` doesn't really work well: https://github.com/google/sanitizers/issues/611, so we should disable `RTLD_DEEPBIND` when compiled with ASAN.Mixing AddressSanitizer and `RTLD_DEEPBIND` doesn't really work well: https://github.com/google/sanitizers/issues/611, so we should disable `RTLD_DEEPBIND` when compiled with ASAN.BIND-9.13.6Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/818Improve mirror zone logging2019-01-18T14:48:09ZMichał KępieńImprove mirror zone loggingLogging messages whenever a mirror zone transitions from being "usable" to "unusable" and vice versa might be helpful for troubleshooting purposes - currently, mirror zone logging is virtually identical to secondary zone logging while (u...Logging messages whenever a mirror zone transitions from being "usable" to "unusable" and vice versa might be helpful for troubleshooting purposes - currently, mirror zone logging is virtually identical to secondary zone logging while (un)availability of mirror zone data has different implications than for secondary zones.BIND-9.13.6Michał KępieńMichał Kępień