[opensuse] Why are nsupdate changes not persistent?
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 example.com, 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 example.com as follows - local_zones.conf - zone "example.com" in { file "/etc/named.d/local/master/example.com"; type master; allow-transfer { none; }; allow-update { key "letsencrypt"; }; }; external_zones.conf - zone "example.com" in { type master; allow-transfer { "aclID"; }; also-notify { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy}; file "/etc/named.d/external/master/example.com"; allow-query { any; }; allow-update { key "letsencrypt"; }; }; internal_zones.conf - zone "example.com" in { file "/etc/named.d/internal/master/example.com"; type master; allow-transfer { none; }; allow-query { any; }; allow-update { key "letsencrypt"; }; }; To test nsupdate I created a file called test.txt shown below, ns1.example.com will access my named service via the external interface -
cat test.txt server ns1.example.com debug yes zone example.com. update add foo.example.com. 86400 TXT "bar" show send
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 ;; ZONE SECTION: ;example.com. IN SOA
;; UPDATE SECTION: foo.example.com. 86400 IN TXT "bar" Sending update to xxx.xxx.xxx.xxxx#53 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 36698 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; ZONE SECTION: ;example.com. IN SOA ;; UPDATE SECTION: foo.example.com. 86400 IN TXT "bar" ;; TSIG PSEUDOSECTION: letsencrypt. 0 ANY TSIG hmac-sha512. REDACTED_KEY 36698 NOERROR 0 Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 36698 ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;example.com. IN SOA ;; TSIG PSEUDOSECTION: letsencrypt. 0 ANY TSIG hmac-sha512. REDACTED_KEY 36698 NOERROR 0 and using dig demonstrates that indeed the new TXT record was added -
dig +short -t txt foo.example.com "bar" "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 example.com -
systemctl restart named.service
dig +short -t txt foo.example.com "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 example.com 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! ;-) 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! * -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 @xxx.xxx.xxx.xxx +short -t txt foo.example.com "bar" "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 @xxx.xxx.xxx.xxx +short -t txt foo.example.com "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.... Marc 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 example.com, 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 example.com as follows -
local_zones.conf -
zone "example.com" in { file "/etc/named.d/local/master/example.com"; type master; allow-transfer { none; }; allow-update { key "letsencrypt"; }; };
external_zones.conf -
zone "example.com" in { type master; allow-transfer { "aclID"; }; also-notify { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy}; file "/etc/named.d/external/master/example.com"; allow-query { any; }; allow-update { key "letsencrypt"; }; };
internal_zones.conf -
zone "example.com" in { file "/etc/named.d/internal/master/example.com"; type master; allow-transfer { none; }; allow-query { any; }; allow-update { key "letsencrypt"; }; };
To test nsupdate I created a file called test.txt shown below, ns1.example.com will access my named service via the external interface -
cat test.txt server ns1.example.com debug yes zone example.com. update add foo.example.com. 86400 TXT "bar" show send
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 ;; ZONE SECTION: ;example.com. IN SOA
;; UPDATE SECTION: foo.example.com. 86400 IN TXT "bar"
Sending update to xxx.xxx.xxx.xxxx#53 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 36698 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; ZONE SECTION: ;example.com. IN SOA
;; UPDATE SECTION: foo.example.com. 86400 IN TXT "bar"
;; TSIG PSEUDOSECTION: letsencrypt. 0 ANY TSIG hmac-sha512. REDACTED_KEY 36698 NOERROR 0
Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 36698 ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;example.com. IN SOA
;; TSIG PSEUDOSECTION: letsencrypt. 0 ANY TSIG hmac-sha512. REDACTED_KEY 36698 NOERROR 0
and using dig demonstrates that indeed the new TXT record was added -
dig +short -t txt foo.example.com "bar" "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 example.com -
systemctl restart named.service dig +short -t txt foo.example.com "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 example.com 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! ;-)
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! * -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 « and », 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 @xxx.xxx.xxx.xxx +short -t txt foo.example.com "bar" "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 @xxx.xxx.xxx.xxx +short -t txt foo.example.com "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....
Marc
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 example.com, 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 example.com as follows -
local_zones.conf -
zone "example.com" in { file "/etc/named.d/local/master/example.com"; type master; allow-transfer { none; }; allow-update { key "letsencrypt"; }; };
external_zones.conf -
zone "example.com" in { type master; allow-transfer { "aclID"; }; also-notify { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy}; file "/etc/named.d/external/master/example.com"; allow-query { any; }; allow-update { key "letsencrypt"; }; };
internal_zones.conf -
zone "example.com" in { file "/etc/named.d/internal/master/example.com"; type master; allow-transfer { none; }; allow-query { any; }; allow-update { key "letsencrypt"; }; };
To test nsupdate I created a file called test.txt shown below, ns1.example.com will access my named service via the external interface -
cat test.txt server ns1.example.com debug yes zone example.com. update add foo.example.com. 86400 TXT "bar" show send
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 ;; ZONE SECTION: ;example.com. IN SOA
;; UPDATE SECTION: foo.example.com. 86400 IN TXT "bar"
Sending update to xxx.xxx.xxx.xxxx#53 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 36698 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; ZONE SECTION: ;example.com. IN SOA
;; UPDATE SECTION: foo.example.com. 86400 IN TXT "bar"
;; TSIG PSEUDOSECTION: letsencrypt. 0 ANY TSIG hmac-sha512. REDACTED_KEY 36698 NOERROR 0
Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 36698 ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;example.com. IN SOA
;; TSIG PSEUDOSECTION: letsencrypt. 0 ANY TSIG hmac-sha512. REDACTED_KEY 36698 NOERROR 0
and using dig demonstrates that indeed the new TXT record was added -
dig +short -t txt foo.example.com "bar" "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 example.com -
systemctl restart named.service dig +short -t txt foo.example.com "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 example.com 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! ;-)
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! * -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin wrote:
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 « and », 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...
Interesting, I would not have imagined rndc to have a need to parse those configs, and even if, to do it differently to named.
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...?
It's been a few years since I've set up a new nameserver, but I can easily imagine your choice of 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?
It doesn't sound like something systemd should be fiddling with at all. I use dynamic DNS from dhcp, bind is bind-9.10.4-P2. There are no journal files, except when I manually updatee and I do a 'rndc freeze'. TMK, named should be picking up and persisting any journals on a restart.
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.
right, dns-01. So you get something from letsencrypt and you need to put it in a zone file. Or even create one? I use http-01, but I have been wondering about moving to dns-01. You are making me curious. : -- Per Jessen, Zürich (10.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
right, dns-01. So you get something from letsencrypt and you need to put it in a zone file. Or even create one? I use http-01, but I have been wondering about moving to dns-01. You are making me curious. :
fwiw - maybe it'll help comparing notes. I set up my name server with a key for access to "example.com". When I run an nsupdate, I see a file named "example.com.jnl" created. When I stop named, I see the zone file was updated, but the jnl file remains. After starting named again, no change, jnl file still there, all is fine. This system is still sysv init, but looking at the start/stop script from leap15, they are the same or very similar. If I do 'rndc freeze', the jnl file is removed. I don't think systemd has any blame here - keep an on your zone files to figure what is happening. -- Per Jessen, Zürich (12.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Per, Thanks for following up and taking a look at this issue. ;-) I set up a test host in one of my zones and used nsupdate to insert a txt record for that host. Monitoring what is happening in the chroot directories where named does it's work. First I set up a small test file to use
# cat test.example.txt debug yes zone example.com. update add test.example.com. 86400 TXT "foobar" show send
Then using nsupdate I add the TXT record "foobar" for test.example.com -
nsupdate -k /etc/letsencrypt/james/Kletsencrypt.+165+56715.key -v ./test.example.txt
dig does show that indeed the TXT record was added and I see that the jnl file - example.com.jnl has been created. However neither of the config files for example.com in /etc/named.d/local/master/example.com or /var/lib/named/etc/named.d/local/master/example.com has been updated yet, as expected...
quasar:/var/lib/named/etc/named.d/local/master # dig +short -t txt test.example.com "bar" "bar" Now for a small segway, if I manually sync the jnl file, i.e. rndc sync I do see that the TXT record is copied into the chrooted version of example.com as can be seen with this copy/past section from example.com -
test A xxx.yyy.zzz.aaa $TTL 86400 ; 1 day TXT "bar" $TTL 172800 ; 2 days However, it still is not persisted into /etc/named.d/local/master/example.com. The jnl file is still in the chrooted directory...
So far so good... Next I stop the named service -
quasar: /etc/named # systemctl stop named.service
And the contents of the chrooted directory is still intact, both the record remains defined and the jnl file exists. But the file at /etc/named.d/local/master/example.com remains unchanged and not updated. When I start up the named service, the entire chrooted directory at /var/lib/named/etc/named.d/local/master is destroyed and then recreated. I was able to determine that this is done by copying the contents of /etc/named.d/local/master into the new chroot directory. Thus the TXT record inserted by nsupdate is lost and the jnl file is destroyed. Therefore I must conclude that either the scripts that stop the named service or the ones that start the named service do not copy the files out of the chrooted directories back into the files at /etc/named.d before the chrooted directory is destroyed. I don't know which step should have this responsibility, but my guess is that the copy back should occur when the named service is stopped. Anywise, this is where a systemd guru is needed, as this is getting above my pay grade... Marc... On 03/15/2019 10:18 AM, Per Jessen wrote:
Per Jessen wrote:
right, dns-01. So you get something from letsencrypt and you need to put it in a zone file. Or even create one? I use http-01, but I have been wondering about moving to dns-01. You are making me curious. : fwiw - maybe it'll help comparing notes.
I set up my name server with a key for access to "example.com". When I run an nsupdate, I see a file named "example.com.jnl" created.
When I stop named, I see the zone file was updated, but the jnl file remains. After starting named again, no change, jnl file still there, all is fine.
This system is still sysv init, but looking at the start/stop script from leap15, they are the same or very similar.
If I do 'rndc freeze', the jnl file is removed.
I don't think systemd has any blame here - keep an on your zone files to figure what is happening.
-- *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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
15.03.2019 23:23, Marc Chamberlin пишет:
Hi Per, Thanks for following up and taking a look at this issue. ;-) I set up a test host in one of my zones and used nsupdate to insert a txt record for that host. Monitoring what is happening in the chroot directories where named does it's work.
First I set up a small test file to use
# cat test.example.txt debug yes zone example.com. update add test.example.com. 86400 TXT "foobar" show send
Then using nsupdate I add the TXT record "foobar" for test.example.com -
nsupdate -k /etc/letsencrypt/james/Kletsencrypt.+165+56715.key -v ./test.example.txt
dig does show that indeed the TXT record was added and I see that the jnl file - example.com.jnl has been created. However neither of the config files for example.com in /etc/named.d/local/master/example.com or /var/lib/named/etc/named.d/local/master/example.com has been updated yet, as expected...
quasar:/var/lib/named/etc/named.d/local/master # dig +short -t txt test.example.com "bar" "bar" Now for a small segway, if I manually sync the jnl file, i.e. rndc sync I do see that the TXT record is copied into the chrooted version of example.com as can be seen with this copy/past section from example.com -
test A xxx.yyy.zzz.aaa $TTL 86400 ; 1 day TXT "bar" $TTL 172800 ; 2 days However, it still is not persisted into /etc/named.d/local/master/example.com. The jnl file is still in the chrooted directory...
So far so good... Next I stop the named service -
quasar: /etc/named # systemctl stop named.service
And the contents of the chrooted directory is still intact, both the record remains defined and the jnl file exists. But the file at /etc/named.d/local/master/example.com remains unchanged and not updated.
When I start up the named service, the entire chrooted directory at /var/lib/named/etc/named.d/local/master is destroyed and then recreated. I was able to determine that this is done by copying the contents of /etc/named.d/local/master into the new chroot directory. Thus the TXT record inserted by nsupdate is lost and the jnl file is destroyed. Therefore I must conclude that either the scripts that stop the named service or the ones that start the named service do not copy the files out of the chrooted directories back into the files at /etc/named.d before the chrooted directory is destroyed. I don't know which step should have this responsibility, but my guess is that the copy back should occur when the named service is stopped. Anywise, this is where a systemd guru is needed, as this is getting above my pay grade...
It has absolutely nothing to do with systemd. systemd service just calls script which is basically the same as in case of sysvinit. It is this script that re-creates chroot environment and any copyback should happen in this script also. This script is not part of upstream distribution. Open bug report in openSUSE bugzilla. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin wrote:
dig does show that indeed the TXT record was added and I see that the jnl file - example.com.jnl has been created. However neither of the config files for example.com in /etc/named.d/local/master/example.com or /var/lib/named/etc/named.d/local/master/example.com has been updated yet, as expected...
Ah. No, those configs should not be updated. The zone files in /var/lib/named/ are what matters: nameserver:/var/lib/named/master # l example* -rw-r--r-- 1 named named 11891 2019-03-15 18:05 example.com -rw-r--r-- 1 named named 732 2019-03-16 08:52 example.com.jnl (I've just now added a txt record, hence the 0852 timestamp on the journal).
However, it still is not persisted into /etc/named.d/local/master/example.com. The jnl file is still in the chrooted directory...
Aha, now I see what is happening. You have put your zone file in file "/etc/named.d/external/master/example.com"; That won't work, at least not with the current init-scripts supplied by openSUSE. I suggest you use "/var/lib/named/master/example.com" instead. config and data are kept separately - in /etc/named.{d/,conf} and in /var/lib/named/, respectively. The config is copied into the chroot dir, but the data is kept/maintained in /var/lib/named/. In your zonefile config, just use something like this: zone "example.com" { type master; ------> file "master/example.com"; forwarders { }; notify yes; etc etc -- Per Jessen, Zürich (12.1°C) member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Per - Well you hit the nail on the head, many thanks for your help! Moving the zone files over to /var/lib/named solved the persistence problem. I guess that wasn't clear to me but now that I think about it, makes sense since named is running in a chrooted jail and it cannot follow links out of there. (I actually had to create 3 new "master" directories, one for each view, but that wasn't a big hurdle..) This didn't solve my troubles I am having with LetsEncrypt certificates but at least I know this persistence issue isn't getting in my way... Marc... On 03/16/2019 01:07 AM, Per Jessen wrote:
Marc Chamberlin wrote:
dig does show that indeed the TXT record was added and I see that the jnl file - example.com.jnl has been created. However neither of the config files for example.com in /etc/named.d/local/master/example.com or /var/lib/named/etc/named.d/local/master/example.com has been updated yet, as expected... Ah. No, those configs should not be updated. The zone files in /var/lib/named/ are what matters:
nameserver:/var/lib/named/master # l example* -rw-r--r-- 1 named named 11891 2019-03-15 18:05 example.com -rw-r--r-- 1 named named 732 2019-03-16 08:52 example.com.jnl
(I've just now added a txt record, hence the 0852 timestamp on the journal).
However, it still is not persisted into /etc/named.d/local/master/example.com. The jnl file is still in the chrooted directory... Aha, now I see what is happening.
You have put your zone file in
file "/etc/named.d/external/master/example.com";
That won't work, at least not with the current init-scripts supplied by openSUSE.
I suggest you use "/var/lib/named/master/example.com" instead.
config and data are kept separately - in /etc/named.{d/,conf} and in /var/lib/named/, respectively. The config is copied into the chroot dir, but the data is kept/maintained in /var/lib/named/. In your zonefile config, just use something like this:
zone "example.com" { type master; ------> file "master/example.com"; forwarders { }; notify yes; etc etc
-- *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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin wrote:
Hi Per - Well you hit the nail on the head, many thanks for your help!
Marc, my pleasure! Two pairs of eyes will always beat one pair :-)
Moving the zone files over to /var/lib/named solved the persistence problem. I guess that wasn't clear to me but now that I think about it, makes sense since named is running in a chrooted jail and it cannot follow links out of there. (I actually had to create 3 new "master" directories, one for each view, but that wasn't a big hurdle..)
I also have two views, but I keep all the zone files in one place.
This didn't solve my troubles I am having with LetsEncrypt certificates but at least I know this persistence issue isn't getting in my way...
I'm using http-01 which works very well, but I have been contemplaing trying out dns-01 too. -- Per Jessen, Zürich (11.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen you scalawag!!! ;-) I found the solution to my LetsEncrypt issue and why the DNS-O1 challenge wasn't working for me. Turns out I found it in a thread from way back in 2006 that you had participated in! - https://lists.isc.org/pipermail/bind-users/2006-January/061063.html Talk about another poorly documented feature of bind, with no examples to help a poor soul out! But using the key itself, as a way to control matches for a view, is the solution. This way one is able to force bind to only allow certbot challenges for LetsEncrypt certificates to use a particular (external) view and not other inappropriate local or internal views! So in both of my localhost_resolver and my internal views I used the following statements - view "localhost_resolver" { match-clients { ! key letsencrypt.; localhost; }; match-destinations { ! key letsencrypt.; localhost; }; ... and view "internal" { // What the home network will see match-clients { ! key letsencrypt.; localnets; localhost; }; match-destinations { ! key letsencrypt.; localnets; localhost; }; ... Works like a charm! Many many thanks again for your help, from a long long time ago, though I don't think you realized how helpful you already were or knew that distance future bodies would be indebted to your trailblazing efforts... Marc.. On 03/16/2019 12:18 PM, Per Jessen wrote:
Marc Chamberlin wrote:
Hi Per - Well you hit the nail on the head, many thanks for your help! Marc, my pleasure! Two pairs of eyes will always beat one pair :-)
Moving the zone files over to /var/lib/named solved the persistence problem. I guess that wasn't clear to me but now that I think about it, makes sense since named is running in a chrooted jail and it cannot follow links out of there. (I actually had to create 3 new "master" directories, one for each view, but that wasn't a big hurdle..) I also have two views, but I keep all the zone files in one place.
This didn't solve my troubles I am having with LetsEncrypt certificates but at least I know this persistence issue isn't getting in my way... I'm using http-01 which works very well, but I have been contemplaing trying out dns-01 too.
-- *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@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin wrote:
Works like a charm! Many many thanks again for your help, from a long long time ago, though I don't think you realized how helpful you already were or knew that distance future bodies would be indebted to your trailblazing efforts...
Wow, 13 years ago. Haha, the internet may forgive, but it never forgets :-) -- Per Jessen, Zürich (3.9°C) member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019-03-10 5:08 p.m., 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.
Maybe I'm naive and simplistic but isn't nsupdate a "Dynamic DNS update utility" and the changes are not meant to persist? As I understand it there is a mechanism whereby a separate DHCP server can tell the DNS server about requests it has fulfilled and add or remove appropriate entries for the dynamically assigned addresses. Since I use dnsmasq this isn't a problem for me. It is a very capable 'all-in-one' package. Since it does both DNS and DHCP it 'knows' what addresses it has issued and so can effortless create the and remove the dynamic dns entries. I can see a problem when you don't have the all-in-one. If the DHCP server issues the update but the DNS server later does and looses that information but then restarts then there is a host with a dynamically assigned for whom the dynamic DNS information is lost. Perhaps that is a 'well don't do that' reason to use dnsmasq. When it goes down the assignment of the address and the DNS record are both lost. It comes back up and 'orphaned' host requests and is given a new address and the appropriate DNS record created. No 'dangling' stuff. I looked at the complexity and failure modes associated with separate DHCP and DNS and the messaging and cryptology and decided that a minimalist of dnsmasq was going to more functional in my system. Nevertheless, you pose an interesting set of conundrums in this thread and I'm bookmarking it. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov
-
Anton Aylward
-
Marc Chamberlin
-
Per Jessen