BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:42:12Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1156isc_refcount_increment0 is wrong, the code using it needs refactoring2023-11-02T16:42:12ZOndřej Surýisc_refcount_increment0 is wrong, the code using it needs refactoringThe `isc_refcount_increment0()` does two things and that's wrong.
1. The first purpose is to bump the value from `0` -> `1` making the object referenced.
2. The second purpose is to increment the reference counter.
This has several pr...The `isc_refcount_increment0()` does two things and that's wrong.
1. The first purpose is to bump the value from `0` -> `1` making the object referenced.
2. The second purpose is to increment the reference counter.
This has several problems:
1. You can't check whether the previous value really was `0`.
2. When object becomes dereferenced with `isc_refcount_decrement() == 1`, the `isc_refcount_increment0()` can make it referenced again while destroying the object.
There are two things that we could do about it:
1. Don't use isc_refcount API when it's not reference counting, prepare similar API for object counting (isc_objcount?)
2. Use `isc_refcount_init()` when initializing object for the first time (note that `isc_refcount_init()` is not atomic)
3. Always initialize the value to `1` and adjust the code that destroys the object
4. Split `isc_refcount_increment0()` to `isc_refcount_incfirst()` and existing `isc_refcount_increment()`
Nevertheless, the overloading of the API for `<1, MAX>` and `<0, MAX>` reference counting is wrong.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1147Feature request for logging TSIG on client queries and/or in RPZ rewrites2023-11-02T16:42:12ZCathy AlmondFeature request for logging TSIG on client queries and/or in RPZ rewritesFrom Support Ticket [#14942](https://support.isc.org/Ticket/Display.html?id=14942)
The use case is a scenario where for clients with 'stable' IP addresses, access to a set of custom resolvers is permitted by client IP address, but for o...From Support Ticket [#14942](https://support.isc.org/Ticket/Display.html?id=14942)
The use case is a scenario where for clients with 'stable' IP addresses, access to a set of custom resolvers is permitted by client IP address, but for other more mobile clients, is done via TSIG key.
Clients are identifiable either by source IP or by TSIG key being used.
It is a local requirement that it be possible to identify which clients have made queries that have been rewritten via RPZ (the obvious use case here being to identify clients that might have been infected with malware).
The easiest way to identify the TSIG-capable migratory clients would be to have to RPZ logging identify clients not just by IP address, but by TSIG key used (if any).
Another tack (if RPZ processing doesn't have access to the client query context with the TSIG key) might be to emit this in dnstap or query logging and then cross-reference or otherwise identify clients that 'need to be identified' on the basis of the queries they're making.
How hard would this be to achieve and also to integrate into BIND in such a way that the feature doesn't detrimentally affect users who are not interested in whether or not their client queries arrive with TSIG?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1141named-checkzone should check jnl to avoid a zone not loading due to: journal ...2023-11-02T16:42:11ZGhost Usernamed-checkzone should check jnl to avoid a zone not loading due to: journal out of sync with zone (and other related issues)### Description
1. If a non-dynamic but journaled zone is modified when named is stopped, named cannot load the zone on startup. (This could be considered a bug, but is being filed as a feature request.) Likewise, the same situation can ...### Description
1. If a non-dynamic but journaled zone is modified when named is stopped, named cannot load the zone on startup. (This could be considered a bug, but is being filed as a feature request.) Likewise, the same situation can occur with named running, if the journal isn't properly updated during a zone reload (That scenario can be forced by removing write access to the journal file).
1. When ixfr-from-differences is set, the -j option for named-checkzone incorrectly reports sync problems. Perhaps I'm getting too far out over my skis, but I think that -j in the presence of ixfr-from-differences is never useful and commonly wrong.
### Request 1
* Ideal request: named-checkzone should discover problem number 1 and give a warning.
* This is not just requesting that named-checkzone default to use the '-j' option.
* There will be problems trying to implement this. It requires named-checkzone to know that "ixfr-from-differences true;" has been set, which would require reading named-checkconf. (We don't want a warning if ixfr-from-differences not set.) Additionally, named-checkzone would also need to read named-checkconf to find the journal file. Yes, it could assume that the journal is in the same directory as the zone file, and has the default file name, however, that doesn't cover all cases.
* More realistic request: named-checkconf -z should discover the problem without requiring the -j option.
### Request 2 (Perhaps this is a bug)
When ixfr-from-differences is set, the -j option incorrectly reports journal rollforward problems, and claims that the zone will not load, when everything is in fact fine and rndc reload works perfectly well.
The scenario is simple common use:
1. The zone file is modified manually. The SOA serial is increased.
1. named-checkzone reports no errors.
1. named-checkzone -j incorrectly reports: "jounal rollforward"
1. rndc reload works perfectly.
1. named-checkzone -j reports no errors.
### Question
Are there similar documented cases of "named-checkzone <zone> <zone-file>" reporting a zone OK, but named not being able to load it? If the answer is no, than this seems like a bigger deal to me. Perhaps incorrectly, but it is widely accepted that when named-checkzone reports no errors, it is safe to reload the zone. If there are already several cases where that is not true, than this is just one more. However, if this case is unique, the trust in named-checkzone has a crack in its foundation.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1128[ISC-support #22100] Offline KSK2024-03-26T10:42:53ZMatthijs Mekkingmatthijs@isc.org[ISC-support #22100] Offline KSKImplement offline key support.
This will require signatures for `DNSKEY`, `CDS`, and `CDNSKEY` RRsets to be generated in advance. This is done with a Key Signing Request (`KSR`). On the system with the KSK provide the `KSR` and ask to c...Implement offline key support.
This will require signatures for `DNSKEY`, `CDS`, and `CDNSKEY` RRsets to be generated in advance. This is done with a Key Signing Request (`KSR`). On the system with the KSK provide the `KSR` and ask to create signed RRsets for each period (resulting in Signed Key Responses (`SKR`)).
This also means that `DNSKEY` records for the ZSK need to be pregenerated, because ZSK rollovers may take place while the KSK is offline.
This also means that "Offline KSK" does not work in conjunction with a CSK because we need to resign the zone contents periodically.
Pregenerating keys can be done with `dnssec-keygen`, or some other method. But we need to provide a `dnssec-policy` and a duration for how long a period we need to create SKRs. For example if you have a policy where ZSKs are rolled every 3 months, and you want to keep the KSK offline for a year, the key generation utility should create 4 keys. The keys should have additional metadata that sets `Predecessor` and `Successor` key metadata and/or set the `Published` and `Remove` timing metadata.
We need to load the `SKR` files. Probably import it before hand with `rndc reconfig` or `rndc import skr` or something. Then when BIND decides to rekey it needs to lookup the correct `DNSKEY`, `CDNSKEY`, and `CDS` records from the `SKR` sign, and when BIND decides to resign it needs to lookup the signatures from the same `SKR` data.
When BIND starts a new key rollover, it should select the right key. This is determined by the metadata. The new keyset must match the `SKR` data.
If the `dnssec-policy` changes, the KSR process needs to be done again and the new SKR files should be imported.
So the following changes to the code and documentation need to be made:
- [ ] Create a tool `dnssec-ksr` for dealing with KSRs (!8188)
- [ ] Add an option to `dnssec-ksr` to generate keys given an interval and a DNSSEC policy (!8188)
- [ ] Add an option to `dnssec-ksr` to create `KSR` files given an interval, a DNSSEC policy, and some keys (!8188)
- [ ] Add an option to `dnssec-ksr` to sign `KSR` files, generating `SKR` files to be imported into BIND (!8188)
- [ ] Create signed `CDS` and `CDNSKEY` RRsets in the `SKR` files (!8188)
- [ ] Add a configuration option for `named` to set a `SKR` directory.
- [ ] Add a command line option for `rndc` to import a `SKR` file or directory.
- [ ] When rekeying, make sure that the `DNSKEY`, `CDNSKEY`, and `CDS` records match the `SKR` data.
- [ ] When resigning, lookup the signature in the `SKR` data rather than trying to generate a new signature.
- [ ] Add a checkconf check that Offline KSK cannot work with CSK.
- [ ] Add documentation about Offline KSK to the ARM and DNSSEC guide.BIND 9.19.xMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1127Add configuration for type of key rollover2023-09-07T05:11:21ZMatthijs Mekkingmatthijs@isc.orgAdd configuration for type of key rolloverWe can either decide to choose the optimal key rollover, or we can let the user to configure what key rollover they want to use.We can either decide to choose the optimal key rollover, or we can let the user to configure what key rollover they want to use.Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1113Use per-query GeoIP2 entry cache2023-11-02T16:42:11ZEvan HuntUse per-query GeoIP2 entry cacheAn idea suggested by @ondrej in relation to https://gitlab.isc.org/isc-projects/bind9/merge_requests/2031#note_64941:
We can improve the GeoIP2 code by storing a copy of the `MMDB_entry` for each database we've consulted in the `ns_clie...An idea suggested by @ondrej in relation to https://gitlab.isc.org/isc-projects/bind9/merge_requests/2031#note_64941:
We can improve the GeoIP2 code by storing a copy of the `MMDB_entry` for each database we've consulted in the `ns_client` object. When we need to make another query to the same database for the same client address (or client ECS address, on 9.11), we already know it's going to get the same answer, so we can keep it and reuse it.
This is currently done with thread-specific state memory in lib/dns/geoip2.c, but would be simpler this way.Not plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1107managed-keys.bind error related to changing working directory back and forth2019-06-25T10:58:28ZOndřej Surýmanaged-keys.bind error related to changing working directory back and forthWhen you change workdir back and forth, the `managed-keys.bind` + journal gets left in the place and then loaded back leading to:
```
25-Jun-2019 12:55:17.921 managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer compl...When you change workdir back and forth, the `managed-keys.bind` + journal gets left in the place and then loaded back leading to:
```
25-Jun-2019 12:55:17.921 managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
25-Jun-2019 12:55:17.922 malformed transaction: managed-keys.bind.jnl last serial 6 != transaction first serial 7
25-Jun-2019 12:55:17.922 managed-keys-zone: keyfetch_done:dns_journal_write_transaction -> unexpected error
25-Jun-2019 12:55:17.922 managed-keys-zone: error during managed-keys processing (unexpected error): DNSSEC validation may be at risk
```
We probably need to cleanup the old file when changing the working directory and doing reconfigs on the fly.https://gitlab.isc.org/isc-projects/bind9/-/issues/1105named-checkconf option to convert deprecated options2019-06-25T07:37:00ZMatthijs Mekkingmatthijs@isc.orgnamed-checkconf option to convert deprecated optionsRequest- an option that would deal with the options that are deprecated and deliver a nice `named.conf`. For example, `managed-keys` and `trusted-keys` would be translated to `dnssec-keys`. Obsoleted options (like `dnssec-enable`) would ...Request- an option that would deal with the options that are deprecated and deliver a nice `named.conf`. For example, `managed-keys` and `trusted-keys` would be translated to `dnssec-keys`. Obsoleted options (like `dnssec-enable`) would be filtered out. This would be useful only if it could also preserve the comments in the file, which currently are stripped by -checkconf.)https://gitlab.isc.org/isc-projects/bind9/-/issues/1099Add the ability to add a record to a zone if the name is not already in use i...2021-10-04T19:30:37ZMark AndrewsAdd the ability to add a record to a zone if the name is not already in use in the zone.This is to allow a machines to grab a unused name for themselves.
Return REFUSED if the name already exists in the zone unless the record itself already exists.
Normally the type list would be restricted to KEY but other types could be u...This is to allow a machines to grab a unused name for themselves.
Return REFUSED if the name already exists in the zone unless the record itself already exists.
Normally the type list would be restricted to KEY but other types could be used.
This would normally be used in conjunction with self/self-sub updates for further updates.
I would restrict this to a single label below given names to prevent one machine hijacking the namespace of another.https://gitlab.isc.org/isc-projects/bind9/-/issues/1079[ISC-support #11491] : rndc sign after a key roll doesn't match covering RRSI...2023-11-02T16:42:10ZVicky Riskvicky@isc.org[ISC-support #11491] : rndc sign after a key roll doesn't match covering RRSIG TTLs with RR TTLs properFrom [BUGS RT #45281](https://bugs.isc.org/Ticket/Display.html?id=45281)
Found in version 9.9.8-P3
------------
The zones are managed using inline signing.
In this specific instance, the signed zone has been adopted from another DNS pr...From [BUGS RT #45281](https://bugs.isc.org/Ticket/Display.html?id=45281)
Found in version 9.9.8-P3
------------
The zones are managed using inline signing.
In this specific instance, the signed zone has been adopted from another DNS provisioning organisation and the public keys imported into the zone using dnssec-importkey. The old RRSIGs will have been expiring naturally since ownership of the zone was transferred.
The next step has been to roll the keys so that the old keys are retired.
The keys were removed by use of:
```
$ dnssec-settime -D -1 /path/to/Ksmplezone.+008+99999.key
$ rndc sign samplezone
```
Following this, and not consistently (as in, not all RRsets have this problem, and not all zones treated to the same process have encountered the issue), but in some cases, the TTLs of the RRSIGs generated don't match the TTLs on the RRsets that they cover. For example:
```
GJ050EV20BAIGROA12RTHHLJD97AF672.samplezone. 10800 IN RRSIG NSEC3 8 2 10800 20170604232817 20170430232547 5586 samplezone. ia4bp3JpaBYZDOj+gBCwPtA+eOPk6vkWCr+lMFM6rzwnye+ZWgNgJ78v 2HipQRAe/X0pQWqoJKimMC1jRU2sj+JTlu9RDvxOA5ZeP6k65e8YIzKY E1NzVXUJ2e+YgomJiI/v72W0MJdEkyW1nQhe7xZ
dFFCzV1FykKlXxoP1 nJT+deFvq6u0wItBWcLsBAphUg9fXhC6hRwNLbg2YasAtBHIT6H/hZqO aQbrriOX0C8FAIckkH5V6v+5aN3QqklMflI/wHbBFOC3ZCBN03AMQkFp bjxY1VLo0vCbvU2LE5PczU5nUbPglLBIIbVI/u5KsflR40J0wwUsEp0v OYUlCg==
GJ050EV20BAIGROA12RTHHLJD97AF672.samplezone. 3600 IN NSEC3 1 0 10 497E730B PGES0URI1U8F2U362CLIDVP1QTSEODPS A RRSIG
```
The mismatch self-corrects as the auto-resigning replaces DNSSEC signatures - it's been created by the use of rndc sign against the zone (and only noticed because of the use of a DNSSEC validator tool that is applied against the zone.
Technically, it doesn't matter that the TTLs don't match, and it shouldn't make a significant operational difference, but it's thought to be better that they do.
The problem doesn't occur if using "rndc loadkeys" instead of "rndc sign" in this situation.
"sign" causes the zone to be fully signed right away using all of the active keys in the DNSKEY rrset, whereas "loadkeys" just updates the DNSKEY rrset and lets the zone carry on as scheduled. In this situation the keys being deleted were not being used to sign the zone, so there should be no need to walk the zone re-signing anything; "rndc loadkeys" is sufficient.
Conclusion - there's a low grade bug in the "rndc sign" code path that sets the TTL incorrectly when generating signatures.
-----------------
A new development on this one - it seems that it's not just 'rndc sign' that does this, but that 'rndc loadkeys' also can (in this instance, it was during the removal of expired keys). The steps were:
- remove the post published keys from several zones
- use rndc loadkeys to get BIND to load the changed keydata
The outcome: RRSIG's original TTL differs from corresponding records'
It's understood that this shouldn't cause client DNSSEC-validators any problems.
From [Support ticket #11491](https://support.isc.org/Ticket/Display.html?id=11491)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1078[ISC-support #10477] Log the rdata when nsupdate deletes a single RR2024-03-27T13:13:01ZVicky Riskvicky@isc.org[ISC-support #10477] Log the rdata when nsupdate deletes a single RRFrom [BUGS RT #44733](https://bugs.isc.org/Ticket/Display.html?id=44733)
Currently we see this:
21-Feb-2017 12:35:20.295 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': adding an RR at 'foo.co.uk' NS ns2.foo.co.uk.
21-Feb-2017 12...From [BUGS RT #44733](https://bugs.isc.org/Ticket/Display.html?id=44733)
Currently we see this:
21-Feb-2017 12:35:20.295 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': adding an RR at 'foo.co.uk' NS ns2.foo.co.uk.
21-Feb-2017 12:35:20.295 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': adding an RR at 'foo.co.uk' NS ns3.foo.co.uk.
21-Feb-2017 12:35:20.296 zone foo.co.uk/IN: sending notifies (serial 59)
21-Feb-2017 12:35:53.752 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': deleting an RR at foo.co.uk NS
21-Feb-2017 12:35:53.757 zone foo.co.uk/IN: sending notifies (serial 60)
Or:
21-Feb-2017 12:29:53.197 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': adding an RR at 'handbag.foo.co.uk' A 127.0.0.2
21-Feb-2017 12:30:11.546 client 127.0.0.1#49131: updating zone 'foo.co.uk/IN': deleting rrset at 'handbag.foo.co.uk' A
In both cases, I know that I deleted one of several RRs in the same RRset, but named has not logged which one it was. This is really unhelpful if you are trying to troubleshoot historically what happened and when.
Since it's a single RR being deleted - the rdata has to have been specified in the nsupdate request, so update.c has to have it. (It would be a different matter if an RRset or all the RRs for a given name were being deleted).
Please can we upgrade the logging to do this a bit better/more helpfully?
--------------------
Actually named always records what changed. That record goes into
the journal. It is complete copy of what changed and it can be
printed out.
Mark
-------------------
Can it also be logged though, since this specific scenario is a singleton RR delete being requested, so we do have the rdata available to do so.
Cathy
-------------------
And named manages the journal, potentially rewriting it at any time, to
be either larger or smaller, and possibly even throwing it away entirely
or recreating it with entirely different contents.
Logging can be easily sent to syslog and from there distributed out to
a remote syslog server for archival and retention.
That isn't so easily done with a zone journal file.
Mark
------------------
<please ...>
More specifically - the case where the nsupdate specifies a single RR delete by providing both the rtype and the rdata in the request.
(I don't think it's necessary to attempt to log when the nsupdate request is for the full rrset or for everything under a specific qname) - then we *know* that they're all gone - there isn't the same problem of not knowing which RR of several has been deleted.)
CathyNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1075Print entire running configuration to a file for troubleshooting, diagnostics...2023-11-02T16:42:10ZVicky Riskvicky@isc.orgPrint entire running configuration to a file for troubleshooting, diagnostics, updatingProvide a way to print out whole configuration that will be used (including default values which are not necessarily specified in the config file.
This would be helpful for BIND QA, as well as for Red Hat, so that we can detect changes...Provide a way to print out whole configuration that will be used (including default values which are not necessarily specified in the config file.
This would be helpful for BIND QA, as well as for Red Hat, so that we can detect changes when updating BIND in RHEL.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1040missing cache expiration test2023-11-02T16:42:09ZEvan Huntmissing cache expiration testWhile examining differences between the 9.11 and 9.11 subscription branches I noticed an unexpected change in `rbtdb.c:expirenode()` - the `force_expire` variable was set to `true` in one and `false` in the other. This bug was introduced...While examining differences between the 9.11 and 9.11 subscription branches I noticed an unexpected change in `rbtdb.c:expirenode()` - the `force_expire` variable was set to `true` in one and `false` in the other. This bug was introduced when we changed the boolean constants from `ISC_TRUE` to `true` and `ISC_FALSE` to `false`. In the subscription branch, an `ISC_FALSE` was changed to `true` by mistake.
I'm not certain what the effects of this were, but based on the names, I would guess that cache nodes were probably forced to expire in some cases when they shouldn't have been, perhaps leading to more recursion than would otherwise have been necessary.
It's disappointing that no unit or system test noticed the change, and we should consider writing one that would.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1039Tag based policy controls2019-05-17T12:56:21ZRay BellisTag based policy controlsWe need a syntax and mechanism to apply policy controls (e.g. per #825 and #826) based on EDNS Client Tag (see #960)We need a syntax and mechanism to apply policy controls (e.g. per #825 and #826) based on EDNS Client Tag (see #960)https://gitlab.isc.org/isc-projects/bind9/-/issues/1025rpz_rewrite_name: mismatched summary data2021-10-04T19:16:44ZHåvard Eidnesrpz_rewrite_name: mismatched summary data### Summary
If you run BIND with rpz configured and configured with `--enable-querytrace`,
a message with the text `rpz_reqrite_name: mismatched summary data` is logged
per query processed.
### BIND version used
```
BIND 9.14.1 (Stabl...### Summary
If you run BIND with rpz configured and configured with `--enable-querytrace`,
a message with the text `rpz_reqrite_name: mismatched summary data` is logged
per query processed.
### BIND version used
```
BIND 9.14.1 (Stable Release) <id:d4c1008>
running on NetBSD amd64 8.0_STABLE NetBSD 8.0_STABLE (GENERIC) #0: Sun Aug 5 00:07:14 CEST 2018 he@smistad.uninett.no:/usr/obj/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--with-libtool'
compiled by GCC 5.5.0
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with zlib version: 1.2.10
linked to zlib version: 1.2.10
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Configure BIND for RPZ processing.
Misconfigure BIND with `--enable-querytrace` (it's not on in the above, I know...)
Watch the log fill with the above messages.
### What is the current *bug* behavior?
It looks like BIND is doing a lookup in an RB-tree to find the queried-for name
while doing RPZ processing. I think this is an attempt at optimization. However,
`dns_rpz_find_name()` always gets back a `DNS_R_PARTIALMATCH` result from the RB-tree
lookup, causing lookups to fall back (?) to `rpz_find_p()`, and most of the time getting
`NXDOMAIN`.
### What is the expected *correct* behavior?
If the RB-tree lookup is supposed to be an optimization, I would expect it not
to almost always return `DNS_R_PARTIALMATCH`.
### Relevant configuration files
[named.conf](/uploads/70e755c0b7f8adb090df79bdcf5cd9af/named.conf)
### Relevant logs and/or screenshots
(Suggestions welcome.)
### Possible fixes
(Sorry, no suggestion.)https://gitlab.isc.org/isc-projects/bind9/-/issues/977Generate dlz_minimal.h from lib/dns/include/dns/clientinfo.h and others2023-11-02T16:42:09ZOndřej SurýGenerate dlz_minimal.h from lib/dns/include/dns/clientinfo.h and othersWhen keeping stuff in sync, it's very prone to break at some point in future. Instead of adding test that compares the data structures from dlz_minimal.h to their BIND library counterparts, we should rather generate dlz_minimal.h at the...When keeping stuff in sync, it's very prone to break at some point in future. Instead of adding test that compares the data structures from dlz_minimal.h to their BIND library counterparts, we should rather generate dlz_minimal.h at the build time from the pieces that needs to be included.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/957Information on upgrading in release notes2022-03-01T09:48:04ZVicky Riskvicky@isc.orgInformation on upgrading in release notesThis is a proposed process change that I hope we can discuss at all-hands.
* I know there is a file that lists all the options the BIND parser knows.
* I expect/hope there is a file that lists all the supported build options.
I know a f...This is a proposed process change that I hope we can discuss at all-hands.
* I know there is a file that lists all the options the BIND parser knows.
* I expect/hope there is a file that lists all the supported build options.
I know a few of our users do try to compare the options from the release they are running to the release they are upgrading to - but imho most of them don't and they all need to know what these differences are.
Can we do a diff on these from one major version to the next, and then get someone to explain in English to users, in a paragraph in the release notes, what are the impacts on upgrading to the release? (at least additions and deletions - I realize changes in behavior are harder)
I realize we try to address these in the release notes today, and we usually do a good job, but without a process step that compares with the options supported in the prior branch, it is always possible we will miss some.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/953Problems signing a zone that already contains an NSEC3PARAM2024-02-14T14:39:55ZSara DickisnonProblems signing a zone that already contains an NSEC3PARAM### Summary
While testing zone signing using NSEC3, we used a method slightly different to that documented in the ARM - we added an NSEC3PARAM directly into an unsigned zone and got BIND to load it (with 'dnssec-auto maintain;' specifie...### Summary
While testing zone signing using NSEC3, we used a method slightly different to that documented in the ARM - we added an NSEC3PARAM directly into an unsigned zone and got BIND to load it (with 'dnssec-auto maintain;' specified in the config). BIND signed the zone, did not report an error but in some (not all) cases the resulting zone had invalid NSEC3 records.
We wanted to use the different method as it was simpler for our setup... we have subsequently used the documented method with no issues.
### BIND version used
Reproduced with several versions from 9.11.2 to 9.13.7
### Steps to reproduce
Zone file and named.conf attached
0) Create signing keys in the specified directory (/usr/local/bind/etc/dnssec_keys)
1) Use attached (trivial) zone file and named.conf and start BIND.
2) Inspect the logs - no errors shown
3) rndc sync -clean example.com
4) stop BIND
5) dnssec-verify -o example.com zones/example.com
6) result of 5) is:
dnssec-verify -o example.com etc/zones/example.com
Loading zone 'example.com' from file 'etc/zones/example.com'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
No correct ECDSAP256SHA256 signature for 55165Q1V1UD5N19L8DF1LLRNKNJMTIS6.example.com NSEC3
The zone is not fully signed for the following algorithms: ECDSAP256SHA256.
dnssec-verify: fatal: DNSSEC completeness test failed.
Multiple other tests on the zone showed the same issue. Reproduced with other signing algorithms.
### What is the current *bug* behavior?
If this method is supported, then NSEC3 records are invalid
### What is the expected *correct* behavior?
If the method isn't supported then suggest to refuse to load the zone reporting the reason to the user.
### Relevant configuration files
Files attached:
[named.conf](/uploads/f9c2739e35dbe02c0a4daed637e3034e/named.conf)
[example.com](/uploads/5e8dfd80fd546906fd95cb772dd4ce05/example.com)
[example.com.signed](/uploads/35c648d3cdd85fe0af426647b07d21c8/example.com.signed)
### Relevant logs and/or screenshots
Part of BIND log:
```
21-Mar-2019 15:01:40.201 managed-keys-zone: loaded serial 0
21-Mar-2019 15:01:40.201 zone example.com/IN: loaded serial 2007120712
21-Mar-2019 15:01:40.201 all zones loaded
21-Mar-2019 15:01:40.201 running
21-Mar-2019 15:01:40.201 zone example.com/IN: reconfiguring zone keys
21-Mar-2019 15:01:40.204 zone example.com/IN: next key event: 21-Mar-2019 16:01:40.201
21-Mar-2019 15:01:50.393 received control channel command 'sync -clear example.com'
21-Mar-2019 15:01:50.394 sync: dumping zone 'example.com/IN', removing journal file: success
```
### Possible fixesMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/933Reduce the tcp-initial-timeout default2021-10-14T16:04:54ZStephen MorrisReduce the tcp-initial-timeout defaultThis is currently set to 30 seconds. Discussions in the BIND team meeting on 12 March 2019 tended towards a consensus that this was too high and should be reduced.
ARM description:
``tcp-initial-timeout``
This sets the amount of time...This is currently set to 30 seconds. Discussions in the BIND team meeting on 12 March 2019 tended towards a consensus that this was too high and should be reduced.
ARM description:
``tcp-initial-timeout``
This sets the amount of time (in units of 100 milliseconds) that the server waits on a new TCP connection for the first message from the client. The default is 300 (30 seconds), the minimum is 25 (2.5 seconds), and the maximum is 1200 (two minutes). Values above the maximum or below the minimum are adjusted with a logged warning. (Note: this value must be greater than the expected round-trip delay time; otherwise, no client will ever have enough time to submit a message.) This value can be updated at runtime by using rndc tcp-timeouts.https://gitlab.isc.org/isc-projects/bind9/-/issues/928DNSSEC utilities truncate existing files when saving keys2023-11-02T16:42:09ZMichał KępieńDNSSEC utilities truncate existing files when saving keys[`dst_key_tofile()`][1] and [`dst__privstruct_writefile()`][2] open their destination files using `fopen()` with mode `w`, which causes the opened file to be truncated. These functions are used by certain DNSSEC utilities which work on ...[`dst_key_tofile()`][1] and [`dst__privstruct_writefile()`][2] open their destination files using `fopen()` with mode `w`, which causes the opened file to be truncated. These functions are used by certain DNSSEC utilities which work on existing files, e.g. `dnssec-settime`. If such a utility is used to modify a key file just as named tries to read it, the latter may consider the file to be empty and abort or postpone the operation in progress.
While the time window within which this issue can be triggered is pretty narrow, it already happened in practice - in https://gitlab.isc.org/isc-projects/bind9/-/jobs/189696, during the `autosign` test:
1. The `delzsk.example` zone is switched to NSEC3:
```
06-Mar-2019 14:27:20.682 received control channel command 'signing -nsec3param 1 1 10 12345678 delzsk.example.'
```
2. `zone_nsec3chain()` starts creating the NSEC3 chain and finally adds the NSEC3PARAM record at zone apex:
```
06-Mar-2019 14:27:20.695 add delzsk.example. 0 IN NSEC3PARAM 1 0 10 12345678
```
3. The test checks whether the NSEC3PARAM is present before moving on:
```
06-Mar-2019 14:27:20.720 client @0x7f6768039350 10.53.0.1#34567 (delzsk.example): query 'delzsk.example/NSEC3PARAM/IN' approved
```
4. Right after this happens, `dnssec-settime` is called to set the deletion date for the inactive ZSK. This happens to coincide with the final `zone_nsec3chain()` call:
```
06-Mar-2019 14:27:20.735 zone_nsec3chain: zone delzsk.example/IN: enter
06-Mar-2019 14:27:20.736 dns_dnssec_findzonekeys2: error reading Kdelzsk.example.+007+19943.private: end of file
06-Mar-2019 14:27:20.736 zone delzsk.example/IN: zone_nsec3chain:dns__zone_findkeys -> end of file
06-Mar-2019 14:27:20.736 zone delzsk.example/IN: zone_nsec3chain: end of file
```
This temporarily prevents the private record indicating that the NSEC3 chain is being created from being removed from the zone apex, triggering a false positive for the above check due to an extra line being present in the `rndc signing -list` output inspected after running `rndc loadkeys`.
The way I see it, there are two separate issues to address here:
1. **DNSSEC utilities should never cause key files to become truncated.** I think this problem should be addressed by writing the key to a temporary file first and then moving it into the existing key file's place. However, that would be a functional change which I believe could not be backported because it would break e.g. `dnssec-settime` for users storing key files in non-writable directories.
2. **The aforementioned check in the `autosign` system test should be tweaked to prevent false positives from occurring.** This change should be backported to all maintained branches.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/f285dd9a0828ba472645e61e5e9608c852aa31b6/lib/dns/dst_api.c#L1582
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/f285dd9a0828ba472645e61e5e9608c852aa31b6/lib/dns/dst_parse.c#L642Not planned