ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-12-09T15:46:05Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2128Handle the GSS-TSIG key name uniqueness2021-12-09T15:46:05ZFrancis DupontHandle the GSS-TSIG key name uniquenessQuoting RFC 2930:
> At any DNS server or resolver only one octet string of keying
material may be in place for any particular key name. An attempt to
establish another set of keying material at a server for an existing
name ...Quoting RFC 2930:
> At any DNS server or resolver only one octet string of keying
material may be in place for any particular key name. An attempt to
establish another set of keying material at a server for an existing
name returns a BADNAME error.
We should be prepare to handle this case. Note I do not propose to add code because it is very unlikely (random part on 32 bits and name lookup before creating a new key) but to add an unit test so the condition can be recognized.kea2.1.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2170fix the TKeyExchange cleanup2021-12-09T15:46:05ZRazvan Becheriufix the TKeyExchange cleanupcalling ~TKeyExchange() -> ~TKeyExchangeImpl() -> TKeyExchangeImpl::cancel() -> io_fetch_->stop() -> TKeyExchangeImpl::operator() -> TKeyExchangeImpl::callCallback() -> ManagedKey::operator() -> getTKeyExchange().reset() -> ~TKeyExchange...calling ~TKeyExchange() -> ~TKeyExchangeImpl() -> TKeyExchangeImpl::cancel() -> io_fetch_->stop() -> TKeyExchangeImpl::operator() -> TKeyExchangeImpl::callCallback() -> ManagedKey::operator() -> getTKeyExchange().reset() -> ~TKeyExchange()
caused by:
```
void
ManagedKey::operator()(TKeyExchange::Status tkey_status) {
...
getTKeyExchange().reset();
}
```kea2.1.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2127Add a GSS-TSIG command to rekey a DNS server2021-12-09T15:46:05ZFrancis DupontAdd a GSS-TSIG command to rekey a DNS serverkea2.1.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2121More GSS-TSIG DNS update checks and TKEY exchange checks2021-12-09T15:46:05ZFrancis DupontMore GSS-TSIG DNS update checks and TKEY exchange checksNew TKEY exchange unit tests of #2092 show that the TKEY exchange code should protect before calling the GSS-API library against two misuses:
- [x] use twice the same key (proposal: check the GSS-API context)
- [x] call doExchange twic...New TKEY exchange unit tests of #2092 show that the TKEY exchange code should protect before calling the GSS-API library against two misuses:
- [x] use twice the same key (proposal: check the GSS-API context)
- [x] call doExchange twice (proposal: introduce an initial state)
The GSS-TSIG configured server should fallback to non secure DNS update if the TKEY is not available (missing UT):
- [x] checking fallback (if no GSS-TKEY is available, the DNS update should fall through with no security)kea2.1.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2174configurable TKEY-exchange timeout2021-12-09T15:46:05ZRazvan Becheriuconfigurable TKEY-exchange timeoutConfigure IOFetch timeoutConfigure IOFetch timeoutkea2.1.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2138configurable renew timer and retry timer intervals used for key renewal2021-12-09T15:46:05ZRazvan Becheriuconfigurable renew timer and retry timer intervals used for key renewalloop parameter (including minimal lifetime)
- retry if there's an error or timeout
- check the next key renew will happen before TKEY expire, otherwise renew TKEY now
created on top of #2121 and #2127loop parameter (including minimal lifetime)
- retry if there's an error or timeout
- check the next key renew will happen before TKEY expire, otherwise renew TKEY now
created on top of #2121 and #2127kea2.1.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2177remove very old GSS-TSIG keys2021-12-09T15:46:05ZFrancis Dupontremove very old GSS-TSIG keysCurrent proposal is to remove keys which expired more than 2 maximum lifetimes.Current proposal is to remove keys which expired more than 2 maximum lifetimes.kea2.1.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2175Fix rekey timer computing2021-12-09T15:46:04ZFrancis DupontFix rekey timer computingrekey timer should use a date based on the newest key (vs just the configured interval).rekey timer should use a date based on the newest key (vs just the configured interval).kea2.1.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2173gss code cleanup2021-12-09T15:46:04ZRazvan Becheriugss code cleanupsome things still need to be addressed:
- [x] 1. rename gss_tsig_keys_mgr.h/.cc to managed_key.h/.cc
- [x] 2. TKeyExchange can store the IOService on constructor instead of the doExchange method
- [x] 3. check the key's security context ...some things still need to be addressed:
- [x] 1. rename gss_tsig_keys_mgr.h/.cc to managed_key.h/.cc
- [x] 2. TKeyExchange can store the IOService on constructor instead of the doExchange method
- [x] 3. check the key's security context on TKeyExchange constructor and throw if it has already been used
- [x] 4. add core documentation for expiration-timeout and a table explaining all parameters
- [x] 5. add core documentation about keys being deleted if more than 3 times maximum lifetimekea2.1.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2122Update d2/d2srv developer doc2021-12-09T15:46:04ZFrancis DupontUpdate d2/d2srv developer docSome code was moved from src/bin/d2 to src/lib/d2srv. This is now finished but the dev doc (src/bin/d2/d2.dox) needs to be update to reflect file moves.
- [x] update d2.dox
- [x] update gss_tsig.doxSome code was moved from src/bin/d2 to src/lib/d2srv. This is now finished but the dev doc (src/bin/d2/d2.dox) needs to be update to reflect file moves.
- [x] update d2.dox
- [x] update gss_tsig.doxkea2.1.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2228backport GSS-TSIG to Kea 2.02021-12-09T15:46:01ZRazvan Becheriubackport GSS-TSIG to Kea 2.0kea2.0.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2231Kea ARM review, continued (stork.rst, security.rst)2021-12-09T15:32:11ZSuzanne GoldlustKea ARM review, continued (stork.rst, security.rst)Continuing review of Kea ARMContinuing review of Kea ARMThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2137configure automatic credential management using sssd2021-12-09T15:18:36ZRazvan Becheriuconfigure automatic credential management using sssdcreate doc how to configure sssd to automatically do kinit similar action for us (potentially useful for MIT, Heimdal provides this out of the box).create doc how to configure sssd to automatically do kinit similar action for us (potentially useful for MIT, Heimdal provides this out of the box).https://gitlab.isc.org/isc-projects/kea/-/issues/2226Kea ARM review, continued (shell, integrations, netconf, gss-tsig)2021-12-09T13:12:08ZSuzanne GoldlustKea ARM review, continued (shell, integrations, netconf, gss-tsig)Continuing update of Kea ARMContinuing update of Kea ARMThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/stork/-/issues/613follow up to 0.22 sanity checks2021-12-09T09:01:37ZAndrei Pavelandrei@isc.orgfollow up to 0.22 sanity checks* [x] A minor issue. The Stork Agent help prints "A new cli application":
```
$ ./stork-agent --help
NAME:
Stork Agent - A new cli application
```
It is no longer a new application. Shouldn't it rather be "Stork Agent - A Stork appl...* [x] A minor issue. The Stork Agent help prints "A new cli application":
```
$ ./stork-agent --help
NAME:
Stork Agent - A new cli application
```
It is no longer a new application. Shouldn't it rather be "Stork Agent - A Stork application monitoring Kea and BIND9 servers".
* [x] We seem to be a bit inconsistent how we define boolean values in the env files. In the agent.env we have:
```
# skip TLS certificate verification when the Stork Agent connects
# to Kea over TLS and Kea uses self-signed certificates
# STORK_AGENT_SKIP_TLS_CERT_VERIFICATION=true
```
In the server.env we have:
```
# Enable Prometheus /metrics HTTP endpoint for exporting metrics from
# the server to Prometheus. It is recommended to secure this endpoint
# (e.g. using HTTP proxy).
# STORK_ENABLE_METRICS=1
```1.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2219Kea ARM review, continued (stats.rst, ctrl-channel.rst, logging.rst)2021-12-08T17:49:53ZSuzanne GoldlustKea ARM review, continued (stats.rst, ctrl-channel.rst, logging.rst)Continuing review of the Kea ARMContinuing review of the Kea ARMThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/stork/-/issues/6441.0 release2021-12-08T11:15:01ZWlodzimierz Wencel1.0 release1.0Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/stork/-/issues/649Doc updates from Sanity checking 1.0 release2021-12-08T11:01:31ZVicky Riskvicky@isc.orgDoc updates from Sanity checking 1.0 releaseI will try to fix the doc issues Marcin identified in the 1.0 sanity checking.
- [ ] In the Stork Tool section of our ARM we have this text: "To initialize the database directly, the Stork Tool must be built and used to initialize and u...I will try to fix the doc issues Marcin identified in the 1.0 sanity checking.
- [ ] In the Stork Tool section of our ARM we have this text: "To initialize the database directly, the Stork Tool must be built and used to initialize and upgrade the database to the latest schema. However, this is optional, as the database migration is triggered automatically upon server startup."
In fact, the `rake install_server` builds and installs the tool. So, there is no optionality.
>> I didn't find this and actually, it seems to me that the explanation implies it is triggered automatically so I don't see the problem...?
- [x] The `stork-agent` man page (perhaps other man pages too), says this:
```
Once Stork becomes more mature, ISC will provide professional support for Stork services.
```
It should be removed.
>> I removed this from several places.
- [ ] Stork Agent has a silly brief description in its help:
```
./stork-agent --help
NAME:
Stork Agent - A new cli application
```
>>> completely agree this should be fixed but I couldn't find where this text is.
- [x] CONTRIBUTING.md: invalid link: https://gitlab.isc.org/isc-projects/stork/forks/new
A new cli application?
- [x] "Submitting MR" section in CONTRIBUTING.md should be updated to remove Godfryd and add Slawek.
- [x] This TODO in CONTRIBUTING.md doesn't make sense: "TODO: Describe how to run unit-tests and system tests for Stork" because the previous section describes how to run the unit tests.
- [x] CONTRIBUTING.md: we should remove Godfryd from here:
"ask someone from the ISC team to give you permission to fork Stork\*\* (ask @tomek, @vicky, @ondrej or @godfryd or basically anyone from the Stork dev team)".
- [x] Another nit in the README.md. I think we should remove this sentence: "Stork is in early stages of its development, but it's getting new features rapidly". It will take some time to get new fancy features but we accomplished a major milestone, so saying it is in early stage is probably a bit confusing.
- [x] A nit in the AUTHORS.md file: the `agent` should be also included on my list of components.Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/3047Change reject-000-label default to false in BIND 9.192021-12-08T07:05:44ZMark AndrewsChange reject-000-label default to false in BIND 9.19As per documented road map for reject-000-label.
- [ ] change default
- [ ] update documentation
- [ ] update synthfromdnssec system test
- [ ] update release notes
- [ ] create future issue to remove reject-000-label (9.21.x)As per documented road map for reject-000-label.
- [ ] change default
- [ ] update documentation
- [ ] update synthfromdnssec system test
- [ ] update release notes
- [ ] create future issue to remove reject-000-label (9.21.x)BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3044'recursing clients' counter in stats is still underflowing on BIND 9.16.23-S12021-12-07T11:47:20ZCathy Almond'recursing clients' counter in stats is still underflowing on BIND 9.16.23-S1As reported in [Support ticket #19917](https://support.isc.org/Ticket/Display.html?id=19917)
For example:
```
4294445023 recursing clients
```
We seem to have addressed some causes of this anomaly in earlier versions of BIND ...As reported in [Support ticket #19917](https://support.isc.org/Ticket/Display.html?id=19917)
For example:
```
4294445023 recursing clients
```
We seem to have addressed some causes of this anomaly in earlier versions of BIND (#1078, #1719), but it is definitely still a problem.
There was one hypothesis that this might be related to DNS64 - however, no sign of DNS64 in this named.conf.
I would like to suggest that it might be due to one (or all) of:
- prefetch (it'd be easy to turn this off to confirm?)
- RPZ (yes, they have all of `nsip-wait-recurse no` and `qname-wait-recurse no` but whether or not additional recursion takes place is determined also by the actual policies in the policy zones themselves)
- Something awry with TCP socket handling?
- Something whacky with the interaction with serve-stale? (Although this is a default config., so `stale-cache-enable yes;`, `stale-answer-enable no;`.
No fetch-limits in this configuration, but if it was purely fetch-limits related, I think we'd have found and fixed it by now.