3

I have a pool of authoritative DNS servers that have to host zones for 5 users each of which have between 2 and 10 zones.

Each user can ssh to the servers using public key authentication. The requirements I am facing say that as long as the user is able to connect to the ssh port on the server, they must also be able to update their own zones without relying on any other network communication.

What I have done so far is to configure each zone to be loaded from the home directory of the user owning the zone as in this example:

zone "example.com" {
     type master;
     file "/home/example/zones/example.com";
};

I don't know if there exist any recommendations about loading zone files directly from a user's home directory. I tried a few searches and found no recommendations for or against this practice.

It appears to work, but changes only take effect after I have either restarted or reloaded bind, which I currently has to do as root.

The distribution I am using provides BIND 9.8 with security patches. So I downloaded the 9.8 version of "BIND 9 Administrator Reference Manual" to look for ways for a user to instruct bind to reload a zone.

I found the rndc command, however it appears the access controls on BIND are not fine-grained enough to allow a secret to be used only to reload a specific zones. I can specify combinations of IP addresses and HMAC-MD5 secrets permitted access, but any such combination permitted access will be permitted to invoke all commands through rndc.

How do I allow a user to reload their zone files without granting them other administrative rights?

At this point I am thinking I could use either sudo or the command option in .ssh/authorized_keys to give a user access to invoke a specific rndc command.

Is this an advisable approach or should I be doing something else?

I have also considered using zone transfers. But my understanding of how zone transfers work is that the receiving DNS server act as client in the zone transfer and the sending DNS server act as server. If my understanding is correct it means having a client provide a new version of the zone to the server isn't possible. So it seems if I were to take this approach I would have to use a hidden master setup with that hidden master running on a VPN client, which for reasons I cannot fully formulate feels wrong.

1
  • sudo is your friend.
    – Roy
    Jan 27, 2016 at 14:17

3 Answers 3

13

i'd make it via sudo

user1    ALL=(root)    /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2    ALL=(root)    /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com
1
  • 1
    This is the simplest approach to the problem and also the most specific in terms of the rights you grant to your users. It is the correct way to go when you want to allow a user to perform any specific set of actions as root.
    – Carcer
    Jan 26, 2016 at 0:19
1
+50

You could ask your clients to use a rcs tool like git to update their zone files and push them to their homedirs. There, create a git repository with a post receive hook that runs those commands using the sudo rules user1700494 indicates (I would add named-checkzone and named-checkconf as well).

For completeness sake, here are the sudo rules user1700494 suggested

user1    ALL=(root)    /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2    ALL=(root)    /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com

That way you keep everything in version control so you can easily go back if necessary, and your users do not need to login and modify files on the server, everything can be done on their own environment. Additionally you only reload the server after having verified the files are correct.

9
  • The zone files are already being pushed to the server using Mercurial (with SSH for the transport). I believe I know enough about Mercurial to adapt your proposal from git to Mercurial. However the exact part about where to to run the named-checkzone command is a bit unclear to me. Which user would you run that as? And should I still have BIND load the files from the home directory? If I run named-checkzone after updating to the latest repo version and it fails, that would mean the bad update is already in the location where BIND would load it from next time it is restarted.
    – kasperd
    Jan 27, 2016 at 18:57
  • I am wondering what is the reason for suggesting to run named-checkconf as well. Is that just for additional paranoia? Or is there some way named-checkconf could catch problems with the zone files?
    – kasperd
    Jan 27, 2016 at 18:59
  • I think you should update your answer such that it can be understood on its own without having to read the other answer you are currently referring. That would make your answer better. (Your answer is the best so far, but there is still room for improvement.)
    – kasperd
    Jan 27, 2016 at 19:02
  • :-) paranoia it is, I have had bind give up on me with wrong configs, so better safe than sorry. The named-checkzone command should work ok without root rights (as long as the user account has read rights on the files), named-checkconf fails at least in centos 6 (where I am testing now) because out of the box /etc/named.conf is 640 root:named. Jan 27, 2016 at 19:06
  • I was just thinking. Should I be concerned about the checks being done in a way where the user could bypass them or modify the files after they have been checked?
    – kasperd
    Jan 27, 2016 at 19:08
0

I would advice the each bind instance to be run on an LXC. Each user having their own Bind instance. Supply them with the credentials of their respective instances.

3
  • We don't have enough IP addresses to allocate one to each user.
    – kasperd
    Jan 27, 2016 at 13:41
  • Even if I had enough IP addresses I couldn't just allocate one to each user. The operator of the TLD used by most of the domains impose restrictions on what we are allowed to put in the NS records on the TLD servers. So for all practical purposes we do have to serve all of the domains from a single BIND instance. As far as I can tell that means your recommendation would require me to keep the LXC instances internal and do zone transfers from the LXC instances to the bind instance outside LXC. Is that the configuration you would recommend?
    – kasperd
    Jan 27, 2016 at 16:06
  • If I am going to take the zone transfer approach, there has got to be better approaches than hosting an LXC instance on the DNS server itself. I could use some VPN solution to allow a DNS server to be brought up on the client side for the duration of the zone transfer. Opening yet another port for the VPN feels like it would increase the potential attack surface unnecessarily though, so maybe tunneling IP through SSH might be better (sounds like a compromise between performance and security). This is probably deviating quite far from what you had in mind. Maybe you'd elaborate a bit on that.
    – kasperd
    Jan 27, 2016 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .