Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NOERROR rcode is returned to a client when dynamic DNS update is rejected by the LUA updatepolicy #14953

Open
2 tasks done
kabenin opened this issue Dec 11, 2024 · 0 comments
Open
2 tasks done

Comments

@kabenin
Copy link

kabenin commented Dec 11, 2024

Thank you a lot for your hard work on PowerDNS. It is an amazing product!

  • Program: Authoritative
  • Issue type: Bug report

Short description

I run Authoritative server, that has Dynamic DNS Updates enabled and uses lua-dnsupdate-policy-script. In case an update request was rejected by the updatepolicy function, no update is performed (which is expected), and the NOERROR response is returned (which is unexpected). One may expecte rcode of REFUSED. RFC-2136 describes this rcode as:

REFUSED     5       The name server refuses to perform the
                                  specified operation for policy or
                                  security reasons.

Environment

  • Debian bullseye. I'm using docker desktop to run it under MacOS Sonoma, M1 chip.
  • Software version:
root@ns-primary:/# pdns_server -V
Dec 11 00:54:02 Loading '/usr/lib/aarch64-linux-gnu/pdns/libgsqlite3backend.so'
Dec 11 00:54:02 [gsqlite3] This is the gsqlite3 backend version 4.9.2 (Sep 30 2024 10:34:20) reporting
Dec 11 00:54:02 This is a standalone pdns
Dec 11 00:54:02 Previous controlsocket '/var/run/pdns/pdns.controlsocket' is in use
  • Software source: PowerDNS repository

Steps to reproduce

I use Authoritative DNS server under docker with sqlite3 backend. There is a single zone example.com. I can share my docker file if that helps, but it basically just follows steps outlined for debian on (https://repo.powerdns.com/).
Here is my updatepolicy.lua file:

root@ns-primary:/etc/powerdns# cat /etc/powerdns/updatepolicy.lua

function updatepolicy(input)
    return false
end

here is my pdns.conf:

root@ns-primary:/etc/powerdns# cat /etc/powerdns/pdns.conf
primary=yes
webserver=yes
api=yes
reuseport=yes
#numeric: 0 = emergency, 1 = alert, 2 = critical, 3 = error, 4 = warning, 5 = notice, 6 = info, 7 = debug
loglevel=7

dnsupdate=yes
allow-dnsupdate-from=192.168.0.0/16 10.0.0.0/8
lua-dnsupdate-policy-script=/etc/powerdns/updatepolicy.lua

launch=gsqlite3
gsqlite3-database=/pdns.dat
  1. add a testing TSIG
pdnsutil import-tsig-key testing hmac-sha512 "Wpc7R1R080pCnS2OlqCl7wuqIvV/YT+/IBKKLuP8K3PEJHq1iqZt6qtRmNyIstnKpr7j+kT9ZrcV2nKQEIjBMA=="
  1. Try updating example.com by adding a new record. I tried 2 methods. Using nsupudate command line tool and using dnspython library. Here is my test_nsupdate.sh script:
nsupdate <<!
server 127.0.0.1 5533
zone example.com
update add testme.example.com. 300 A 127.0.0.1
key hmac-sha512:testing. Wpc7R1R080pCnS2OlqCl7wuqIvV/YT+/IBKKLuP8K3PEJHq1iqZt6qtRmNyIstnKpr7j+kT9ZrcV2nKQEIjBMA==
send
!
exit $?
  1. Run the script. No error returned (exit code is 0 and no errors printed).
  2. If I delete tsig creted above and try nsupdate again, I'm getting an expected REFUSED error:
❯ bash test_nsupdate.sh
; TSIG error with server: expected a TSIG or SIG(0)
update failed: REFUSED
❯ echo $?
2

Expected behaviour

I would expect an rcode REFUSED in case an update was rejected by the policy

Actual behaviour

No updates are made on the backend, but no error reported back to the client

Other information

If the updatepolicy returns alse here
PDNS does not act on this update at all, and if other names in this update did not trigger errors, NOERROR is returned.

Documentation for lua updatepolicy says:

 To permit change, return true, otherwise return false. The script is called for each record at a time and you can approve or reject any or all.

which does not specify, what happens if any of records were rejected. This language is not explicit enough discussing the return value, unlike 'How it works' documentation section. However, step 12 of this algorighm suggest at least ServFail result. But I really think Refused will be better in this particular case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant