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

[Paul Vixie]

神明達哉 wrote:

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

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.


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.


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.



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?


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.



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".


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

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

> > Realistically, I expect virtually everyone will implement 3, given how
> > 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

神明達哉 wrote:

At Wed, 15 Nov 2017 05:41:04 +,
P Vix  wrote:


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).

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.  ,,,


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Wed, 15 Nov 2017 05:41:04 +,
P Vix  wrote:

> >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).
>
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[P Vix]

On November 14, 2017 9:13:29 PM PST, Dave Lawrence  wrote:
>Paul Vixie writes:
>> 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.
>
>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?

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

>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.

Ah.

>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).

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

2 would be chaos, helping nobody.

>___
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dave Lawrence]

Paul Vixie writes:
> 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.

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).

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dave Lawrence]

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

Paul, and echoed by Paul:
> i'm of the opposite view. we should not change behaviour without
> 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Tue, 14 Nov 2017, Paul Vixie wrote:


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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

Dave Lawrence wrote:

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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

Ray Bellis wrote:

...

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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dave Lawrence]

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Alexander Mayrhofer]

> 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,

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..

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

On 15/11/2017 11:47, Alexander Mayrhofer wrote:

> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Alexander Mayrhofer]

On Wed, Nov 15, 2017 at 9:57 AM, Dave Lawrence  wrote:
> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

Dave Lawrence wrote:

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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dave Lawrence]

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

On Tue, Nov 14, 2017 at 4:10 AM, Dave Lawrence  wrote:

> Dave Lawrence writes:
> > 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.
>
> 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
>

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

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

[Dave Lawrence]

Dave Lawrence writes:
> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dave Lawrence]

internet-dra...@ietf.org 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=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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop