Restrict named to only allow nsupdate from localhost + key

Red Squirrel

[H]F Junkie
Joined
Nov 29, 2009
Messages
9,211
I just discovered an interesting named command called nsupdate which basically allows you to update records on the fly without having to restart/reload the service, just need to setup the records differently and create a secret key that is used for updating as a form of authentication. I wrote a script so that my home IP can automatically update when it changes as I used to do it manually but now it's automated.

So I got that working nicely, basically the script is called via SSH from a cron job on one of my home VMs and it uses the $SSH_CLIENT variable on the server to determine the origin IP then compares to what the current IP is set to and updates if needed. Works great, but I don't like the idea that nsupdate also works from outside the server, and I simply have no need for it. I can't seem to find info on how to restrict updates to require the key AND a certain host. Is there a proper way of doing that? I found some way of doing it but it's ridiculously nasty, there's got to be a better way. Seems like a rather basic security option that should be there.
 
Wow.

I don't like the idea that nsupdate also works from outside the server, and I simply have no need for it. I can't seem to find info on how to restrict updates to require the key AND a certain host. Is there a proper way of doing that? I found some way of doing it but it's ridiculously nasty, there's got to be a better way. Seems like a rather basic security option that should be there.

You want to do dynamic DNS, but you don't want to allow connections from outside the server to update. ????????
 
Do you even read the BIND manual?

http://www.bind9.net/arm910.pdf

Read it entirely, then come back if anything is still unclear.

Edit: Out of curiosity: does your current setup involve views already?
 
Last edited:
Wow.



You want to do dynamic DNS, but you don't want to allow connections from outside the server to update. ????????

I'm running it from localhost.

Setup key pair with SSH, client SSHes in and runs nsupdate using the IP in $SSH_CLIENT. Basically SSH is already opened for administration, so may as well use that instead of creating another potential attack vector. Seems like a rather basic security practice to me. If someone was to figure out the key or an exploit in the way the query is processed they could change/add/delete records for that particular zone.

Do you even read the BIND manual?

http://www.bind9.net/arm910.pdf

Read it entirely, then come back if anything is still unclear.

Edit: Out of curiosity: does your current setup involve views already?

Sure I could comb the entire manual but I'm wondering if someone knows off the top of their head how to do it. No idea about views, I don't imagine so unless it's part of the default config. I just setup zones for each domain that's needed, maybe tweaked a few things and that's about it. It's chrooted, which is also part of the default config. Combing through a manual to know how to setup something does not usually help much, tutorials on the other hand give proper examples so it's easier to just find a tutorial that shows how to do something and then do it. Manual is good for reference if you already know what to look for. I could not find much on disabling nsupdates from external IPs, unless I skip using keys and then just put localhost, but then if it was a shared server any user would be able to run it, so not that secure. I don't have any other users though so if worse comes to worse I can always do that, but I rather use the key in addition to IP restriction.
 
Last edited:
Updates run over the standard port 53 as special queries. The server is exposed anyway. You could play around with views to separate access by source address.

Combing through a manual to know how to setup something does not usually help much

That's what the manual is for! Most of the stuff about BIND I have learned from the manual. A tutorial is from idiots for idiots who don't really care about what they do and just want some stuff done a la painting by numbers. Or when there's no good documentation available, which Linux is notorious for.

The BIND manual is actually good and I suggest going through it.
 
What is the point in settings something up when you don't understand it. Excellent fun when it comes to fault finding.
 
Back
Top