Vladimír Čunát [Fri, 7 Jul 2017 15:13:26 +0000 (17:13 +0200)]
dns64: improve with policy.FORWARD or .STUB
Clearing the query flags lead to kresd iterating over authoritative
servers. Related: https://gitlab.labs.nic.cz/knot/resolver/issues/217
Note that validation of synthesised AAAA behind a CNAME doesn't work
when policy.FORWARD + dns64. Example: www.regiojet.cz.
policy.STUB + dns64 seems not to work at all.
Vladimír Čunát [Fri, 30 Jun 2017 06:48:59 +0000 (08:48 +0200)]
rplan: fix a coverity warning (CID 164834)
There would be no real resource leak, as the memory is on a mempool,
so the lifetime is limited by kr_request finishing. Also, it's only
on an unlikely error branch, but still...
Vladimír Čunát [Mon, 12 Jun 2017 13:40:02 +0000 (15:40 +0200)]
iterate: be more precise when detecting CNAME loops
Iterating over sibling sub-queries isn't precise enough,
and in particular in forwarding mode it reported non-existing loops.
Example ATM: www.dpo.cz - there forwarding spawns multiple sub-queries,
and one of those is a CNAME to another of them. Due to them being siblings,
the old code misdetected that as a CNAME loop. Now that we have these
cname_parent pointers, we can do a precise detection.
Vladimír Čunát [Thu, 8 Jun 2017 15:03:22 +0000 (17:03 +0200)]
validate: work around some SERVFAILs (iterating mode)
- This affects the iterating mode only (except for a verbose message).
- The problem was introduced when implementing forwarding in 651c5aad.
- Example that was affected: *.org.ru.
When the same server is authoritative for multiple consecutive zones,
with a higher one being signed and a lower one being unsigned, we may
get an unsigned answer even in case we *think* we're currently in a
signed zone.
In particular, DS (sub-)queries are important because of being used to
prove the insecurity of zones - in that case the iterator can correctly
determine the (unexpected) zone name from which the answer came, due to
seeing the SOA record, but that is too late for zone_cut_check() to try
getting a trust chain to it, so we need to YIELD for it to do it.
Vladimír Čunát [Wed, 17 May 2017 17:58:13 +0000 (19:58 +0200)]
resolve: remove an incorrectly added condition
This part of code is NOT reachable when forwarding, because
ns.name is . (the root) and retry is true.
kr_nsrep_elect* would ruin forwarding anyway, as they're written ATM.
Vladimír Čunát [Wed, 26 Apr 2017 12:53:49 +0000 (14:53 +0200)]
policy: purge pointer-casting where not necessary
Casting is dangerous, e.g. it's easy to misconfigure policy with
policy.add(policy.FORWARD('some address'))
which lead to segfault without showing any indication of the cause.
Now this case will show as
.../policy.lua:98: 'struct kr_query' has no member named 'current'
and only abort the policy module instead of the whole process.
Vladimír Čunát [Tue, 30 May 2017 16:31:10 +0000 (18:31 +0200)]
kr_ranked_rrarray*: avoid duplicate RRsets on wire
Fixes https://gitlab.labs.nic.cz/knot/resolver/issues/198.
We can't let multiple "matching RRsets" to the wire, and we can't just
merge the sets from multiple queries either. The only way is to choose
either of the sets and put it on the wire. ATM the last one wins.
Common ocurrence of the bug: if www.example.cz was a CNAME for example.cz
and we ask for a non-existent type, we would get the SOA record twice
in the final answer.
A few related changes:
- don't just assert, also return error code if -DNDEBUG
- kr_ranked_rrarray_set_wire: don't do full-content comparison anymore;
see the first paragraph in this commit message for the reasons
- minor refactoring of that code, more comments, etc.
Vladimír Čunát [Tue, 23 May 2017 19:30:54 +0000 (21:30 +0200)]
Revert "iterator: don't retry if REFUSED"
This reverts commit bc2a26702e6460aee65fe170671336d670ba3eb9 (almost).
It would be best to avoid retrying with the same NS and keep trying with
others (if any), but that would require larger changes if it should work
well, so let's err on the side of sending more queries.
Vladimír Čunát [Mon, 22 May 2017 13:13:19 +0000 (15:13 +0200)]
validate: avoid keeping KR_RANK_MISSING
If a sub-query transitions the state to QUERY_DNSSEC_INSECURE,
we didn't set correct rank. This lead to caching with _MISSING rank
which is too low to be utilized on re-queries. Example: nix.mx query.
Vladimír Čunát [Fri, 19 May 2017 12:59:39 +0000 (14:59 +0200)]
ranked rrarray: don't merge RRSIGs of different types
For example, kr_rrmap_add has been relying on sets covering just a
single type (for years). It's used by cache and there it's required to
store types separately.
It seems all other parts of code should be just OK with this.