We're a bit late with this ad-hoc rule; I think it was most useful
when SHA256 support in DS algorithms wasn't wide-spread yet.
(Note that DNSKEY algos have standardized no similar rule.)

Usage of SHA1 as DS algorithm is highly discouraged, but even at this
point it does *not* seem unsafe, in the sense of anyone publishing an
attack that would come anywhere close to breaking *this* usage of SHA1.

Fixes #80

ci: various test updates

See merge request !1243

Due to missing support on some of the regular runners, let's migrate
these tests to our special LXC runners. This should hopefully make the
results more reliable and stable.

The downside is that we have to keep an additional image (and recipe)
for LXC, since it' slightly different. However, it's probably worth it,
since we'll likely migrate some other tests there in the future (for
better stability).

policy docs: warn about filters and forwarding

See merge request !1241

Vladimír Čunát authored 3 years ago and Tomas Krizek committed 3 years ago

We've been notified about possibility of "cache poisoning" this way,
so let's document this drawback to make the expectations clearer.

hints docs: better explain shadowing by policies

See merge request !1244

doc: fix links to our mailing lists

See merge request !1247

Vladimír Čunát authored 3 years ago and Tomas Krizek committed 3 years ago

Their implementation was changed.
Fortunately I was able to find the message in Google's cache
and thus discover easily which one it is in the new archive.

doh2: fix CORS by adding `access-control-allow-origin: *`

See merge request !1246

I didn't feel like adding it to every test, so I picked a mix.
I confirmed this would fail before the parent commit.

For old doh we added this in commit a34aa1ee;
with the new implementation we somehow forgot.

release 5.4.4

Closes #692

See merge request !1245

# Conflicts:
#   NEWS

The typical DNSSEC problems should happen already when trying to
validate the DNSKEY set, so it's better to be more verbose there.

In the end I gave up on deduplicating with log_bogus_rrsig() code,
as it's different logging group, logging level, no kr_query, etc.

We can always easily add groups when needed.

The approach of the code was rather hacky, simulating some packets
arriving from upstream and making the module stack CONSUME that.
Instead we take a direct approach now: use the simplified validator API
and then insert into cache directly.

One effect is improved performance, and consequently roughly halving
the lag which happens when prefill module invokes this.
(With root zone the lag goes down to 0.1 s from over 0.2 s,
 on my relatively fast CPU.  Fortunately it's just once a day.)

Closes #689

The following actions will now be logged in debug level (or request
tracing): ANSWER, DENY, DENY_MSG, DROP, REFUSE, TC

This can be useful for RPZ and other policy debugging.

Purposefully ommitted actions:
PASS - since it's the same as normal processing
REROUTE - the action itself comes from renumber module
STUB,FORWARD,TLS_FORWARD - this could be more confusing than useful
  (e.g. when response comes from cache)