Hi, I use a dynamic DNS, i.e. I want the dhcp-server to update the master's dns-server's records. Then this master updates the slave's records. This worked fine but now the update does not work anymore. I found out when I tried to create a static record. I restarted both the dhcp-server and the dns-servers. On the master I got this message : named[23503]: zone 168.192.in-addr.arpa/IN: journal rollforward failed: journal out of sync with zone named[23503]: zone ace-electronics.be/IN: journal rollforward failed: journal out of sync with zone Actually this is the second time I get this, last time a few months ago. Then I just deleted the journal-files and restarted the dns-server. I could do this again, but I wonder if there's a better way to restore the updates. And important : why would this happen ? Any hints ? Regards, Koenraad Lelong. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Koenraad, Le 13.08.2010 à 13:08, Koenraad Lelong a écrit :
I use a dynamic DNS, i.e. I want the dhcp-server to update the master's dns-server's records. Then this master updates the slave's records. This worked fine but now the update does not work anymore. I found out when I tried to create a static record. I restarted both the dhcp-server and the dns-servers. On the master I got this message : named[23503]: zone 168.192.in-addr.arpa/IN: journal rollforward failed: journal out of sync with zone named[23503]: zone ace-electronics.be/IN: journal rollforward failed: journal out of sync with zone
Actually this is the second time I get this, last time a few months ago. Then I just deleted the journal-files and restarted the dns-server. I could do this again, but I wonder if there's a better way to restore the updates. And important : why would this happen ?
Any hints ?
A mismatch with the journal is inevitable, if you modify the zone files directly. You need to modify the zones through the protocol layer, using the "nsupdate" tool. The nsupdate tool has a very complicated syntax, and 5 years go I wrote a wrapper script that makes it easy to use; should you have a need for frequent modifications, I can provide it. Your other option is to simply modify the zone (file) with an editor, ruthlessly remove the journal files and reload the server. It is useful to flush the journal before doing that ("rcnamed reload" should do it), so the zone files will be in sync with the state cached in memory. If you forget to remove the journal and reload the server, there is a good chance that the name server will silently stop serving the zone later. Which is probably how you ran into the bug, and then you saw the lines in the log. Peter
On 08/18/2010 12:50 PM, Peter Pöml wrote:
Koenraad,
Le 13.08.2010 à 13:08, Koenraad Lelong a écrit :
I use a dynamic DNS, i.e. I want the dhcp-server to update the master's dns-server's records. Then this master updates the slave's records. This worked fine but now the update does not work anymore. I found out when I tried to create a static record. I restarted both the dhcp-server and the dns-servers. On the master I got this message : named[23503]: zone 168.192.in-addr.arpa/IN: journal rollforward failed: journal out of sync with zone named[23503]: zone ace-electronics.be/IN: journal rollforward failed: journal out of sync with zone
Actually this is the second time I get this, last time a few months ago. Then I just deleted the journal-files and restarted the dns-server. I could do this again, but I wonder if there's a better way to restore the updates. And important : why would this happen ?
Any hints ?
A mismatch with the journal is inevitable, if you modify the zone files directly. You need to modify the zones through the protocol layer, using the "nsupdate" tool. The nsupdate tool has a very complicated syntax, and 5 years go I wrote a wrapper script that makes it easy to use; should you have a need for frequent modifications, I can provide it.
Your other option is to simply modify the zone (file) with an editor, ruthlessly remove the journal files and reload the server. It is useful to flush the journal before doing that ("rcnamed reload" should do it), so the zone files will be in sync with the state cached in memory.
If you forget to remove the journal and reload the server, there is a good chance that the name server will silently stop serving the zone later. Which is probably how you ran into the bug, and then you saw the lines in the log.
Peter
So in short-hand (translating) Stop both named servers, then delete the .jnl files from /var/lib/named/dyn and then restart the servers :p Peter, if you still have the wrapper script, I would like to get a copy. I have to update zones about once every six months or so and have to re-learn the nsupdate syntax each time. Having the wrapper script would be nice. If you could post a link I would be grateful. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Peter Pöml schreef: ...
Koenraad,
A mismatch with the journal is inevitable, if you modify the zone files directly. You need to modify the zones through the protocol layer, using the "nsupdate" tool. The nsupdate tool has a very complicated syntax, and 5 years go I wrote a wrapper script that makes it easy to use; should you have a need for frequent modifications, I can provide it.
Your other option is to simply modify the zone (file) with an editor, ruthlessly remove the journal files and reload the server. It is useful to flush the journal before doing that ("rcnamed reload" should do it), so the zone files will be in sync with the state cached in memory.
If you forget to remove the journal and reload the server, there is a good chance that the name server will silently stop serving the zone later. Which is probably how you ran into the bug, and then you saw the lines in the log.
Peter Thanks Peter,
That explains what I'm experiencing. Thinking back, everytime I modified some static routes ("manually", via webmin) this happened. So, yes please I'm interested in that script. I'll also study nsupdate itself. -- Met vriendelijke groeten, Koenraad Lelong -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi David, hi Koenraad, On Wed, Aug 18, 2010 at 01:58:02PM -0500, David C. Rankin wrote:
Peter, if you still have the wrapper script, I would like to get a copy. I have to update zones about once every six months or so and have to re-learn the nsupdate syntax each time. Having the wrapper script would be nice. If you could post a link I would be grateful. Thanks.
On Thu, Aug 19, 2010 at 08:27:41AM +0200, Koenraad Lelong wrote:
So, yes please I'm interested in that script. I'll also study nsupdate itself.
Here's the script attached. I wrote it in 2003-2006. Since then I didn't use it much, only once a year or so, and maybe the last time was in 2008. I hope it still works - but I think it will. You need to create a little conf file containing the filename of a key (e.g. the same as the DHCP server uses): # cat /etc/dnsupdate.conf /etc/Klocalkey.+157+55291.private Called without arguments, the script give some examples how it's used: # dnsupdate Usage examples: dnsupdate add host.domain. 86400 A 10.10.100.230 dnsupdate add 230.100.10.10.in-addr.arpa. 86400 IN PTR host.domain. dnsupdate delete host.domain. dnsupdate delete 230.100.10.10.in-addr.arpa PTR dnsupdate add nickname.domain. 86400 CNAME host.domain. dnsupdate delete nickname.domain. dnsupdate delete domain.tld. 3600 MX 20 mailsrv.domain.tld add -b as first argument to add/delete both forward/reverse mapping. the word 'update' is automatically inserted in the beginning. You usually want to use it with the -b option ("both"), unless you want to manipulate only a forward or reverse mapping, but not both. If you improve the script, I'd be happy to know about it. Thanks, Peter
participants (3)
-
David C. Rankin
-
Koenraad Lelong
-
Peter Pöml