On Wed, Mar 29, 2017 at 2:10 PM, Paul Vixie <p...@redbarn.org> wrote:
>
>
> 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.
>
Yes, I forgot to comment on that piece in the previous email. I agree
that delegation revalidation should be published also. Among other things,
I think it effectively solves the ghost domain problem that was discussed
during the last IETF and DNS-OARC.
--
Shumon Huque
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
