rndc and nsupdate failing to work for me
Marc Chamberlin
marc at marcchamberlin.com
Thu Mar 14 05:17:02 UTC 2019
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-bounces at lists.isc.org] *On Behalf
> Of *Marc Chamberlin via bind-users
> *Sent:* Wednesday, March 13, 2019 6:02 PM
> *To:* bind-users at 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 at 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!
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190313/4d4a7a2f/attachment-0001.html>
More information about the bind-users
mailing list