Re: Bind9.3.5 or 6 on ubuntu
On Fri, Jun 26, 2009 at 04:40:48PM -0500, Martin McCormick mar...@dc.cis.okstate.edu wrote a message of 36 lines which said: I read that it is best for them all to be the same version of bind. Strange assertion. this one needs to be like the rest rather than introducing new unknowns in to the system. It seems quite backward. Why not upgrading the FreeBSD machines instead? But anyway, there is no point in the whole question: the set of name servers for a domain can be of many versions of BIND and can also include other, completely different, name servers, such as NSD. Should I be able to find a Debian package of bind9.3.6? Maintained? I doubt it. The configuration for bind9.3.5 has several parameters in it that bind9.5 essentially did not understand: /etc/bind/named.conf.local:8: unknown option 'allow-query' /etc/bind/named.conf.local:38: unknown option 'allow-transfer' /etc/bind/named.conf.local:42: unknown option 'check-names' /etc/bind/named.conf.local:43: unknown option 'check-names' These parameters certainly still exist in 9.5. ___ 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
In message 200906262140.n5qlemev047...@dc.cis.okstate.edu, Martin McCormick w rites: 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. I read that it is best for them all to be the same version of bind. Having different versions really doesn't matter. You have minimum versions for DNSSEC (9.3) and DNSSEC w/ NSEC3 (9.6) but if you are not using DNSSEC there are no problems with have a BIND 4.8 being a slave to a BIND 9.7.0a1 master or vica versa provided your zone content has no errors. You don't want to run BIND 4.8 for other reasons but interop is not one of them. I have been asked to set up a slave DNS on a ubuntu system which happens to be in the correct subnet so this is a good idea, but I want it to be as functionally close as possible to the rest of our DNS's. Eventually, they will all be upgraded to bind9.5, but for now, this one needs to be like the rest rather than introducing new unknowns in to the system. Should I be able to find a Debian package of bind9.3.6? Basically, is there a recommended way to accomplish this without too much extra work? The configuration for bind9.3.5 has several parameters in it that bind9.5 essentially did not understand: /etc/bind/named.conf.local:8: unknown option 'allow-query' /etc/bind/named.conf.local:29: unknown option 'auth-nxdomain' /etc/bind/named.conf.local:30: unknown option 'cleaning-interval' /etc/bind/named.conf.local:31: unknown option 'max-journal-size' /etc/bind/named.conf.local:32: unknown option 'sortlist' /etc/bind/named.conf.local:38: unknown option 'allow-transfer' /etc/bind/named.conf.local:42: unknown option 'check-names' /etc/bind/named.conf.local:43: unknown option 'check-names' BIND 9.5 knows about all of these. I suspect you had them in the wrong place in named.conf. 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
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: Getting dynamic entries into their db files
Hello John. Cherney John-CJC030 wrote: [rndc freeze zone] 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
