pdns REC: Mishandling of NSDNAME + NSIP triggers through RPZ

[x] This is not a support question, I have read about opensource and will send support questions to the IRC channel, Github Discussions or the mailing list.
[X] I have read and understood the 'out in the open' support policy
Program: Recursor
Issue type: "Bug" report

Short description

I think I've found a bug in how the rpz-nsdname is handled by the recursor.

The domain that tricked my attention is iod.at as it resolves to the NS of both *.dan.com + *.undeveloped.com. However, the *.dan.com is in the RPZ list (block) and should therefor be tricked, but it isn't, instead it is just served over *.undeveloped.com.

As far I understand from the RFC draft-ietf-dnsop-dns-rpz-00 section 4.4 and 4.5, then this query should have responded with the NXDOMAIN.

IRC quotes

To not point any fingers, no names are mentioned.

draws the attention to the comment in section 9.4 ("Use Glue for NSDNAME and NSIP Checks") explains the trade-offs; Now let us prof them wrong, right? and make the code right and show them this can be done without any of the drawbacks mentioned.

you could argue for a switch to always evaluate NSs at the end, but it would likely have a noticeable CPU and latency impact

although I guess PowerDNS ignores the NS records in the additional section and thusly won't trigger the rule An implementation MAY use either, both, or whichever is currently available.

I would suggest making a ticket with all the info so ottom can figure this out

short story about the problem

In this particular case the domain in question is somewhat harmless throughout the internet, as it is a hijacked domain, however the case could easily have been concerning something like malicious, phishing or any other really unwanted stuff we would like to block access to. The problem this issue is showing is that in this case I can't blacklist the DNS servers of *.undeveloped.com as they are also hosting domains we don't want to block, only *.dan.com serves blokable domains.

Case example

In a case where IE any of the amz AUTH servers, serves the NS records, and another one comes from a AUTH that only servers bad/hijacked or whatever domains, then we are in trouble and the RPZ .rpz-nsdname + .rpz-nsip record types becomes very unreliable for safeguarding any networks.

Trace log

There was an error creating your Issue: body is too long (maximum is 65536 characters).

Log is moved to https://gist.github.com/spirillen/3948e4d1a3d4487233ede057f6da422b

The log for verification

The following RPZ records are in place

24261063,12,*.dan.com.rpz-nsdname.pirated.mypdns.cloud,CNAME,.,300,0,0,,1
24261090,17,*.dan.com.rpz-nsdname.blacklist.matrix.lan,CNAME,.,300,0,0,,1

Environment

Operating system: ubuntu 22.04.3
Software version: sudo rec_control version: 4.6.0
Software source: PowerDNS repository

Steps to reproduce

add *.dan.com.rpz-nsdname.pirated.mypdns.cloud to your RPZ (Auth in this case)
wait for propagating the zone to the recursors rpz
query for 'iod.at'

Full rpz record(s) in the AUTH server

24261063,12,*.dan.com.rpz-nsdname.pirated.mypdns.cloud,CNAME,.,300,0,0,,1
24261090,17,*.dan.com.rpz-nsdname.blacklist.matrix.lan,CNAME,.,300,0,0,,1

Expected behaviour

I would expect the query for 'iod.at' would have returned the NXDOMAIN according to section 4.4 + 4.5 in the RFC draft for RPZ

Actual behaviour

I get a undesirable A record for 'iod.at'

dig @127.0.0.1 -p 53 iod.at

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> +nocookie iod.at
;; Got answer:

...

;; ANSWER SECTION:
iod.at.                 7200    IN      A       3.64.163.5

Other information

Any question... just ask, there are no suck thing as stupid questions, but people do ask stupidly...

Dec 20 '23 00:12 spirillen

As the time goes, I start to think the RPZ are missing a crucial value in it's standard... a weight/priority system... as there constantly would be conflict between blocking and allow the query to pass or not. What do you other think, should this be commended to the draft? and if it should be implanted, then how? The only alternative is to give the zone's a weight system as mentioned in this issue at unbound https://github.com/NLnetLabs/unbound/issues/1104

Jul 13 '24 20:07 spirillen

The unbound issue seems to be not really relevant as it concludes: it was a misonfigure/typo.

We document our processing and priorities of RPZ zones in https://docs.powerdns.com/recursor/lua-config/rpz.html#evaluation-order, so there is a priority mechanism. It follow mostly the draft standard with a few noted exceptions.

I agree that using NSDNAME and NSIP triggers in RPZs is less than useful.

I'm am closing this issue, if a concrete proposal appears to get better NSDNAME and NSIP handing in RPZ, I'm all for it, as long as it an improvement of the (draft) standard that can be implemented by all vendors and has less drawbacks that what we have now.

Dec 09 '24 10:12 omoerbeek