Without it we were failing to download fstrm tarball,
and the shown errors were very confusing.
Tested building an image locally.

Grigorii Demidov authored 7 years ago and Vladimír Čunát committed 7 years ago

unecessary queries in some circumstances; some minor bugfixes

Grigorii Demidov authored 7 years ago and Vladimír Čunát committed 7 years ago

it can contain records which have not been validated by validator

Grigorii Demidov authored 7 years ago and Vladimír Čunát committed 7 years ago

Don't check proof of nonexistance in NODATA or NAME ERROR answers
which contains a CNAME.

In particular, don't mention things that probably don't work (well):
Windows, amalgamation, very old OpenSUSE package.

I also verified there's no other usage of the `moduledir` symbol from
lua.  Bug introduced in 2f81b111 (within !298).

Leo Vandewoestijne authored 7 years ago and Vladimír Čunát committed 7 years ago

(the port will soon be 1.3.0 also)
Close https://github.com/CZ-NIC/knot-resolver/pull/43.

Leo Vandewoestijne authored 7 years ago and Vladimír Čunát committed 7 years ago

This tiny addition was needed to be able to install on FreeBSD.
Close https://github.com/CZ-NIC/knot-resolver/pull/44

lua kres-gen: add a guide to re-generating

See merge request !310

http://www.root-servers.org/news/b-root-begins-anycast-in-may.txt

Update the final date for 1.3.0 release

See merge request !308

iterate: be more precise when detecting CNAME loops

See merge request !307

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.

- 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.

Valid CNAME chains that ended in NODATA had AD flag set.