Additional info:
>First thought...and it's probably not related to the problem you're
>having...if you're using "match-clients" to limit what IP blocks
>can do lookups, what's with the "allow-query" line?
The allow-query is a left over from before implementing split DNS, so its
superfluous, but does no harm.
>Second thought, more likely related...and I can't tell, based on the
>snippet you presented...Are you listing all the private zones *inside* the
>"view "private" {" stanza, and all of the public zones *inside* the "view
>"public {" stanza?
The named.conf is almost 1000 lines long so I trimmed it. All the publics
are inside one public stanza and all the privates are inside one private
stanza.
>According to the named.conf docs... The notify parameter should be either
>yes or no. Do you see any errors logged when named starts?
The notify explicit & also-notify are perfectly legit. There are no errors
in /var/log/messages or /var/log/named. Both servers come up clean as a
whistle.
>If 192.168.168.146 is a listed name server (NS) within the zone, the
>also-notify is really not needed.
Its a long story, but without the notify as I've done it. the secondary
server doesn't get updated properly. I don't recall the exact nature of the
anomaly now, but its a sneaky issue that I stumbled on by noticing that the
secondary wasn't getting some of the zones. Its a catch 22 situation using
the older nomenclature. That's one of the reasons they came up with the new
options.
The box 192.168.168.146 is NS1 and .144 is NS2.
>I take it you have previously defined an ACL named internals??
All the other parts are there from the time before I split the DNS into
public and private views.
I can't figure out how data that resides only in the private files is
leaking over into the public DNS. I programmatically (grep) checked all the
public files and none of them contain any private IP addresses. Similarly,
none of the private files contains any public IP addresses. But somehow,
data that resides in a private file is leaking over to the public view of
the world.
The fact that on the secondary all the private files and public files are
identical, and contain only private IP addresses has got to have something
to do with this. NS1 is hosed up somehow and then it transmits trash to NS2.
I just don't see it, but I'm beginning to suspect that the name space
elements inside a "view" aren't hidden from the other view.
BTW - The reason I chose not to put the public files in one subdirectory and
the privates in another was due to scripts I've written expecting all the
zone files to exist in one place. I'm going to update those scripts to use
subdirectories if I decide to stay with BIND, which is more and more
doubtful. The scripts do sanity checking on zones so its impossible to put
private addresses into public zones and vice versa, as well as all forward
references produce their reverse entries automatically, and name collisions
are avoided.
--
Bill Gradwohl
YCC
(817) 224-9400 x211
www.ycc.com
SPAMstomper Protected E-mail
www.stomperware.com
--
Shrike-list mailing list
Shrike-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/shrike-list
