Local rpz ban list format

Mark Abram marek.w.abram at gmail.com
Sun Apr 11 23:17:35 UTC 2021


      
Thank you Paul for taking the time and explaining in more details. I have learned few things tfrom you today.
  
​Much appreciated.
  
​
  
  
  
Mark
  
  
  
On Apr 11 2021, at 5:05 pm, Paul Vixie  <paul at redbarn.org>  wrote:
  
>   
>   
> On Sun, Apr 11, 2021 at 03:28:54PM -0600, Mark Abram via Unbound-users wrote:
>   
> >  What Paul has suggested works in unbound. But what I am not sure
>   
> >  about why I need to specify any sort of TTL values
>   
>   
> one of the most controversial parts of the RPZ design was the use of DNS
>   
> zone files to convey recursive server policy. this kind of overloading is
>   
> often a sign of ignorance or bad taste. for example, using "CNAME ." as a
>   
> way to signal that the owner name should trigger an artificial NXDOMAIN
>   
> response (without regard for the authoritative truth of that matter) is,
>   
> no matter how you look at it, pretty ugly.
>   
>   
> we (the RPZ designers; vernon schryver and myself) had no use for TTL,
>   
> and so it doesn't matter to us what value you use. since the zone is
>   
> not going to be "served," the value makes no difference to Unbound (or
>   
> BIND, or Knot, or PowerDNS, all of which now support RPZ). so, letting
>   
> the TTL be the minimum (last of the five numbers in the SOA record) is
>   
> absolutely harmless and arguably the most correct.
>   
>   
> >  for a local rpz file I manage to ban permanently some bad hosts. I want
>   
> >  indefinite TTL for banned hosts. Maybe I am not understanding it completely
>   
> >  but with Pauls suggested header values it works and blocks my hosts.
>   
>   
> TTL has no role in RPZ. but it must be present because RPZ uses DNS zones
>   
> to convey DNS recursion policy. so, use any value you please, because
>   
> nothing will see it except you when editing your "zone file".
>   
>   
> we overloaded the DNS "zone" mechanism to carry recursive DNS policy because
>   
> it was a format that the servers already understood, and a relied on a set
>   
> of firewall rules that DNS operators already understood.
>   
>   
> --
>   
> Paul Vixie
>   
>   
     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20210411/c1ea91c8/attachment-0001.htm>


More information about the Unbound-users mailing list