BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-01T14:43:41Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4330Add support to parse and display DSO (opcode 6) messages2023-11-01T14:43:41ZMark AndrewsAdd support to parse and display DSO (opcode 6) messagesSee [RFC 8490](https://www.rfc-editor.org/rfc/rfc8490.txt). These contain 1 or more TLVs immediately after the DNS messages header.
Add support to dig to be able to send arbitrary DSO messages.See [RFC 8490](https://www.rfc-editor.org/rfc/rfc8490.txt). These contain 1 or more TLVs immediately after the DNS messages header.
Add support to dig to be able to send arbitrary DSO messages.Long-termMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3228Reduce and then remove task exclusive mode2023-11-01T07:55:11ZOndřej SurýReduce and then remove task exclusive modeThis is (umbrella) issue to track the removal of task exclusive mode which (with proper design) should not be necessary. The exclusive mode is used in:
* [ ] named itself when:
* [ ] [(re-)loading configuration](issue TBD)
* [ ] [lo...This is (umbrella) issue to track the removal of task exclusive mode which (with proper design) should not be necessary. The exclusive mode is used in:
* [ ] named itself when:
* [ ] [(re-)loading configuration](issue TBD)
* [ ] [loading zones](issue TBD)
* [ ] [shutting down](issue TBD)
* [ ] [enabling/disabling DNSSEC validation](issue TBD) via rndc
* [ ] [flushing cache](issue TBD)
* [x] [deleting TSIG?](issue TBD)
* [ ] [dumping changes to dynamic zones](issue TBD) via rndc
* [ ] [freezing/thawing zone](issue TBD)
* [ ] [something with adding/removing zones](issue TBD) via rndc
* [ ] [destroying managed-keys database](issue TBD)
* [ ] [setting TCP timeouts](issue TBD) #WTF?
* [ ] [configuring serve-stale](issue TBD) via rndc
* [x] [dns_adb](issue TBD)
* [ ] [dns_catz](issue TBD) via `catz_addmodzone_taskaction()`, `catz_delzone_taskaction()`
* [ ] [dns_dt](issue TBD)
* [x] [ns_clientmgr](https://gitlab.isc.org/isc-projects/bind9/-/issues/3230)
* [x] [ns_interfacemgr](https://gitlab.isc.org/isc-projects/bind9/-/issues/3229)Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2549Create a BIND benchmarking package for users to download and use in their own...2022-06-03T10:15:14ZCathy AlmondCreate a BIND benchmarking package for users to download and use in their own environmentsThis feature issue ticket is to track discussions on a potential downloadable benchmark testing framework for users (performance testing is hard...)This feature issue ticket is to track discussions on a potential downloadable benchmark testing framework for users (performance testing is hard...)Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2548Resolver testing - building an Internet Simulator device2022-06-03T10:15:14ZCathy AlmondResolver testing - building an Internet Simulator deviceThis ticket is being opened to capture discussions on how to create a device to take the place of 'The Internet' for benchmarking resolver performance more realisticallyThis ticket is being opened to capture discussions on how to create a device to take the place of 'The Internet' for benchmarking resolver performance more realisticallyLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2547Resolver benchmarking testing - corralling the generic plus the important edg...2022-06-03T10:15:14ZCathy AlmondResolver benchmarking testing - corralling the generic plus the important edge cases to include when testingOpening this issue to capture discussions on what we need to include in BIND resolver performance benchmark tests, beyond the generic case.Opening this issue to capture discussions on what we need to include in BIND resolver performance benchmark tests, beyond the generic case.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2999remove duplicate code between DLZ example & dlzexternal test2022-01-07T09:40:28ZPetr Špačekpspacek@isc.orgremove duplicate code between DLZ example & dlzexternal testVersion: main branch, 4bebcd45033400a6b1a3057c60c3a2cfd5fd4029
These two files are substantially the same:
- contrib/dlz/example/dlz_example.c
- bin/tests/system/dlzexternal/driver/driver.c
I think we should remove one of them and use ...Version: main branch, 4bebcd45033400a6b1a3057c60c3a2cfd5fd4029
These two files are substantially the same:
- contrib/dlz/example/dlz_example.c
- bin/tests/system/dlzexternal/driver/driver.c
I think we should remove one of them and use symlink instead of copy. Updating two files is ... suboptimal.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1573Rewrite qmin ans.py services2021-10-05T07:43:44ZWitold KrecickiRewrite qmin ans.py servicesLong-termWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4544"primaries" block documentation issues2024-01-23T15:27:16ZRay Bellis"primaries" block documentation issuesI'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years ...I'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years within the `also-notify` section of primary zones.
There's no direct mention of `primaries` in the grammar of an `also-notify` block. I _suspect_ that it's covered by `<remote-servers>` but the only link between `primaries` and `remote-servers` is this text in the glossary:
> remote-servers: A named list of one or more ip_addresses with optional tls_id, server_key, and/or port. A remote-servers list may include other remote-servers lists. See primaries block.
If in fact a `<remote-servers>` reference _is_ a (named) `primaries` list, then that ought to be spelled out more explicitly, and the documentation updated to reflect that this can be used in *any* `allow-notify` block in any applicable zone type.
I'd also suggest that the top level grammar ought to actually be called `xfer-servers` instead of `masters` and then that term used in place of `remote-servers` in the ARM. In the NOTIFY case the listed servers are secondaries, not primaries, and it makes no sense to call them primaries.
[`remote-servers` also causes confusion with `server <prefix> { }` used to specify per-server EDNS overrides, etc]Long-termMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4542XoT: Primaries should be able to have different allow-transfer acls per trans...2024-01-22T13:10:56ZDave KnightXoT: Primaries should be able to have different allow-transfer acls per transport or ACLs should be extended with port and transport options### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per tr...### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per transport.
I want to require XoT for transfers over the Internet, but allow insecure AXFR to localnets.
It's not possible to have multiple allow-transfer definitions, i.e. this
allow-transfer port 53 transport tcp { acl_for_nonxot_clients; };
allow-transfer port 853 transport tls { acl_for_xot_clients; };
results in
'allow-transfer' redefined near 'allow-transfer'
And my understanding is that we can't refer to ports or transport in an acl.
### Request
Either allow multiple allow-transfer clauses, treating "allow transfer transport tcp" and "allow transfer transport tls" as different things, which can have their own acl specification, or add port and transport to the acl so that this can be controlled there.
### Links / referencesLong-termArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4505Implement kTLS support in BIND2024-02-14T17:13:53ZArtem BoldarievImplement kTLS support in BIND
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user sp...
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user space, including offloading TLS encryption to the NICs that support that (e.g. [NVIDIA Mellanox ConnectX-6 Dx](https://www.nvidia.com/en-us/networking/ethernet/connectx-6-dx/)), almost completely freeing the CPU from this task, because even in the case of hardware acceleration of encryption within the CPU, it still requires some cycles from it. Also, using it might reduce memory copying in some cases.
Of course, kernel space encryption is more limited compared to the one provided by OpenSSL and its derivatives in the user space: these limitations are imposed by hardware - e.g. NICs might not support anything but AES 128 (aka `TLS_AES_128_GCM_SHA256`), as it is the only cipher mandatory for TLS v1.3). If it is good enough for WEB servers, it should be good enough for DNS, too.
Even when kTLS is used, the handshake itself happens in the user space (e.g. using OpenSSL) with negotiated parameters passed to the kernel using `setsockopt()` calls on a TCP socket descriptor.
OpenSSL provides support for kTLS encryption natively since version 3.X (see `SSL_OP_ENABLE_KTLS` [option](https://www.openssl.org/docs/manmaster/man3/SSL_set_options.html)) but, as far as I understand it, it does so only when OpenSSL manages the underlying TCP socket file descriptor natively: not our case, as we are using LibUV for that. However, considering that the idea of kTLS is that with it enabled, we are supposed to pass unencrypted data to `send()` and `recv()`, that is kTLS-enabled socket from the higher level perspective works (mostly) as a TCP socket, we might try the following approach to implement kTLS, that *might* work:
1. We use our existing code (`tlsstream.c`) to handle handshake, just like we do now;
2. After completing the handshake, we pass the negotiated information to the kernel. OpenSSL might have some interfaces for that. In the worst case, we might need to do that by hand using. `setsockopt()`;
3. Then, we add new code paths to `tlsstream.c` to bypass TLS connection objects (`isc_tls_t`) and use the underlying TCP connection directly, which, by now, works in "kTLS-mode", providing transparent TLS encryption;
4. Control messages, like TLS shutdown, will require additional care.
That is how I see the initial plan that might or might not work. There can (and, likely, will) be unforeseen obstacles that might turn out to overcomplicate the code base so much that it might make it unfeasible to implement, like adding a kTLS-only transport. Furthermore, that might require some assistance from LibUV. That will require some trial and error.
That is mostly written with Linux in mind. If the kTLS interface in FreeBSD is similar enough (it seems so at the first glance), we should support both platforms.
The issue is created mostly to dump the information from my mind and keep kTLS under our radar: we might want to do that, as at least `dnsdist` has experimental support for it. It will be even more important in the future, as it seems now that encrypted DNS transport will be even more important to the point of replacing the good ol' Do53 at some point.
For sure, it is not a 9.20 material - rather 9.21-9.22 if we are lucky, as it is a big feature. Also, I foresee a similar concept eventually appearing for QUIC, too (kQUIC?). Also, I am aquiet certain that we *will* need #3504 for this (implemented here: !8576).
See also:
1. https://docs.kernel.org/networking/tls.html
2. https://man.freebsd.org/cgi/man.cgi?query=ktls&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html
3. https://delthas.fr/blog/2023/kernel-tls/ - mostly discusses it in the context of HTTP and `sendfile()` acceleration, but contains many references on the topic.
4. https://docs.nvidia.com/networking/display/ofedv512580/kernel+transport+layer+security+(ktls)+offloadsLong-termArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4503Possible pytest RNDC interface improvements2023-12-21T18:03:30ZŠtěpán BalážikPossible pytest RNDC interface improvementsReview of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
...Review of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
- [ ] Find a way to the the `*.in` files templating in pure Python. This is needed for the elimination of the `setup.sh` scripts. This will probably require depending on `jinja` explicitly.
- [ ] Add an "rndc null" before every reconfiguration to show which file is used (NamedInstance.add_mark_to_log() as it may be generically useful?)
- [ ] Extend `NamedInstance` with some kind of `query` method. This is needed as a replacement for the calls to `dig` which are common in system tests.
- [ ] There are now two objects representing the ports used in tests: dictionary returned by the `ports` fixture and the new `NamedPorts` class. Unify them. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411674).
- [ ] Consider switch from `NamedTuple` to `dataclass` (Python 3.7 feature, requires a external dependency on some distros we run) as discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411004).
- [ ] `NamedInstance.rndc(…)` method probably ought to be `async`. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411007)
Feel free to add others!Long-termŠtěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4297Follow-up from "Resolve "UAF in validator logging""2023-09-06T01:05:12ZMark AndrewsFollow-up from "Resolve "UAF in validator logging""The following discussion from !8269 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8269#note_399683): (+2 comments)
> Wouldn't it be better if `val->name` would...The following discussion from !8269 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8269#note_399683): (+2 comments)
> Wouldn't it be better if `val->name` would be attached to the `dns_name_t` instead of just assigned to prevent this reordering issues? What would be the performance impact of such change?Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4268There is a performance waste in the rpz check2023-08-22T07:06:22ZMr BenThere is a performance waste in the rpz check
### Summary
This is not a strict bug, it should belong to performance optimization.
When using rpz, if a domain name contains a cname domain name, the domain name will go through multiple rpz checks.
### BIND version used
```
BIND 9....
### Summary
This is not a strict bug, it should belong to performance optimization.
When using rpz, if a domain name contains a cname domain name, the domain name will go through multiple rpz checks.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:5218cdf>
running on Linux x86_64 3.10.0-1160.45.1.el7.x86_64 #1 SMP Wed Oct 13 17:20:51 UTC 2021
built by make with '--enable-dnstap' '--enable-epoll' '--with-dlz-filesystem' '--with-libjson' '--with-libtool' '--enable-dnsdrps' '--prefix=/data/named/' 'CFLAGS= -O0 -g -DDEBUG' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.1.1p 21 Jun 2022
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
threads support is enabled
default paths:
named configuration: /data/named/etc/named.conf
rndc configuration: /data/named/etc/rndc.conf
DNSSEC root key: /data/named/etc/bind.keys
nsupdate session key: /data/named/var/run/named/session.key
named PID file: /data/named/var/run/named/named.pid
named lock file: /data/named/var/run/named/named.lock
```
### Steps to reproduce
```
options {
response-policy {
zone "in-addr.arpa.";
};
};
zone "in-addr.arpa." {
type primary;
file "badlist.zone";
allow-query {none;};
};
```
### What is the current *bug* behavior?
It is not reflected in the function, but it is reflected in the code logic.
```
eg:
dig @127.0.0.1 www.microsoft.com
;; ANSWER SECTION:
www.microsoft.com. 1496 IN CNAME www.microsoft.com-c-3.edgekey.net.
www.microsoft.com-c-3.edgekey.net. 247 IN CNAME www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. 203 IN CNAME e13678.ca2.s.tl88.net.
e13678.ca2.s.tl88.net. 158 IN A 218.58.101.49
```
The rpz module checks the following domain names twice, which is a huge waste of performance:
www.microsoft.com, www.microsoft.com-c-3.edgekey.net, www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
### What is the expected *correct* behavior?
Each domain name is checked only once。
### Relevant configuration files
```
Configure the rpz module normally:
options {
response-policy {
zone "in-addr.arpa.";
};
};
zone "in-addr.arpa." {
type primary;
file "badlist.zone";
allow-query {none;};
};
and the file of badlist.zone is:
$TTL 1H
@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
NS LOCALHOST.
nxdomain.domain.com CNAME . ; NXDOMAIN policy
```
### Relevant logs and/or screenshots
none.
### Possible fixes
The call of the rpz module should be migrated from query_gotanswer to before query_gotanswer:
```
if (!RECURSING(qctx->client) &&
!dns_name_equal(qctx->client->query.qname, dns_rootname))
{
result = query_checkrpz(qctx, result);
if (result == ISC_R_COMPLETE) {
return (ns_query_done(qctx));
}
}
```
After the query resume function is triggered, it will execute to ns_query_start. It is not necessary to call rpz in query_gotanswer after query_resume, but call rpz in ns_query_start, which reduces the number of rpz calls.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4164Investigate performance impact of UDP_GRO2023-06-27T07:06:24ZPetr Špačekpspacek@isc.orgInvestigate performance impact of UDP_GRO### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple dat...### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple datagrams worth of data as a single large buffer, together with a cmsg(3) that holds the segment size. This option is the inverse of segmentation offload. It reduces receive cost by handling multiple datagrams worth of data as a single large packet in the kernel receive path, even when that exceeds MTU. This option should not be used in code intended to be portable.
More reading:
https://developers.redhat.com/articles/2021/11/05/improve-udp-performance-rhel-85
### Request
- Investigate if UDP receipt is even a bottleneck.
- Investigate if UDP_GRO makes a difference and is worth messing with (I supposed in libuv).
### Links / referencesLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4162SHA-1 removal2023-06-27T07:27:14ZPetr Špačekpspacek@isc.orgSHA-1 removal### Description
From [NIST announcement](https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps):
> As a result, NIST will transition away from the use of SHA-1 for applying cryptographic protection to **all app...### Description
From [NIST announcement](https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps):
> As a result, NIST will transition away from the use of SHA-1 for applying cryptographic protection to **all applications** by December 31, 2030
### Request
Don't get caught asleep at the wheel.
### Links / references
Send questions about the transition in an email to sha-1-transition@nist.gov. Visit the [Policy on Hash Functions](https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions) page to learn more.Long-term2030-12-31https://gitlab.isc.org/isc-projects/bind9/-/issues/4161Support quantum safe DNSSEC algorithms2023-06-27T07:27:28ZPetr Špačekpspacek@isc.orgSupport quantum safe DNSSEC algorithms### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early exp...### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early experimentation.
Many algorithms are already available as OpenSSL provider here: https://github.com/open-quantum-safe/oqs-provider
### Additional details
* [FALCON implementation in PowerDNS](https://indico.dns-oarc.net/event/42/contributions/902/attachments/871/1601/Post-Quantum%20DNSSEC%20with%20FALCON-512%20and%20PowerDNS(2).pdf)
* [Verisign's presentation](https://indico.dns-oarc.net/event/46/contributions/985/attachments/938/1728/OARC40-ResearchAgendaForAPQCDNSSEC-Final.pdf)
Word of mouth from Red Hat crypto people I talked to:
Right now it seems that NIST might standardize 5 algorithms, with several variants for each algorithm with intent to provide 128/256 bit-equivalent of security.
Rambling about candidate algorithms for DNSSEC:
- HSS/LMS & XMSS^MT algorithms are extremely susceptible to key reuse. One key reuse ruins the whole thing. Don't use it.
- Falcon-512 has smallest signatures by large margin (around 666 bytes). CRYSTALS-Dillithium are built on the same principle but have larger signatures (about 2420 bytes). The problem is, both are reportedly built on shaky grounds because we as humankind don't fully understand the math behind them, so chances for breaking these algorithms in couple years are non-negligible.
- The remaining candidate algorithm is SPHINCS+-128. That one is most solid because it's based on ordinary hashes, which are well understood. The catch is that one signature is about 7856 bytes :exploding_head:
Consequently, this sounds like we need very good very solid TCP/TLS/QUIC support in client and server, so we are not limited to UDP packet sizes. That's IMHO the only way to go without significantly changing the protocol.
(Or we can go and engineer DNS 2.0 :grinning:)
### Links / referencesLong-term2026-01-01https://gitlab.isc.org/isc-projects/bind9/-/issues/4158investigate performance impact of huge pages2023-06-27T07:27:35ZPetr Špačekpspacek@isc.orginvestigate performance impact of huge pages- We do lots and lots of allocation.
- jemalloc supports huge pages to limit metadata overhead and TLB misses
- that together with tuning sysctl `vm.nr_hugepages` can be interesting.
Reading:
https://access.redhat.com/documentation/en-u...- We do lots and lots of allocation.
- jemalloc supports huge pages to limit metadata overhead and TLB misses
- that together with tuning sysctl `vm.nr_hugepages` can be interesting.
Reading:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/configuring-huge-pages_monitoring-and-managing-system-status-and-performanceLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2800Docker image for AArch64 - Raspberry Pi2022-02-01T11:18:07ZVicky Riskvicky@isc.orgDocker image for AArch64 - Raspberry PiI received a request via email for a Docker image that will run on a stack of Raspberry Pi 4Bs. I have only ever seen the one request, so I will put it here and see if it gets a lot of upvotes...
"ISC's official Docker image is not supp...I received a request via email for a Docker image that will run on a stack of Raspberry Pi 4Bs. I have only ever seen the one request, so I will put it here and see if it gets a lot of upvotes...
"ISC's official Docker image is not supported for the AArch64 architecture."Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/822Follow-up from "GitLab CI cleanup"2019-02-05T20:13:15ZOndřej SurýFollow-up from "GitLab CI cleanup"The following discussion from !1329 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1329#note_38876): (+3 comments)
> Without rebasing, I renamed CI jobs as agreed...The following discussion from !1329 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1329#note_38876): (+3 comments)
> Without rebasing, I renamed CI jobs as agreed upon earlier; the diff from the previous version of the branch looks fairly legible to me.
>
> @ondrej, I think this achieves what you asked for, but please take a look at https://gitlab.isc.org/isc-projects/bind9/pipelines/8771 to confirm that.
>
> While examining job output for the pipeline linked to above, I noticed an issue which was not introduced by this branch: the job testing `make install` does not just install stuff, but rather does an almost complete rebuild first. This is caused by how artifacts are passed between jobs: when a runner for the "install" job clones the tested revision and subsequently extracts the artifacts that the "build" job produced, modification times for the versioned source files inside the working copy turn out to be more recent than the timestamps of the object files extracted from the artifacts archive. This causes `make` to believe that it needs to rebuild stuff.
>
> I see no elegant way to solve this, because:
>
> * Updating the timestamps for all files and directories in the working copy for the "install job" to the same value (e.g. using `find . | xargs touch`) does us no good as that would also cause rebuilds (since dependencies are built in a specific order and this order has to be reflected in timestamps in order for a rebuild to be prevented).
>
> * We could store the modification time for each file created by the "build" job in a separate file and then, in the "install" job, update the timestamp for each file extracted from the artifacts archive to the stored timestamp + some constant delta, but that would trigger a lot of *"Warning: File 'Makefile' has modification time XXXX s in the future"* messages in the job output (though I believe it would achieve the desired effect).
>
> * The above warnings cannot be fully prevented from appearing even if we calculated the timestamp delta dynamically in the "install" job (e.g. "move timestamps for all extracted files by the difference between current time and the lowest timestamp found amongst all the extracted files") as the "install" job runs quicker than the "build" job.
>
> I believe our options here are:
>
> * Ignore this and just let the "install" job rebuild stuff.
>
> * Choose the second approach listed above, ignoring the warnings about timestamps set in the future.
>
> * Run `make install` in the "build" job (theoretically, this might delay the start of the entire "Test" phase of the pipeline, but I do not think it would be noticeable, given the statistical differences in run time between various jobs in the "Build" phase).
>
> @ondrej, thoughts, any other ideas for addressing this?Long-termMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/737Uniquely number and document emitted log messages2018-11-23T15:24:27ZOndřej SurýUniquely number and document emitted log messagesCathy Almond @cathya wrote:
> Can we, off the back of this, take a look at the Kea model for uniquely numbering and documenting emitted logged messages and open a feature request for doing something similar in BIND?
Brian Conry wrote:
>...Cathy Almond @cathya wrote:
> Can we, off the back of this, take a look at the Kea model for uniquely numbering and documenting emitted logged messages and open a feature request for doing something similar in BIND?
Brian Conry wrote:
> I've had it on my personal wish-todo-list to figure out how to generate the catalog files as part of a make operation, ever since I had to troubleshoot a problem with the text start typing instead of out of memory because the OS vendor had pre-installed catalog files that that matched their build of BIND.
>
> But eliminating the (almost completely) unused catalog functionality would work too.
>
> Actually, doing the "unique numbering" thing seems to me like it would be a helpful step if we were to try to preserve support for catalog files, so it seems to me to be something that we should do regardless.Long-term