This unfortunately looks like the thread for me to jump on to....
I missed installing the last two 9.9...-p# patches, first time I built
everything and was pretty much ready to do it, and then forgot all about it
due to health issues. More recent one...I had got it built for Solaris x64
and was about to work on building it for Solaris SPARC when the most recent
one appeared. This one carried a much strong get things patched (to me at
first, then higher ups started jumping around...)
But, it turned out to be a huge mess to upgrade.
The first time I ran into this error, were some really old mistakes where the
admin had copy and pasted a bunch of similar zones...and missed adjusting
some of the files. Since on the master side they all come from the same
file....it probably didn't cause any noticeable problems for the slaves or
clients.
However, install upgrade on our master server...knocked it out, so I'm here
looking to see what the proper fix for my situation is. Looking for a valid
easy fix here ;) Partly because coming soon they're going to demolish the
DNS infrastructure that I got saddled with and feel like I done a pretty good
job at re-engineering it to meet all the demands of it. But, I'm the last
legacy unix systems administrator here....
Anyways...the problem is because we had turned out existing master server
into doing split/stealth (started out stealth...) DNS, while having it
continue to serve as slave to delegated subdomains. So that those subdomains
are propagated to our external facing slave servers.
So that's where the problem comes in....the internal authoritative+
nameservers having the master collect secondary zone data from them...on the
Internal view. But, then having to send that information to nameservers that
hit the external view of the master.
So, until a few hours ago....it was include a file containing all the
delegated (sub)domains into both views....causing both sides to be working
off of the same file.
WHich seemed to work fine. As only one side is getting updates, the other
side is just to feed our outside facing slaves. Well, this update wouldn't
go for that.
So, cloning the file and doing a global search and destroy....the external
view is looking zone files in a directory that is emtpy, while the internal
side continus as is.
To have something for the external nameservers to transfer (hopefully), I'm
doing a regular sync of the file 'sec' to 'ext'.
Not totally sure that's working....but nothing filing up logs about it.
So, is what I did something that'll hold...or is there an easy proper
solution to this? To hold us/me over until they decide if its going to be
BlueCat or Infoblox that replaces everything.
Sadly, I missed both presentations due to other issues....more sad because I
found my "named.iner" shirt, which I was going to wear to the second
presentation ;)
There were a couple of other interruptions in my upgrading my 20 servers, but
I don't recall what the issue was with those now.
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
On 2015-08-03 10:06, Reindl Harald wrote:
Am 03.08.2015 um 16:59 schrieb Anand Buddhdev:
On 03/08/15 16:50, Heiko Richter wrote:
Hi Heiko,
Why use the "file" option at all on a slave?
If you don't use the "file" option on a slave, then BIND does not write
the zone to disk. This is okay for a small number of small zones. But if
you have many zones, or they are large, then you usually want to save a
copy of the zone to disk, so that at restart, BIND can load the zones in
quickly
and load them at all in a acceptable timeframe
if it doesn ot save them to disk as you said and you have some hundret zones
you likely exceed transfer ratelimits and it takes unacceptable long until
you slave responds while clients already ask him
the next problem with not having them on disk is: god beware if your master
is down and due analyzes or before you recognize the problem you restart
your slave named or the server
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
