Policy reserved domains

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

Added test. and invalid. to special domain list

Also allows to disable specific deny rules from reserved domain list 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.

#205 (closed) implement reserved domains properly.

changed the description

added 1 commit

• cb044900 - policy: answer to reversed localhost query

Compare with previous version

resolved all discussions

assigned to @vcunat

added 1 commit

• bd3ba69b - policy: follow RFC6303 more closely

Compare with previous version

Reviewed the RFC and amended the implementation, then re-checked quite some answers, also in comparison to Unbound's. This might actually be relatively easy to test superficially via respdiff.

I'd like to think of this a bit more, e.g. on Omnia it's become common to avoid the local refusals via policy.del(0) which now probably won't work, etc.

added 27 commits

• bd3ba69b...d8fed142 - 26 commits from branch master
• a2f929a7 - Merge branch 'master' into policy-reserved-domains

Compare with previous version

I think that policy.del(0) is bad practice, it unblocks all of reserved domains. Local PTR resolving can be now allowed with: policy:add(policy.suffix(policy.PASS, {todname('168.192.in-addr.arpa.')}))

This is not perfect and I think we should answer only to records from hints module and other reserved domains should be blocked. Policy module should run after hints module and in produce phase. At least some actions should run in produce (DENY, PASS, FORWARD).

added 1 commit

• 520a5d15 - policy: implement NXDOMAIN for onion.

Compare with previous version

I agree! But I want to think of compatibility anyway. It came into use due to the difficulty of adding a rule to forward local zones, etc.

EDIT: that doesn't mean I'll make any such changes in the end; I just don't know yet.

added 1 commit

• b154c751 - policy: change the localhost. domain

Compare with previous version

changed milestone to %1.3.x

added 51 commits

• b154c751...758b133d - 47 commits from branch master
• dd78f620 - hints docs: clean a bit, note interaction with policies
• 9635aa40 - policy docs: rework it all
• 2f4317c1 - Merge branch 'master' into policy-reserved-domains
• b5f7b21d - NEWS: changes in this branch

Compare with previous version

mentioned in commit 956295a3

merged

changed milestone to %1.4.0

mentioned in commit deckard@b1ccad35

mentioned in merge request deckard!62 (merged)

I forgot to write – I thought about the compatibility and it seems perfect. Even invalid calls to policy.del will just return false instead of true, so I don't expect introducing any problems and I think this can be in 1.3.x (if we decide to make one).

Well, there's a tiny incompatibility: policy rules shadow hints just as before this MR – some might have worked around it by policy.del(0) but that won't work anymore and a different approach is needed (e.g. policy.PASS). Still, it seems rather unlikely to me that any real use case would be affected by that. I saw mainly the special-use default policy shadowing custom policies, but that's fixed by the MR.