[FR] Specify if the order of entries in an RPZ file matters

[zacknewman]

Current behavior
unbound.conf(5) does not state whether the order of the entries in a Response Policy Zone (RPZ) file matters. While in the Response Policy Zone Options section, it states "RPZ clauses are applied in order of configuration"; it would be nice to know if the order of entries in a given file is also adhered to.

Describe the desired feature
Explicitly state whether the order of RPZ file entries matters.

Potential use-case
I am using unbound as both a recursive resolver and "ad blocker". When having a wildcard entry that corresponds to one RPZ action (e.g., CNAME .), one may want to perform a different action on specific subdomains (e.g., CNAME rpz-passthru.). As an explicit example, what is the outcome of a DNS query for www.example.com based on an RPZ file that looks like below?

$ORIGIN example.
www.example.com CNAME rpz-passthru.
*.example.com CNAME .

If the order of entries matters, then the query will be resolved normally; however if the order of entries does not matter, then sometimes the response will be NXDOMAIN and other times it will be resolved normally. It would be nice to know either way.

Based on a very small sample size, it appears that the order does matter; but that can be a fluke and so I would like to know for certain if one can actually rely on that always being the case.

[spirillen]

I actually have a similar situation where is seems like any "Blocking" rule super seeds "permissive" rules like the passtrhu.

There can be a numerous good arguments for why this is, however, in my case I maintenance a local rpz zone that differs from my projects records *.mypdns.cloud", in my local RPZ zone I have a number of rpz-passthru` records for e.g. GitHub like these

avatars.githubusercontent.com.blacklist.matrix.lan,CNAME,rpz-passthru
private-user-images.githubusercontent.com.blacklist.matrix.lan,CNAME,rpz-passthru

Whereas the @matrix project have the following records

raw.githubusercontent.com.whitelist.mypdns.cloud,CNAME,rpz-passthru
*.githubusercontent.com.malicious.mypdns.cloud,CNAME,.
*.githubusercontent.com.tracking.mypdns.cloud,CNAME,.

Expected behaviour is to get the PASSTRUE = the IP for both avatars- private-user-images.githubusercontent.com

While the log for sure show what actually happens.

Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: 127.0.0.1 avatars.githubusercontent.com. A IN
Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: rpz: applied [malicious policy] *.githubusercontent.com. rpz-nxdomain 127.0.0.1@36385 avatars.githubusercontent.com. A IN
Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: 127.0.0.1 avatars.githubusercontent.com. A IN NXDOMAIN 0.000000 1 58

The question is now, how can the expected output be accommodated by using the RPZ standard rules? is this a request for a weight system, from where a list with the weight of 0 supersedes other lists? (As Zero is the first number in the IT universe and stays first in line)

[gthess]

@zacknewman, the order of records in a single RPZ file does not matter. An RPZ file is just a regular zone file with extra metadata information. In your example www.example.com. exists and will match the passthru rule. Anything else that does not exist under example.com. (because of the wildcard) will match the NXDOMAIN rule. Duplicate records in the zonefile are ignored by Unbound. I'll update the text on the man page to reflect this.

@spirillen, I believe you are talking about different rpz feeds (different rpz: clauses in Unbound). I will reply to your issue instead.

[zacknewman]

Yeah, it appears to be the case that the most specific match wins regardless; so even though www.example.com matches *.example.com which appears first; the rule on www.example.com "wins" since it's a more specific match. When multiple lines of the same specificity exist, then the first wins.

[gthess]

Note that a wildcard in DNS is not the same as a wildcard in regular expressions for example.
It is not a catch all under example.com, rather it only matches labels that do not exist.
Quick example for a zonefile with the following content:

one.example.com. TXT "exists"
two.example.com. TXT "exists"
*.example.com. TXT "wildcard"

A query for a.two.example.com. IN TXT will return NXDOMAIN.
It will not be expanded from the above wildcard because two.example.com exists in the zone.
In contrast a query for a.three.example.com. IN TXT will return "wildcard".

The same wildcard rules apply to RPZ files.

[zacknewman]

Foolishly I treated wildcards like a wildcard in a regular expression; hence the opening of this issue. Had I not been ignorant, I wouldn't have opened this. Apologize for the noise.

[gthess]

No problem! You would be surprised how often DNS people (including me) are bitten by wildcard semantics.