Mailinglist Archive: opensuse (389 mails)

< Previous Next >
Re: [opensuse] Why are nsupdate changes not persistent?
I know/understand it is a bad sign if no one is replying to a query like
mine, probably means know one knows an answer or has any ideas...
But I was pointed back to OpenSuSE, so will report where I am and what I
have found out...

First of all I did track down a very nasty little issue that really cost
me a lot of time and grief!  The named.conf file that came supplied from
the distro, to be used as a starting example for configuring bind, has a
gotcha in it. There are two views defined called internal and external
(also a localhost.resolver) The quotes that surround the "external" and
"internal" parameters are the ISO version of quotes &laquo; and &raquo;,
not the ASCII version. Very difficult to spot and I cannot really
produce the ISO versions cuz my keyboard doesn't have a key to produce
them. Anywise, named.d is perfectly happy to use either form of quotes,
but tools like rndc choke on the ISO version of quotes. rndc kept
complaining that there was not such view as internal or external even
though my eyes were telling me that there darn well were such views
defined...  Wanna know what choice words I used when I finally
discovered this lil feature? (BTW fixing the quotes also fixed the
problem with rndc sync -clean that I reported earlier.)

Another bit of wizardry I learned about rndc is if you want to use it to
show the contents of a zone - i.e.

#rndc showzone

It only works if you also have "allow-new-zones yes;” set in the options
clause of named.conf. Go figure! I can't find that bit of magic
documented anywhere and it would be nice to include a comment and
example in the options clause of the distro's supplied named.conf file.
Wanna know what choice words...?

The folks over on the bind users forum have pointed me back here in
regards to the persistent problems that I reported, when using nsupdate.
Their thinking is that the systemctl stop and start (or restart) process
for named.d is not copying the data out of the named journal files back
into the config files. Any systemd gurus out there want to help me track
this down or should I simply submit a bug report based on hearsay evidence?

I don't know if this issue with nsupdate persistence is what is causing
the failure I really want to solve, I am trying to validate LetsEncrypt
certificates using Bind to authenticate domain ownership, which I
haven't got working yet either. It doesn't seem likely, but I went down
this rabbit hole while trying to test/pursue my ideas/issues with
LetsEncrypt.. Let me know if anyone wants to help pursue this nsupdate
persistence issue and I will be glad to lend what assistance I can,
otherwise I am going to go back to poking at LetsEncrypt/Bind and see if
I can learn anything more about why their validation process is failing
on my server...

     Marc in Wonderland...

On 03/10/2019 03:42 PM, Marc Chamberlin wrote:
As a followup I explored using rndc sync to try and force persisting the
update data from the journal to the master files. Didn't work but got a
bit of a surprising response....

dig +short -t txt "bar"

Then -

rndc sync -clean
rndc: 'sync' failed: not found
no matching zone '-clean' in any view

HUH???  WTF? I dunno why it is looking for a zone called "-clean",
something is wacko, according the the man pages that is a legitimate
command! Well to heck with trying to remove the journal -

rndc sync
systemctl restart named.service
dig +short -t txt "bar"

And still no joy, so even rndc sync failed to persist the updated
info....  I'm lost, going back to poking around some more while awaiting
for some sage to advise me....


On 03/10/2019 02:08 PM, Marc Chamberlin wrote:
Hi - This has been a difficult journey but I believe I have now
configured my bind (named) service to accept updates using nsupdate to
one of my zones. It seems to be working but when I restart the
named.service the updates I made using nsupdate do not persist. I will
try to show as much info as I can and hopefully some nice guru will tell
me what I need to do to get these changes to persist (sensitive info
redacted of course). I am running under OpenSuSE Leap 15.0  My named
service is configured to run split brained with 3 views -
localhost.resolver, internal, and external. I have a zone for, defined in all 3 views.

This first thing I did was create a new TSIG (Transaction SIGnature) key -

cd /etc/letsencrypt
dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST letsencrypt

Next I extracted the key from the created .key file and added a key
definition in named.conf -

key "letsencrypt" {
  algorithm hmac-sha512;
  secret "xxxxxxxxxxxxxxxxxxxxxxxxxxx...";

In each of the zone configuration files I set up the zone for as follows -

local_zones.conf -

zone "" in {
    file "/etc/named.d/local/master/";
    type master;
    allow-transfer { none; };
        allow-update {
           key "letsencrypt";

external_zones.conf -

zone "" in {   
    type master;
    allow-transfer { "aclID"; };
    also-notify {;  yyy.yyy.yyy.yyy};
        file "/etc/named.d/external/master/";
        allow-query { any; };
        allow-update {
           key "letsencrypt";

internal_zones.conf -

zone "" in {
    file "/etc/named.d/internal/master/";
    type master;
    allow-transfer { none; };
        allow-query { any; };
        allow-update {
           key "letsencrypt";

To test nsupdate I created a file called test.txt shown below, will access my named service via the external interface -

cat test.txt
debug yes
update add 86400 TXT "bar"

With this setup I tested the update process as follows -

systemctl restart named.service
nsupdate -k /etc/letsencrypt/Kletsencrypt.+165+56715.key -v ./test.txt
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;          IN      SOA

;; UPDATE SECTION: 86400 IN      TXT     "bar"

Sending update to
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  36698
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;          IN      SOA

;; UPDATE SECTION: 86400 IN      TXT     "bar"

letsencrypt.            0       ANY     TSIG    hmac-sha512.

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  36698
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;          IN      SOA

letsencrypt.            0       ANY     TSIG    hmac-sha512.

and using dig demonstrates that indeed the new TXT record was added -

dig +short -t txt "bar"

So I know that at least the update was recorded in the bind journal
file. But if/when I restart the named.service I discover that the update
was not persisted back into the configuration for -

systemctl restart named.service
dig +short -t txt "bar"
Dig returns nothing, nada...  I don't think it is a permissions issue
that is causing the failure to persist the update either, all the
/etc/named.d files and subdirectories have ownership set to "root:named"
and both "root" and the group "named" have rw permissions. The
named.service is running under the system user - "named" and that system
user belongs in the system group "named". I am not finding anything in
the log files either that gives me a clue as to why the persistence is
not occurring but I suspect there is something going on when the
named.service is stopped causing it's journal to not be written back
into the domain configuration files. I am by no means an
expert on systemd and reached the limits of my ability to grok why
nsupdate changes are not being persisted. Any kind suggestions from the
gurus will be much appreciated! ;-)


*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!

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups