Hi John, thanks for replying and your thoughts! I will intersperse my feedback within your comments -
On 03/13/2019 08:33 PM, John W. Blue wrote: > > Marc, > > > > Regarding your rndc problem, I think you might be confusing rndc. > > > > If rndc is invoked with no options, specifically “k”, then rndc > assumes the key it needs is in the rndc.conf file. If rndc.conf is > not present, rndc will use the default rndc.key file. That said, > since rndc knows there is an /etc/rndc.key file but it choosing to use > rndc.conf is the secret the same in both places? > Yes > > > > As an option, instead of including /etc/rndc.key nothing prevents you > from including rndc.conf. That way you are consistent with your useage. > I raised an eyebrow at this suggestion thinking oh how cool... but a quick attempt at including rndc.conf in named.conf lead named to bellyache about multiple "options" clauses... I will poke at it some more, as it would be nice to minimize the possibility of getting the two key definitions out of sync, which is why I tried it from the other direction using the include statement in rndc.conf... > > > > I personally do not use nsupdate, but I thought that key file had to > be created by dnssec-keyen and if you opt to use “k” then the file > suffix on the command line had to be “.private”. > Actually I did use dnssec-keygen to generate the key file! ;-) To be precise - > dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST letsencrypt That generates two files, one is a .key and the other is a .private It doesn't seem to matter which file I use with nsupdate, it seems happy with either and both files do contain the private key. In any event, no matter which I choose the persistence issue remains... > > > Hope that helps and good hunting! > At least you confirmed my thinking so far, great minds think alike! Marc... > > > > John > > > > *From:*bind-users [mailto:bind-users-boun...@lists.isc.org] *On Behalf > Of *Marc Chamberlin via bind-users > *Sent:* Wednesday, March 13, 2019 6:02 PM > *To:* bind-users@lists.isc.org > *Subject:* rndc and nsupdate failing to work for me > > > > Hello Bind Users, > > I have been working on upgrading my Bind 9.11.2 server (running on a > Linux system, OpenSuSE Leap 15) so that I can accept DNS > challenges/verification from/for LetsEncrypt certificates, and I am > running into a wall trying to get nsupdate (and rndc which I wanted to > use to test the server with) to work with the server. So I hope some > kind guru here can lead me into the light cuz I am lost.... > > My configuration is really not all that complicated, I am running the > server on a firewall computer that supports other services such as web > and email services also. I have a SOHO internal network behind the > firewall computer. I have configured the Bind (named) server with the > 3 standard views - localhost.resolver, internal, and external. Since I > support a number of virtual hosts and real hosts I have quit a few > zones defined for each view. For regular queries and things like zone > transfers the server is performing OK. > > That said I will show what I think are the relevant definitions from > my configuration files, with sensitive info redacted of course, and > follow on with questions I have - > > named.conf - > > There is a bunch of stuff at the beginning of this file, but I think > it is irrelevant to this issue. Correct me if I am wrong and I will be > happy to post it... > > include "/etc/rndc.key"; > controls { > inet * port 953 > allow { any; } keys { "rndc-key"; }; > }; > view "localhost_resolver" > { > match-clients { localhost; }; > match-destinations { localhost; }; > > ... more stuff here but I don't think it is relevant > > include "/etc/named.d/local/local_zones.conf"; > } > > view "internal" { > match-clients { 192.168.10.0/24; }; > match-destinations { 192.168.10.0/24; }; > recursion yes; > > ... more stuff here but I don't think it is relevant > > include "/etc/named.d/internal/internal_zones.conf"; > }; > > view "external" { > match-clients { any; }; > match-destinations { any; }; > recursion no; > > ... more stuff here but I don't think it is relevant > > include "/etc/named.d/external/external_zones.conf"; > }; > > This seems pretty straightforward configuration in named.conf. The > configuration of a zone in the external view typically looks like this - > > zone "mydomain.com" in { > file "/etc/named.d/external/master/mydomain.com"; > type master; > allow-transfer { "dnsmadeeasy1"; }; > also-notify { xx.xxx.xx.xxx; yyy.yyy.yy.yyy; zzz.zzz.zz.zz; }; > allow-query { any; }; > allow-update { > key "letsencrypt"; > }; > }; > > And this is what is in rndc.conf - > > key "rndc-key" { > algorithm hmac-md5; > secret "secretkeycodehere"; > }; > options { > default-key "rndc-key"; > default-server localserver; > default-port 953; > }; > server localserver { > addresses { 127.0.0.1 port 953; }; > key "rndc-key"; > }; > server intserver { > addresses { 192.168.10.100 port 953; }; > key "rndc-key"; > }; > server extserver { > addresses { xxx.yyy.zzz.aaa port 953; }; > key "rndc-key"; > }; > > Again, straightforward, and as I said normal queries do work.... > However when I use rndc to poke at it, this is what happens - > > # rndc showzone mydomain.com in external > WARNING: key file (/etc/rndc.key) exists, but using default > configuration file (/etc/rndc.conf) > rndc: 'showzone' failed: failure > > I don't understand why I am getting the warning, seems like a so what > since the keys are identical in both locations. (I couldn't figure out > if it is possible to use an include statement instead of the key > definition in rndc.conf) As for the failure when I asked it to do a > showzone, I don't have a clue as to why this is failing. Log files are > not helpful (and neither is this error message for that matter!) > > I am also experiencing problems with nsupdate in that changes I make > with it are not persistent across a restart of the named service. To > demonstrate this I have a file called test.txt - > > debug yes > zone mydomain.com. > update add test.mydomain.com. 86400 TXT "bar" > show > send > > and if I use it as follows this is what I see - > > # nsupdate -k /etc/letsencrypt/james/Kletsencrypt.+165+56715.key > -v ./test.txt > > I get lots of output and no indication of any problems. Using dig to > see if the update indeed works - > > # dig +short -t txt test.mydomain.com "bar" > "bar" > > it works, but if I restart the named service, no joy - > > # systemctl restart named.service > > # dig +short -t txt test.mydomain.com "bar" > > # > > > > > the update is not persistent! Any ideas? Thanks in advance for > helping me resolve these issues. Marc... > > > > -- > *Computers: the final frontier. These are the voyages of the user Marc. > His mission: to explore strange new hardware. To seek out new software > and new applications. > To boldly go where no Marc has gone before!* > > > > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- *Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! *
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
