On Mon, Aug 03, 2015 at 10:36:25PM -0500, Lawrence K. Chen, P.Eng. wrote: > 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
I hope you're well now. > 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...) It's good that you have deployed the fix for CVE-2015-5477. Those who are ignorant or foolish would say this shows the problems with free software. But that's opposed to the truth: these security reports are the strength of free software. Anyone can hack at it looking for bugs. And then those bugs get fixed. Who knows what bugs lurk inside black-box proprietary solutions? Worse, who knows if they'd be fixed? Security is in openness, standing up to the light of scrutiny. > 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. This seems to be a bug fix (not allowing named to share writeable files) which has brought a lot of broken configurations out. Oops. Basically, no two slave zones (even nominally the same zone, in a different view) should EVER share the same file. Master zones can get away with file sharing, but ONLY if named does not write to the file (no allow-update, update-policy, nor auto-dnssec.) > 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.... Sad. There's nothing "legacy" about Unix, though. Sounds like the salesmen are winning out over the technicians, in terms of getting management to set policy. > 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. The way to select a different view on the master is to use TSIG keys. https://kb.isc.org/article/AA-00295/ > 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. It would require some reworking of things, but you might be interested in the new BIND 9.10 feature of "in-view" zone option. This lets you literally include a zone from another view. See BIND 9 ARM chapter 6, "zone Statement Definition and Usage", for details. > 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? Slave zones should be transferred using DNS. In a stealth master case, you need to populate also-notify lists, but perhaps in your case you can share some of that configuration with global or view level settings. (Better than having to set everything per zone.) > To hold us/me over until they decide if its going to be > BlueCat or Infoblox that replaces everything. IIUC both of those are BIND under the hood. :) > 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 ;) Haha, I have one of those also. Really cool. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: _______________________________________________ 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
