[RPZ] DNSRPZ TTL Feature

[nudge]

Hi Vernon

On Fri, Apr 19, 2013, Vernon Schryver wrote:
> (about very low TTLs considered evil)
> 
> Can a recursive server receive a record with a low TTL when
> the nominal authority is really a slave to a stealth master?

pass

> > More privacy than security, but of course it depends where you draw that
> > line. 
> 
> I think the distinction between security and privacy is clear,
> although the same data can raise both kinds of issues.

Maybe you could help the IETF-privacy working group ;)

> 
> >       I've noted some instances where TTLs are purposely kept low
> > apparently for tracking or statistical purposes.
> 
> I don't think the use of small TTLs for fast flux can be excused
> for on either "tracking" or "statistical" grounds.
> I think I've heard of still other reasons for tiny TTLs that
> are none of the above.
> 
> An RPZ trigger for small TTLs does not make sense to me, because
> no reasonable person would say "All RRs with TTLs smaller than X
> are all evil until further notice."  On the other hand, RPZ name
> and IP triggers have a reasonable person maintaining a response
> policy zone saying "This name or IP address is evil."

Sorry, I never intended that. I was thinking of a situation where
clients of a (closed) recursive server make the same query every minute
for say an A record that very rarely changes but has a TTL of 60. I
could pirate that with RPZ by providing the same A response but with a
more reasonable TTL, if I considered that necessary. But I would also
need to ensure that I updated my RPZ zone if the A record in the
original un-pirated zone changes. Doing so in a timely manor could get
messy. So I thought it'd be useful if RPZ allowed my recursive server to
query the authoritative server and then simply adjusted the TTL to match
my local TTL policy for this particular preconfigured case without
changing the rest of the response and without the need for any parallel
processes.

I wasn't suggesting a (controversial) minimun-ttl feature for all
queries that I suspect content delivery providers in particular would
hate.

Thanks,

Ian