[Pdns-users] Lua view record - how to return NXDOMAIN?

[Djerk Geurts]

On 30 Oct 2024, at 13:54, Otto Moerbeek <otto at drijf.net> wrote:
> 
> On Wed, Oct 30, 2024 at 01:18:08PM +0000, Djerk Geurts wrote:
> 
>> On 30 Oct 2024, at 07:30, Otto Moerbeek <otto at drijf.net> wrote:
>>> 
>>> On Tue, Oct 29, 2024 at 10:14:29PM +0000, Djerk Geurts via Pdns-users wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> Is there a way to return NXDOMAIn instead of a valid response?
>>>> 
>>>> test IN LUA CNAME "view({{{'10.0.0.0/16'},{‘ns0.internal.domain.com.'}},{{'0.0.0.0/0'},{''}}})”
>>>> 
>>>> I would like to return NXDOMAIN instead of SERVFAIL for sources outside 10.0/16.
>>>> 
>>>> Thanks,
>>>> Djerk Geurts
>>> 
>>> I don't think NXDOMAIN responses are possible from Lua records.
>> 
>> I saw a request on GitHub for this from a while ago, so if it could be added, that would be great.
>> 
>>> I guess a NODATA (rcode NOERROR + empty answer section) is the closest you
>>> can come.
>>> 
>>> views do not like empty response sets, but this worked for me to get a
>>> a NODATA:
>>> 
>>> test.example     10      IN      LUA     A "; if (0==1) then return {'1.2.3.4'} else return {} end"
>>> 
>>> Maybe you can work from this.
>>> 
>>> 	-Otto
>> 
>> That’s helpful, but I’ll need to work out how to combine the two. `view()` takes all text literally so `return{}` doesn’t yield NODATA.
>> 
>> Equally I don’t know how to test for a source address in the if statement. https://doc.powerdns.com/authoritative/lua-records/ only gives examples for `if(continent`, but this article has some interesting LUA records: https://blog.powerdns.com/2017/12/15/powerdns-authoritative-lua-records
>> 
>> I tried this, but it’s not working:
>> 
>> "if(netmask({'10.0.0.0/16'})) then return {’true.domain.com.'} else return {‘false.domain.com'} end"
> 
> This works here:
> 
> test.example     10       IN      LUA     A "; nmg = newNMG(); nmg:addMask('10.0.0.0/8'); if nmg:match(who) then return {'1.2.3.4'} else return {} end"
> 
> 	-Otto

Thank you Otto, I’ve just found that my testing was flawed. On Linux using `host` to do an external lookup it would hit the local systemd resolver and show SERVFAIL. Switching to dig and using directed queries to the name server, I can see that your last suggestion indeed works. Thank you!

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25388
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

The whole point to doing this is creating insecure delegation records when internal clients query the public name servers for dnssec details, without leaking internal details to the internet.