Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

From: Dave Lawrence <[email-masked]>
Date: Mon, 6 Nov 2017 10:39:07 -0500

[email-masked] writes:
>       Title           : Serving Stale Data to Improve DNS Resiliency
> 	Filename        : draft-ietf-dnsop-serve-stale-00.txt

This is the same as draft-tale-dnsop-serve-stale-02, only renamed for
WG adoption.

The differences between -01 and -02 are here:

https://www.ietf.org/rfcdiff?url1=draft-tale-dnsop-serve-stale-01&url2=draft-tale-dnsop-serve-stale-02

The main changes, based on previous feedback, are:

* Clarifying what the action is for Standards Track;
* Describing the algorithm previously proposed (and still included) as
  one example way of achieving the goals; and,
* Adding a rough proposal for an EDNS option that could be used for
  explicit signalling.

That last item will be fleshed out more if there's demonstrated
interest from implementers in having such a thing.

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 14 Nov 2017 04:10:32 -0500

> interest from implementers in having such a thing.

At the moment I'll observe there are no open issues against the draft,
which is my comically passive-aggressive way of pointing out that it
is obviously perfect and so let's just move it along to Last Call.

This is now your opportunity to correspondingly observe that someone
is wrong on the Internet and to respond appropriately.  At the very
least, we'd like to know whether there is sufficient support for
pursuing the EDNS option or just to take it back out (and leave the
rest of the obviously perfect document as-is).

Thanks in advance for any feedback,
tale

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Nov 2017 01:25:59 -0800

> is obviously perfect and so let's just move it along to Last Call.

i apologize for my silence. there's been a lot going on in this WG.

> rest of the obviously perfect document as-is).

this document must not proceed without explicit signaling, because this 
practice must not grow without explicit signaling.

> Thanks in advance for any feedback,

you're welcome in advance!

-- 
P Vixie

---

From: Bob Harold <[email-masked]>
Date: Tue, 14 Nov 2017 11:06:45 -0500

> Thanks in advance for any feedback,

I think signaling between the client and resolver is important.  I am a
little concerned about yet another option that the client might want to
send with every query.  Can the existence of *any* EDNS option from the
client be taken to mean that EDNS options are understood in general, and
the resolver is ok to respond with this ENDS option, which the client might
not understand but will not choke on?

Signalling between the resolver and authoritative server gets more
complicated.  Probably a good idea, but if the defaults are reasonable, it
probably won't need to be used often.

-- 
Bob Harold

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 14 Nov 2017 20:57:36 -0500

Bob Harold writes:
> I am a little concerned about yet another option that the client
> might want to send with every query.  Can the existence of *any*
> EDNS option from the client be taken to mean that EDNS options are
> understood in general, and the resolver is ok to respond with this
> ENDS option, which the client might not understand but will not choke on?

I personally am of the belief that yes, if the request has an OPT then
a responder can include an option code that was not in the request.
At least I don't see anything in 6891 to prohibit it.  This is
behaviour that draft-ietf-dnsop-extended-error is also expecting.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Nov 2017 19:36:27 -0800

> behaviour that draft-ietf-dnsop-extended-error is also expecting.

while i've seen every kind of misbehaviour from EDNS responders, i've 
yet to suspect that an initiator who knows EDNS in any form will choke 
on, or syslog about, unrecognized options in the response. so, +1 to tale.

-- 
P Vixie

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 15 Nov 2017 11:47:22 +0800

> behaviour that draft-ietf-dnsop-extended-error is also expecting.

I agree that signaling is important, and i also believe that if
there's an OPT in the request, we can safely assume that the client
would not choke on this option. I'm torn on the question whether or
not stale data should be served (without signaling, in that case) when
the request does *not* contain an OPT request. Probably we should err
on the side of *not* serving stale when a client is not "EDNS
capable", because that would mean no change from current behaviour.

Alex

---

From: Ray Bellis <[email-masked]>
Date: Wed, 15 Nov 2017 11:51:20 +0800

> capable", because that would mean no change from current behaviour.

I'm not particularly arguing either way on this question of signalling,
but do we have any feel for how many stubs ever send EDNS?

libresolv can do it, and getdns does, but I don't think glibc's resolver
routinely sends EDNS.

Ray

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 15 Nov 2017 11:54:18 +0800

> libresolv can do it, and getdns does, but I don't think glibc's resolver

Ray,

i do agree - having figures "from the field" about this would be
great. We don't see much direct stub resolver traffic obviously, so i
can't provide any, unfortunately..

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 14 Nov 2017 22:57:42 -0500

Alexander Mayrhofer writes:
> I'm torn on the question whether or not stale data should be served
> (without signaling, in that case) when the request does *not*
> contain an OPT request.

I'm personally not torn on this; for me the whole point of
implementing this functionality is to add resiliency to the existing
DNS ecosystem.  Very specifically for my implementation it was needed
in an environment where answers were going to a stub resolver that did
not (and still does not) speak EDNS.

It is significantly less operationally beneficial if it demands EDNS.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Nov 2017 20:07:24 -0800

Ray Bellis wrote:
> ...

i would look to opendns or gdns for those stats. they've got to be 
seeing an excellent cross-section of every possible stub implementation.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Nov 2017 20:08:55 -0800

> It is significantly less operationally beneficial if it demands EDNS.

i'm of the opposite view. we should not change behaviour without 
explicit signaling. if that means it takes 10 years to reach 50% 
penetration, like EDNS did, then that's the cost of doing business.

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Nov 2017 23:12:58 -0500 (EST)

On Tue, 14 Nov 2017, Paul Vixie wrote:

> i'm of the opposite view. we should not change behaviour without explicit 
> signaling. if that means it takes 10 years to reach 50% penetration, like 
> EDNS did, then that's the cost of doing business.

Agreed. DNS updates are slow enough as it is. Taking into account 10+
year old non-updated DNS software will make the future more even more
slowly. It's not actually helping us.

Paul

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 14 Nov 2017 23:54:26 -0500

Paul, and echoed by Paul:
> explicit signaling.

I've opened this as an issue to track toward WG consensus and suspect
that, unless strong consensus for one view or the other obviously
emerges on the list, that we'll be looking for a hum on it in London.

On the practical side, private implementations are of course going to
easily evade any MUST that could eventually make its way here and
still be seamlessly interoperable with clients.  The restriction's
effect would mainly be binding for implementations claiming the
strictest compliance.

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 15 Nov 2017 00:13:29 -0500

> penetration, like EDNS did, then that's the cost of doing business.

Just so I'm clear, am I understanding correctly from this that you
believe a recursive server should only fall back to stale data from
cache if the request explicitly included a staleness option?

I ask because Bob's comment that started this thread was exploring
being able to signal staleness back when OPT was included in the
request but the option being defined by the draft wasn't included.

To me this makes three different positions we're trying to reach
consensus about, for allowing fallback to stale either:

1) when the request explicitly signals it is ok;
2) when the request groks EDNS but might or might not understand
   a staleness option; or
3) in all cases.

My current understanding is that you and Paul are of position 1, while
I'm at 3.  At first glance 2 would appear to be pretty nearly the same
as 3 as far as its permissive toward unaware clients, but
significantly it does at least provide signal you could still access
via protocol debugging (dig, tcpdump, etc).

---

From: P Vix <[email-masked]>
Date: Wed, 15 Nov 2017 05:41:04 +0000

>cache if the request explicitly included a staleness option?

Yes. I know that coherency does not rank high in a cdn operator's priority queue, but the dns has other users also.

>request but the option being defined by the draft wasn't included.

Ah.

>via protocol debugging (dig, tcpdump, etc).

I expect you to implement 3. I expect us to document 1.

2 would be chaos, helping nobody.

>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 16 Nov 2017 11:10:54 -0800

At Wed, 15 Nov 2017 05:41:04 +0000,

> I expect you to implement 3. I expect us to document 1.

Realistically, I expect virtually everyone will implement 3, given how
this kind of feature is sold in the marketing context.  Open-source
reference implementations may implement 1 if it actually becomes the
standard behavior, but I bet any serious large-scale user of those
implementations will make a custom change to disable that part.  I'd
be sad about that, but that's quite likely to be the reality.

I don't want the IETF to standardize a bad practice, and in that sense
I'd personally prefer option 1 (or something that shares its spirit).
But, as an engineering group, if there's basically no chance to deploy
it I don't see a point of bothering to standardize it.

So, if we choose to document option 1, I'd like to know the plan of
this group of its deployability.  Is it that we optimistically think
that nearly all stub resolvers eventually (in 5-10 years?) support the
signaling option and enable it by default, and then server
implementations will gradually start honoring the standard (and until
then we'll just grumble about the deployment of non-compliant
implementations)?

--
JINMEI, Tatuya

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Nov 2017 22:02:33 -0800

神明達哉 wrote:
> P Vix<[email-masked]>  wrote:
>
> this kind of feature is sold in the marketing context.  ,,,

me too. that's why, in:

https://mailarchive.ietf.org/arch/msg/dnsop/zRuuXkwmklMHFvl_Qqzn2N0SOGY/?qid=ff8e732c964b76fed3bbf333b89b111f

...i wrote:

> therefore a "serve stale" team within IETF-DNSOP was convened, to try to
> standardize the methods and signal patterns necessary to extend the
> usability lifetime of records when their authority servers are not
> reachable at the time of normal TTL-based expiry. most of us recognize
> that TTL's will continue to be stretched no matter what changes are or
> are not made to the specification, and so we expect the resulting RFC to
> document current practice _without recommending it_ and to also document
> a new practice _with recommendations_ as to its proper uses.

comments would be very welcome.

-- 
P Vixie

---

From: 神明達哉 <[email-masked]>
Date: Fri, 17 Nov 2017 10:46:33 -0800

At Thu, 16 Nov 2017 22:02:33 -0800,

> > a new practice _with recommendations_ as to its proper uses.

This (including the entire message) looks reasonable to me, as long as
we mean it, i.e., we actually seriously work on the "new practice" as
a followup wg task, rather than just using it as an excuse to publish
the current serve-stale draft.

But I'd note there might be some confusion here (perhaps only for me,
though).  I've been having the impression that we are talking about
"signalling" between the stub and caching (usually recursive) server,
perhaps because it's a followup of this message:
https://www.ietf.org/mail-archive/web/dnsop/current/msg21339.html

But your suggestion is signalling (mainly) between caching and
authoritative servers, right?

I thought recommending to allow fallback to stale

>>> 1) when the request explicitly signals it is ok;

between stub and caching wasn't realistic, as I didn't see a strong
incentive for the developers and users of stub (except for
protocol-savvy kinds).  That's why I was pessimistic in my previous
message.  I see more reality if it's about signalling between caching
and authoritative since, as you pointed out, there may also be
incentive for authoritative operators to adopt the "new practice".

--
JINMEI, Tatuya

---

From: Paul Vixie <[email-masked]>
Date: Fri, 17 Nov 2017 15:06:20 -0800

神明達哉 wrote:
> Paul Vixie<[email-masked]>  wrote:

later in [ibid], i wrote:

> this system would allow gradual insertion of the new state management
> logic on an opportunistic basis -- motivated authority and recursive
> server operators, which would include CDN operators who must perform
> both services perfectly -- would be early adopters, and like ECS before
> it, the "hot" part of the community would be upgraded years earlier than
> the last outlier.

i think that it's in the large RDNS operators' interests, and in the 
large authority operators' interests, and in CDN and proxy operators' 
interests, to deploy these new protocols -- and that once they see 
positive results, they will find it in their best interests to turn off 
the older pre-standard TTL stretching logic that should be described, 
but _not recommended_, in the TTL-stretch specification.

if i could not visualize a fully interest-aligned deployment path for 
the operators who most need TTL stretching, then i would agree with your 
concern that we might not "mean" it.

> authoritative servers, right?

yes. i don't think anything that requires end-system upgrades is going 
to answer the market need for TTL stretching. even "happy eyeballs" took 
five years to be adopted and another two years to stabilize.

> incentive for authoritative operators to adopt the "new practice".

the TTL stretching specification should ideally introduce new stub 
signalling to turn off stretching, so that those of us using "dig" in 
diagnostic mode, can learn more about the TTL-state of the RRset in our 
local RDNS.

-- 
P Vixie