Blocking private addresses with a optionq

[Lawrence K. Chen, P.Eng.]

----- Original Message -----
> On Mar 14, 2013, at 3:29 AM, Tony Finch wrote:
> 
> > King, Harold Clyde (Hal) <hck at utk.edu> wrote:
> > 
> >> Is there an option for bind like the allow-recursion {
> >> <network-acl> }
> >> For blocking out going records of 10.0.0.0/8 and 192.168.0.0/16 so
> >> I could do a view like:
> > 
> > I'm not sure what you mean by "blocking out going records" but
> > there are a
> > couple of options that might do what you want:
> > 
> > There is the "blackhole" acl which makes named ignore all requests
> > and
> > never send queries to a particular address range.
> > 
> > There is the server ... { bogus yes; }; clause which stops named
> > from
> > sending queries to a particular address range.
> 
> No, I'm pretty sure the OP wants to strip records from responses if
> the records are A records referring to private address space (RFC
> 1918).
> 
> I've no idea how you would do this.
> 

This actually sounds like something I might want to do....

We do have RFC1918 addresses in use.  And, I've heard of people abusing IPv6 since its currently blocked at the border.  Plus people publishing DNS64 addresses for their hosts.

While I run the authoritative servers here, and do split horizon.  So, I try to keep the RFC1918 addresses out of the external view.  Either by refusing the add/change request, or for certain groups do selective $INCLUDE and other trickery.  Though someday I should audit the existing zone data.

And we shouldn't be leaking those IPs anymore. :)

But, there are groups on campus that run their own master server for their 3rd level domains (i.e. the college engineering has most of the engineering related 3rd level domains).  So, my authoritative servers are only slaves and possibly the only ones that can be reached from the outside.  So, being able to filter out these 'bad' things when responding queries against that data might be a good thing.

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkchen at ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library