Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)

[Paul Vixie <[e-mail]>]

Evan Hunt wrote:
> On Thu, Sep 07, 2017 at 10:28:30PM -0700, Paul Vixie wrote:
>> if they really need this, they should provide a method by which i can specify
>> both a TTL and an Expiry, and i will consider publishing both values, and
>> if i do, then they can use them the way i intend them. because as i said,
>> autonomy.  it's my data, and my TTL.
>
> I agree, and yet, a DDoS can make your data unavailable for refresh
> through no fault of yours, which makes a resolver operator appear to be
> broken through no fault of theirs, which makes them want very much to
> be able to do this bad thing.

understood. this is the same reasoning that led comcast to argue for the 
ability to turn off dnssec for important zones (like jpl.nasa.gov) who 
had fubar'd their keys and/or signatures and/or delegated signers.

> So, TTL stretching goes on the pile with NXDOMAIN redirection, tools that
> can be used for censorship, and all the other regrettable things that we
> implemented anyway dammit.

not so fast. nxdomain redirection is an attack. censorship is an attack. 
i don't think you mean to group ttl stretching in with those attacks. 
because if you do, then we agree, it is an attack, and ought not be 
done, and certainly ought not be standardized in any form.

> (I do like the idea of advertising a separate expiry value though.)

i think if we're going to put something into the 20-year deployment 
funnel we should treat the fixed costs as high and demand more benefits. 
that's where the proposal up-thread came from.

-- 
P Vixie