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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
