Re: Getting dynamic entries into their db files
Hello John. Cherney John-CJC030 wrote: [rndc freeze ] > Thanks! I hadn't tried that. I have a problem with that, though. I don't > know which of my ~600 zones will or won't have dynamic updates. Well, if there is a .jnl file for a zone, it needs to be flushed. A bit of shell scripting can generate the rndc freeze and thaw commands. Dynamic updates issued while a zone is frozen will be lost, unless the updating application handles the error and retries often enough. So you probably don't want to freeze zones too long. > It > doesn't appear that there is a way to do an rndc freeze on all of my > zones at once, or pass a wildcard in as the zone name. Indeed. I don't know a way to force BIND to write out all zone files without interrupting normal service. Maybe the folks on bind-users know more. AFAIK, the nearest you can get is to set "flush-zones-on-shutdown" and restart the nameserver: | flush-zones-on-shutdown | When the nameserver exits due receiving SIGTERM, flush or | do not flush any pending zone writes. | The default is flush-zones-on-shutdown no. Also keep in mind that flushing the journal removes IXFR availability up to the current serial number, although this point shouldn't matter much if all slaves are already in sync. I agree with Mark, though, that static backups of dynamic zones are often useless, except for emergencies where all authoritative servers lost the zone. If you restore zones and journals from backup, you lose changes from the timeframe between the snapshot and restoration and need to force a retransfer on all slave servers or manually increase the serial number. It's probably better to sync the current zone from a secondary server before re-enabling dynamic updates. Hauke. signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting dynamic entries into their db files
Mark Andrews writes: > Have you really thought about this? The correct way to > backup the DNS is to use slaves. If all is going well you > will only loose a minute or two of changes. You really > don't want to roll back to what is in backup tapes. At our site, I administer several FreeBSD and Linux boxes. Several of the FreeBSD boxes run slaves for the express purpose of disaster recovery. If you make sure that all the zone files' names for your slaves exactly match the files used for the master zones, you can promote one of the slaves to be a master providing you save your master DNS's configuration files on the slaves, maybe in a tar ball that you refresh each day via cron. Your tar ball needs to not overwrite the actual zone data as this would totally defeat the purpose, but it does need to overwrite the present named configuration so as to be come the new master. What you do about coming up on your master's address is totally up to you, but you could use a virtual interface if the slave is on the same subnet as was the master, or you could conceivably reconfigure the interface temporarily if possible, but the object is to have a presence on the IP address of your master so you can resume dynamic control. We actually did loose our master one evening as all were going home for the day. The FreeBSD box that was our master had the OS on one drive and /var on another. The boot drive died so bind actually continued to work but we had no control any longer. In order to bring the new slave up to master status, we had to physically disconnect the Ethernet interface of the master. The slave promotion worked except I discovered the value of checking all file names before hand. One was wrong and, well, that's another war story. The main thing is that each slave is a perfect backup for your whole operation. It takes very little effort to set them up and almost no maintenance afterwards. They just run themselves quite nicely. Martin McCormick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9.3.5 or 6 on ubuntu
I wrote: > The present package for bind under ubuntu Linux is > bind9.5. This is great and I am not complaining at all but all > the rest of our bind servers are FreeBSD and using 9.3.5, soon > to be 9.3.6. Make that 9.5 now. I failed to catch that 9.3x had died at the end of December. I installed 9.5 on a FreeBSD6.3 system and it reports that it is running and all the logs look quite normal except for this 1 entry: Jun 27 07:42:50 dc named[21227]: errno2result.c:111: unexpected error: Jun 27 07:42:50 dc named[21227]: unable to convert errno to isc_result: 45: Operation not supported How serious is this? What likely isn't working as things look quite normal on this test system? rndc works and the status shows exactly the same output I used to see in 9.3.6. Thanks. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Telecommunications Services Group ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
