"rndc showzone" only works if you also have "allow-new-zones yes;” set.
The last time there was a complaint about UPDATE’s not sticking the
startup procedure was wiping out the changes.
Mark
> On 14 Mar 2019, at 10:01 am, Marc Chamberlin via bind-users
> <bind-users@lists.isc.org> wrote:
>
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
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
