Petr Špaček [Mon, 16 Apr 2018 16:03:05 +0000 (18:03 +0200)]
prefill: split into separate functions, handle daemon restart
The original prefill module did not import zone data after daemon
restart unless the file TTL was expired. The module now reuses data
on disk as long as TTL is not expired, and imports the zone after module
load.
lib/utils: merge kr_rrkey() and kr_rrkey2() functions
The old kr_rrkey() was used only on one place (and incorrectly) so now
we are replacing both copies with single implementation for general
resolver and root zone import.
It should not make any practical difference.
Marek Vavruša [Sat, 14 Apr 2018 04:18:42 +0000 (21:18 -0700)]
worker: fixed infinite loop on send failure
The problem here is when qr_task_send() returns an error, the
following error handler will attempt to cancel all tasks that were
started on the same connection, but that will only work for the first
task (which is finished), the qr_task_on_send() will have no effect
on tasks in progress as the passed handle is NULL, and the task->finished
is false, thus looping infinitely.
The solution here is to let the rest of the tasks complete, even though
sending answer back will fail (which is fine).
Marek Vavruša [Thu, 5 Apr 2018 03:41:15 +0000 (20:41 -0700)]
fixed validation of root DS
The root DS exists outside of DNS hierarchy, so its NSEC proving non-existence
always contains the SOA, as that's the root of DNS and there's nothing above it.
Marek Vavruša [Sun, 8 Apr 2018 01:37:55 +0000 (18:37 -0700)]
iterate: update zone cut when NS is authoritative for both parent and child
In some cases the NS is authoritative for both parent and the child side of
the delegation (e.g. nrl.navy.mil). When it gets the query for such NS,
it can respond from the child side with an NS record in the answer and AA=1.
The resolver should update the zone cut accordingly, otherwise it would fail
validation in cases when the child-side of the delegation is insecure,
but parent side of the delegation is secure, because the child side
would respond without DNSSEC records, and it wouldn't indicate that
the zone cut needs updating (when using minimal answers) (e.g. www.nrl.navy.mil).
Vladimír Čunát [Tue, 3 Apr 2018 14:15:26 +0000 (16:15 +0200)]
validator: fix CNAME to NXDOMAIN in a single answer
Real example: cname.nohats.ca
This case was handled for forwarding only, presumably because it
happened more often (no need to be withing single zone to be within
single answer); now the approach is the same.
Marek Vavruša [Wed, 28 Mar 2018 05:10:09 +0000 (22:10 -0700)]
cache: fixed crash with RR sets with over 255 records
The previous cache version encoded RR count as uint8_t, which doesn't
work with RR sets with over 255 records. This caused cache writes
to fail and subsequently ending in an assertion failure.
It is not very common to have large RR sets, but it has legitimate
use cases such as a lot of SRV or address records for large container
deployments etc.
Marek Vavruša [Tue, 20 Mar 2018 22:41:05 +0000 (15:41 -0700)]
daemon/worker: allow large responses for outbound over TCP
This was previously fixed in e25358d4f6521a55c33ec1d3a55f2bf6e2f99607,
but broken in the rewrite. The answer buffer size must be a maximum size,
otherwise payloads larger than configured UDP buffer size can't be
transmitted over TCP.
Marek Vavruša [Fri, 23 Mar 2018 21:32:08 +0000 (14:32 -0700)]
daemon/tls: downgraded TLS logging to verbose
Logging handshake and connection failures should be verbose, as
it's not really a server failure if client errors, or uses a wrong
SPKI pin to the certificate. It is however not ideal to flood logs.
Tomas Krizek [Thu, 22 Mar 2018 15:59:48 +0000 (16:59 +0100)]
ci: execute OBS build nightly instead of after every change
There are couple reasons to prefer nightly builds:
- to conserve hw resources
- automated builds at predictable times make it easier to use the devel
repo for manual testing builds
Vladimír Čunát [Wed, 7 Mar 2018 09:40:25 +0000 (10:40 +0100)]
make: don't magically -D_FORTIFY_SOURCE=2
This is just annoying for development. You want -O0 or -Og,
and consequently you get lots of warnings that are difficult to disable.
I believe hardening options are more of a responsibility/choice of the
caller, typically distributions have some general policies and pass the
flags (almost) uniformly to all packages. I can't see any part of kresd
being so specific to warrant explicit hardening.