Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

[Paul Vixie <[e-mail]>]

there will be two replies here. one to wes, one to joe.

On Thursday, September 07, 2017 10:36:50 AM Wes Hardaker wrote:
> Stephane Bortzmeyer <[e-mail]> writes:
> > I'm not enthousiastic. We should focus on making the DNS
> > infrastructure more reliable, not on adding something to a pile of
> > already fragile protocols.
> 
> I don't believe we have any ideas how to make infrastructure more
> reliable in the face of DDoS attacks.  Is your opinion then that
> everyone should be using a DDoS resilient cloud provider in case they
> ever get attacked?

i dislike the form of the second sentence, so i'll restrict my answer to your 
first sentence alone. if i were to take the question in your second sentence 
literally, my answer would be simply, yes. but that would be misleading as to 
my actual values and true intentions.

i agree that we don't have ideas on how to make infrastructure more reliable 
in the face of ddos attacks. having authored the cut-down simplified pointy-
haired-boss version of BCP38 (which we called SAC004) and having spent a 
decade on airplanes trying to get folks to understand what source address are, 
why bad guys like to spoof them, and why good guys aren't properly positioned 
or incentivized to verify them... i sort of gave up and assumed that the 
internet was just never going to be dependable. that is to say, any time some 
angry teenager wants something to be down, it will be down. exceptions include 
facebook and google, who have invested literally tens of billions of dollars 
in scalable defensible infrastructure.

i could have predicted that others who realized this fundamental unshakable 
and dark truth would behave otherwise -- not, in other words, simply give up. 
i urge you to reconsider whether adding more signaling and more state to a 
system that already has more than we can comprehend, is your best way forward. 
in fact, please consider the possibility that you are following a recipe for 
disaster, where by trying to solve the problems you have today, you must and 
will inevitably create worse problems for tomorrow, which will be even harder 
to identify much less to solve.

see also:

http://queue.acm.org/detail.cfm?id=1242499

---

On Thursday, September 07, 2017 02:25:14 PM Joe Abley wrote:
> On 7 Sep 2017, at 11:42, Stephane Bortzmeyer <[e-mail]> wrote:
> > I'm not enthousiastic. We should focus on making the DNS
> > infrastructure more reliable, not on adding something to a pile of
> > already fragile protocols.
> 
> I hear that. I don't have a strong opinion about whether serving stale data
> in general is desirable or abhorrent. However, the pragmatist in me says
> that people are already implementing things like this anyway, and a
> standard approach is better for all concerned than a fragmented set of
> uncomfortably-different implementations, which will surely make
> troubleshooting problems harder.

joe, i'd be ready to agree, except that ECS was standardized here under the 
same (precisely the same) reasoning, and as you'll recall, i lost my bid to 
have an applicability statement included, to the effect that this practice is 
common, but not necessarily recommended, and in fact somewhat controversial.

unless you can show how a standard for using stale data, published by the 
IETF, will not have an imprimatur such that newcomers believe that there are 
no downsides to implementing it, then i must respectfully disagree that having 
a standard would be better than having chaos.

> I also think if a standard specification can be obtained it ought to include
> appropriate instrumentation to allow a response to indicate whether data is
> stale or not. This seems to me just one example of a set of additional
> components we might expect the working group to come up with, which in my
> mind is a good reason to make it a working group document.
> 
> I support adoption with all of that in mind.

if the draft being considered was clear on two points, i'd support adoption.

first, this feature is controversial, and there is not consensus favouring its 
implementation, merely its documentation.

second, the initiator must indicate its intent to use data beyond its TTL, and 
the responder must assent to this, and that otherwise, including in the 
default case where such signaling is absent, data shall not be used beyond its 
TTL.

vixie