rndc key issues
Closed this issue · 21 comments
I am having troubles getting a slave DNS server to refresh zones because rndc "can't get key". By default, rndc looks in /etc/bind/rndc.key - which , in my case, is zero length. The key I specifiy in the module is stored under /etc/bind/keys.... the /etc/bind/rndc.key file is zero length. I cannot declare a FIle['/etc/bind/rndc.key'] because of the duplicate declaration in params. What am i doing wrong?
It's possible that this is a platform issue. What operating system is it? The bind package for Debian-family distributions creates the /etc/bind/rndc.key file, but I don't know for sure that others also do this.
Thatnks for the quick response.... I neglected to inform you that I am trying this on Ubuntu 12.04 LTS (Precise). In accordance with the params file, a zero length /etc/bind/rndc.key is created.
Here is my code snippet FWIW:
bind::key {'rndc-key':
algorithm => 'hmac-md5',
secret => 'xxnxisfkjsbfslknfgsl;kjgnsdrgljkb==',
}
Ok, that's a platform the module should fully support. I'm struggling to understand what happened to the rndc.key file that the package created. The module supplies no content for this file because the package should handle this. I'll play around on a VM to figure out what's going on.
I apologize for giving such little info at a time:
The key file is created, /etc/bind/keys/rndc-key; /etc/bind/keys.conf has include /etc/bind/keys/rndc-key, and has #include /etc/bind/rndc.key
/etc/bind/rndc.key is zero length. I can't create a link from /etc/bind/keys/rndc-key to /etc/bind/rndc.key because of the duplicate declaration issue.
When running rndc refresh zone, I get an error stating that is can't "get key"
If I copy or link /etc/bind/keys/rndc-key to /etc/bind/rndc.key, the rndc refresh command works fine
I haven't had much of a chance to get into this issue today, and looking ahead at the next week my time will be a bit touch and go. Are you able to proceed with your workaround until we can get a code change together?
Oh, also... I took a look into the Debian package (of which Ubuntu uses a slight variation) and how it is intended to work. I haven't been able to find exactly what stage of the installation makes the rndc.key file in /etc/bind. I have also noticed that the documentation for rndc claims it looks for its configuration at /etc/rndc.conf by default and the key at /etc/rndc.key, which seems inconsistent.
The module doesn't do much to support rndc, and it certainly doesn't try to control the rndc.key contents. This was by design, but it appears reasonable to try to do more with rndc configuration. When I do get a chance to work on this more, I plan to pursue that route.
Yes Nate, that's fine.
This is not critical for me at the moment. I have some functioning DNS servers. I have at least a week to work on this.
If you're timing on a code change is in the next ten days, I can wait. If the timing is two weeks or greater, I'll spend some time on a workaround.
Thanks,
Tony
On January 15, 2015 at 5:12 PM Nate Riffe notifications@github.com wrote:
I haven't had much of a chance to get into this issue today, and looking ahead at the next week my time will be a bit touch and go. Are you able to proceed with your workaround until we can get a code change together?
—Reply to this email directly or view it on GitHub.
Ubuntu is inconsistent in all aspects :) or should I says not like all the others ....
yes, the default is what you said ..... one can manually specify an alternate location, but not permanently change that location - that I know of.
AS A WORKAROUND:
Is it reasonable, and safe, to comment out the rndc.key entry in the params file? If so, I can insert a symlink in /etc/bind to point to the key file that is created.
On January 15, 2015 at 5:17 PM Nate Riffe notifications@github.com wrote:
Oh, also... I took a look into the Debian package (of which Ubuntu uses a slight variation) and how it is intended to work. I haven't been able to find exactly what stage of the installation makes the rndc.key file in /etc/bind. I have also noticed that the documentation for rndc claims it looks for its configuration at /etc/rndc.conf by default and the key at /etc/rndc.key, which seems inconsistent.
The module doesn't do much to support rndc, and it certainly doesn't try to control the rndc.key contents. This was by design, but it appears reasonable to try to do more with rndc configuration. When I do get a chance to work on this more, I plan to pursue that route.
—Reply to this email directly or view it on GitHub.
I had a chance to spend a quick minute with strace and rndc on a fresh VM this morning. The documentation is inconsistent. The default rndc.conf location is actually /etc/bind/rndc.conf and default key location is /etc/bind/rndc.conf. In the absence of a configuration file, it uses defaults for all other settings, including the location of the key. The Puppet module currently does nothing to try to control any of this except to leave the existing rndc.key file in place and optionally include it in the named configuration (thus enabling rndc usage at all). I have an idea of a change I'd like to make in the Puppet module. I'll cut a branch and work on it a little over the weekend.
I'll also submit a bug to Debian to fix up the documentation.
Nope, bug exists...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597029
Thank you Nate
On January 16, 2015 at 8:09 AM Nate Riffe notifications@github.com wrote:
I had a chance to spend a quick minute with strace and rndc on a fresh VM this morning. The documentation is inconsistent. The default rndc.conf location is actually /etc/bind/rndc.conf and default key location is /etc/bind/rndc.conf. In the absence of a configuration file, it uses defaults for all other settings, including the location of the key. The Puppet module currently does nothing to try to control any of this except to leave the existing rndc.key file in place and optionally include it in the named configuration (thus enabling rndc usage at all). I have an idea of a change I'd like to make in the Puppet module. I'll cut a branch and work on it a little over the weekend.
—Reply to this email directly or view it on GitHub.
I'm pretty sure I've got the issue resolved. There is better support now for key generation and plcaement in general, but more specifically I found this:
This is a much better explanation of rndc default behavior than any of the man pages.
If you could please give the master branch a try and let me know if it solves your issue, I'll release a new version.
I've spent a little time on ths branch code that I pulled from git
I had to comment out my entry for bind::key , whose name is rndc-key.....this was my own key I created, but now complains of a duplicate decaration from your init.pp:51
Another thing that I can't figure out is the allow_query: I get a REFUSED when doing an nslookup against this server
On January 18, 2015 at 10:50 AM Nate Riffe notifications@github.com wrote:
I'm pretty sure I've got the issue resolved. There is better support now for key generation and plcaement in general, but more specifically I found this:
https://deepthought.isc.org/article/AA-00722/0/Why-does-rndc-log-warning-key-file-...-exists-but-using-default-configuration-file-rndc.conf.html:
This is a much better explanation of rndc default behavior than any of the man pages.
If you could please give the master branch a try and let me know if it solves your issue, I'll release a new version.
—Reply to this email directly or view it on GitHub.
Yes, rndc-key is declared in the module now.
Regarding querying, have you declared a view? The necessity is not well documented, but any zones you have defined are included in the named configuration through inclusion in a view. With no views, a simple resolving name server should still work.
I do have a view declared. Maybe I am not using it correctly.
Here is my whole config for DNS using your module:
node /dns/ inherits resources { #class { 'xxxxxx::user::dns': } class { 'xxxxxx::network::default': } #class { 'xxxxxx::servercfg::dns': } class { 'bind': dnssec => 'auto', rndc => true, allow-query => ['local-key',], #dnssec-validation => 'auto', }# file { '/etc/bind/rndc.conf':# ensure => present,# source => 'puppet:///modules/bind/rndc.conf',# } bind::zone { 'xxxxxx.com': zone_type => 'slave', #ns_notify => true, masters => ['10.0.1.29', ], #allow_notify => ['10.0.1.29', ], #key_directory => '/var/cache/bind/db.xxxxxx.com', } bind::zone { 'xxxxxxusa.com': zone_type => 'slave', ns_notify => true, masters => ['10.0.1.29', ], allow_notify => ['10.0.1.29', ], key_directory => '/var/cache/bind/db.xxxxxxusa.com', } bind::zone { '10.in-addr.arpa': zone_type => 'slave', ns_notify => true, masters => ['10.0.1.29', ], allow_notify => ['10.0.1.29', ], key_directory => '/var/cache/bind/db.10', } bind::view {'clients': recursion => true, match_destinations => ['127.0.0.1','10.0.0.0','172.20.0.0',], zones => ['xxxxxx.com' , 'xxxxxxusa.com' , '10.in-addr.arpa', ], } #bind::key {'rndc-key': bind::key {'local-key': algorithm => 'hmac-md5', secret => 'w6rrpS15viAMPP5VyVUM7g==', } bind::acl {'xxxxxx': addresses => ['127.0.0.1/24','10.0.0.0/8','172.16.0.0/12', ], }}
The server IP itself is in the 10.0.0.0 network. When I test, I just specifiy the server's own IP address when doing an nslookup:
server 10.252.1.43
hostname
** server can't find xxx: REFUSED
P.S. : I don't mind not scrubbing the names, if I knew the message wouldn't be posted for all to see (If that would make a difference)
On January 19, 2015 at 10:32 AM Nate Riffe notifications@github.com wrote:
Yes, rndc-key is declared in the module now.
Regarding querying, have you declared a view? The necessity is not well documented, but any zones you have defined are included in the named configuration through inclusion in a view. With no views, a simple resolving name server should still work.
—Reply to this email directly or view it on GitHub.
The formatting of the manifest has been completely lost in email, but I think I see you're trying to use an allow-query parameter to the bind class. There is no allow-query parameter. Do you intend to restrict querying globally within this nameserver?
I noticed that I had natch-destinations set for the bind::view, so I changed it to match-clients
when puppet agent -ran, i saw that it removed match-client {any} and added what I had specified.
That didn't work either...
This did:
bind::view {'clients': recursion => true, match_clients => ['127.0.0.1','10.0.0.0/8','172.20.0.0',], zones => ['xxxxx.com' , 'xxxxusa.com' , '10.in-addr.arpa', ], }
I think what I have will work now. Thank you for all your help!
On January 19, 2015 at 10:32 AM Nate Riffe notifications@github.com wrote:
Yes, rndc-key is declared in the module now.
Regarding querying, have you declared a view? The necessity is not well documented, but any zones you have defined are included in the named configuration through inclusion in a view. With no views, a simple resolving name server should still work.
—Reply to this email directly or view it on GitHub.
Glad to help! If there's anything else, please let me know.
I have released the rndc related changes and some minor updates to the documentation in version 3.5.0, now available on the forge.
Thank you!
On January 19, 2015 at 5:22 PM Nate Riffe notifications@github.com wrote:
I have released the rndc related changes and some minor updates to the documentation in version 3.5.0, now available on the forge.
—Reply to this email directly or view it on GitHub.