Blocking private addresses with a optionq

[Lawrence K. Chen, P.Eng.]

----- Original Message -----
> > From: "Lawrence K. Chen, P.Eng." <lkchen at ksu.edu>
> 
> > ... So, being able to filter out these 'bad' things when responding
> > queries against that data might be a good thing.
> 
> RPZ might be used for such things.  However, by design RPZ rewrites
> entire responses.  It is triggered by individual records in a
> response,
> but changes the entire response and not just individual records
> within
> the response.
> 
> To use RPZ for such filtering, you would probably use views with
> a response-policy{} statement in the external view to be filtered.
> 
> The RPZ rules could be triggered by rpz-ip records for 10.0.0.0/8 or
> similar.  The rules might rewrite responses to a CNAME or to sets of
> A and AAAA records suitable for outsiders.  That sounds a lot more
> fragile and error prone than distinct zones for insiders and
> outsiders
> specified in the view statements.  However, RPZ might be good as a
> failsafe against leaks (perhaps rewriting to NXDOMAIN).
> 
> 
> Vernon Schryver    vjs at rhyolite.com
> 

Since this problem has started increasing again, I went to look to see how to use RPZ....

First thing that got my attention was that "The rules encoded in a response policy zone (RPZ) are applied only to responses to queries that ask for recursion".  But, these are authoritative only nameservers....   So, would RPZ work in this case?

-- 
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