Shumon Huque wrote:
> On Tue, Mar 28, 2017 at 12:20 PM, Paul Vixie <p...@redbarn.org
> ...
>
> speaking of resimprove, i hope you'll include in this draft the idea of
> using delegation-TTL as a delegation-recheck interval, and using an
> authoritative NXDOMAIN from the delegator as proof that you need to run
> an "rm -rf" in your cache.
>
> i bring this up because we need to be able to kill more cached data
> faster-- the opposite of stretchiness-- for abuse control reasons. if
> you're going to soften the signaling for cache expiration, you really
> ought to balance that out with this simple method of also hardening it.
>
> Perhaps you've forgotten (since you participated in the discussions), but
> the portion of resimprove that dealt with expunging cached data below the
> NXDOMAIN boundary was rescued, expanded on, and published as
> RFC 8020 ("NXDOMAIN: There Really is Nothing Underneath") late last
> year.
yes, i know that RFC 8020 includes both the idea of stopping downward
searches when a cached NXD is encountered, and the idea of pruning (like
"rm -rf" in UNIX) existing cache entries when an NXD is received. those
changes, in addition to QM, will do much to pacify the DNS data model.
however, it's equally vital for malicious DNS content takedown, that the
part about remembering the delegation NS TTL and using it to
periodically revalidate the existence of that delegation, also be
brought forward. this becomes even more vital if we're making TTL
stretchy, and i would be happy to see tale's document cover this topic.
in other words, the prune-and-stop on NXD must be given a new source of
NXD, which is delegation revalidation. i'd love it if delegations all
had a one hour or less TTL, at least for public suffixes.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
