According to RFC6761 query to localhost domain should generate
immediate response with loopback ip address.

This allows to disable specific deny rules on zone-by-zone basis
as it should be according to RFC6303 sec.3. Disable can be done by
policy rule PASS.

Also any FORWARD rule for such zone will be evaluated before DENY
that query.

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.