filtering results to subnets

[Jerome Haltom]

Well, this was sort of my last resort option. I guess it's where I'll be
heading.

On Sun, 2008-07-20 at 12:24 +0100, Howard Wilkinson wrote:
> Robert Spangler wrote:
> > On Saturday 19 July 2008 20:19, Barry Margolin wrote:
> >
> >   
> >>  In article <g5sup4$2gf7$1 at sf1.isc.org>,
> >>
> >>   Robert Spangler <mlists at zoominternet.net> wrote:
> >>  > On Friday 18 July 2008 22:27, Jerome Haltom wrote:
> >>  > >  I have a desire to filter A records returned to clients that are
> >>  > > outside of certain subnets. Basically my zone has a lot of private
> >>  > > addresses in it. I'm cool with this.
> >>  >
> >>  > How about using the View Option in Bind?
> >>
> >>  Did you read his entire message?  He explained why views doesn't apply:
> >>  he's a slave to a Windows Active Directory.
> >>
> >>  To accomplish this they'd need to use separate zones for the public and
> >>  private hostnames, so that the private stuff could be in an internal
> >>  view.
> >>     
> >
> > Here is the issue, why would you have the slaves doing something different 
> > then the master?  You are just looking for issues.
> >
> > That is like saying if the answers come from server 'A' I want this to be 
> > returned but if the answer comes from server 'B' I want something different.  
> > That is just asking for resolve issues and a troubleshooting nightmare.
> >
> >
> >   
> I have lost the original message but if I remember correctly then a 
> combination of views and some post-processing of the transferred zone 
> file may achieve waht is wanted here.
> The internal view should be a slave of the Windows DNS server and serve 
> out the entire zone as required. A script would then be written to do a 
> zone transfer from the local server and generate a file with the 
> RFC1918(?) addresses removed. This file is then served from another view 
> as a master zone giving the answer required. The major problem with such 
> a scheme is getting a trigger to run the script when an updated zone is 
> transferred. This could be done from CRON by inspecting the serial 
> number on the internal zone and only running the update when it changes. 
> I suggest localhost to localhost transfers so as to not complicate the 
> security settings needed.
> 
> Apologies if this is noise but it is a solution I have used for other 
> similar problems elewhere.
> 
> Howard.
> 
> 
> 
> 
>