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

From: tjw ietf <[email-masked]>
Date: Tue, 5 Sep 2017 15:25:39 -0400

August is over and my self-imposed holiday is over, so it's time to get
busy again. We have this document marked as a candidate for adoption.

This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale

The draft is available here:
https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

*If You have already stated your position for or against adoption, we are
counting those so you do not need to repeat yourself. *

This call for adoption ends: 19 September 2017

Thanks,
tim wicinski
DNSOP co-chair

---

From: Davey Song(宋林健) <[email-masked]>
Date: Wed, 6 Sep 2017 13:01:05 +0800

Just quickly go through the draft. 

One question: Is it worthwhile to let sub-resolver to know that the answer is stale. It is true that “stale bread is better than no bread” on the recursive server’s point of view. But it may be not true for sub-resolver or measurement probes .

The user may want to be more informative. They may have alterative recursive servers or other resolution path ( some apps have their own resolution path) . I have this thought analogous to buying a sushi in 7&11 shop. I pay attention to the  <http://dict.youdao.com/w/expiration%20time/#keyfrom=E2Ctranslation> expiration time. I think I need to know it. 

Davey

发件人: DNSOP [mailto:[email-masked]] 代表 tjw ietf
发送时间: 2017年9月6日 3:26
收件人: dnsop
主题: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

August is over and my self-imposed holiday is over, so it's time to get busy again. We have this document marked as a candidate for adoption.  

Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view.

*If You have already stated your position for or against adoption, we are counting those so you do not need to repeat yourself. *

Thanks,

tim wicinski

DNSOP co-chair

---

From: Jared Mauch <[email-masked]>
Date: Wed, 6 Sep 2017 07:04:59 -0400

I support adoption of the document.

- Jared

> On Sep 5, 2017, at 3:25 PM, tjw ietf <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Barry Raveendran Greene <[email-masked]>
Date: Wed, 6 Sep 2017 19:35:32 +0200

+1

> On Sep 6, 2017, at 1:04 PM, Jared Mauch <[email-masked]> wrote:
>

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 7 Sep 2017 14:14:42 +0200

> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
I do support the adoption.  We plan to support some kind of
stale-serving in knot-resolver soon, so
I'm certainly willing to review and perhaps contribute some suggestions.

Still, I wonder about the intended level of vagueness of the text.  Is
it meant that the final RFC will leave (larger) unspecified corners?

One issue I see is the case when servers for some zone don't respond but
they (are expected to) only provide a *lead* to the final answer, e.g. a
delegation or a CNAME elsewhere.  In that case it seems useless to wait
without
action until the client timer fires, because we (typically) need at
least one more round-trip to get the final answer.  It might be also
good to touch the issue of negative caching of non-responsivity for some
short time (rfc2308.7.2) and consequently serving stale records
*immediately*.  There's a tradeoff between stale-ness and many resolvers
legitimately hammering servers that are/were under attack (or simply
broken).

I personally think that the length of stale-serving should derive from
the original TTL in some way, as very short TTL suggests the value is
more likely to change and operator doesn't mind increased traffic.
(Raised at IETF99, I think.)  The security section should perhaps stress
that the technique may effectively extend the range of validity in
RRSIGs, as served by validating resolvers (unless I misunderstand the
draft).  I suppose the AD flag might get zeroed in that case, but that
seems not to make much difference in practice (and we *do* want the
stale records, right?)

--Vladimir

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Sep 2017 17:42:34 +0200

On Tue, Sep 05, 2017 at 03:25:39PM -0400,
 tjw ietf <[email-masked]> wrote 

> https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

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.

There is also an opportunity that it masks failures and prevents
people from properly assigning blame: "example.com works if I use
Something Public DNS but not if I use my ISP's resolver, therefore my
ISP is broken".

Also, the current draft does not make crystal-clear that stale data
MUST NOT be served unless no authoritative name server replies.

If it is adopted, I think that requesting some way to convey the fact
it is stale to the client (Davey Song's message) is necessary.

Regarding the draft, I'm surprised by the paragraph starting with
"Paul Vixie has suggested", paragraph which seems to completely ignore
RFC 8020.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Sep 2017 09:21:12 -0700

Stephane Bortzmeyer wrote:
>   tjw ietf<[email-masked]>  wrote

+1.

-- 
P Vixie

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 07 Sep 2017 10:36:50 -0700

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

-- 
Wes Hardaker
USC/ISI

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Sep 2017 14:25:14 -0400

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

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.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Sep 2017 14:28:31 -0400 (EDT)

> I support adoption with all of that in mind.

Agreed.

Paul

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 7 Sep 2017 20:32:26 +0200

> 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 exam…

Yes, an interesting idea.  It should be easy to design an EDNS option
that allows to (1) customize some parameters of this (opt-in, opt-out,
request a different client-timeout) and (2) indicate whether some RRs
are stale and perhaps how much stale they are.

--Vladimir

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 Sep 2017 11:33:22 -0700

At Thu, 07 Sep 2017 10:36:50 -0700,
Wes Hardaker <[email-masked]> wrote:

> reliable in the face of DDoS attacks.

+1.

If we don't work on a proposal like this, I'd love to see a specific
counter proposal that doesn't violate the current protocol
specification (i.e., using a cached answer beyond its TTL) and still
avoids resolution failure when authoritative servers are forced to be
non-responsive due to huge scale DoS attacks.  Otherwise the more
likely scenario is that some vendors still keep a similar protocol
violation using marketing decoration like "smartness" while other
compliant implementors just look incompetent (and this will be a huge
incentive for the latter group to follow the former, and we'll just
see more proliferation of this violation).

--
JINMEI, Tatuya

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Sep 2017 13:29:47 -0700

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

> everyone should be using a DDoS resilient cloud provider in case they

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

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Sep 2017 13:42:45 -0700

On Thursday, September 07, 2017 11:33:22 AM 神明達哉 wrote:
> ...
> non-responsive due to huge scale DoS attacks.

i think the actual problem statement is broader, and that by solving for this 
narrow version, we would lose the complexity/capability tradeoff -- we'd add 
more state and more signaling at a cost higher than what we would get for it.

it's a general reachability problem not specifically ddos problem. reasons for 
not being able to refresh data in a cache include ddos, but also backhoes, 
wire cutters, squirrels, circuit breakers, and bad design/provisioning.

i think the right answer will look like a miniature version of IXFR/AXFR and 
NOTIFY, such that a cache can register its intent to become a partial stealth 
secondary server, and by participating, an authority server can both indicate 
its willingness to have this done, and possibly remember what was transmitted 
so as to facilitate subsequent cache invalidation or zone change notification 
messaging. one could even imagine a dns cookie exchange at the outset, to help 
authenticate later messages. sort of a super-lightweight session protocol.

when the DNS was first popularized, we were using a lot of computers with less 
than four megabytes of memory and fewer than a million instructions per 
second, and our links were thought fast if 56K DDS, or super-fast if 1.544M T1 
or even 2.0M E1. this drove choices of how to encode, how to compress, where 
to synthesize, and whether to authenticate. all of those choices should be up 
for reconsideration now.

if our _vision_ as a technical community is to have little chunks of semi-
authoritative data cached in stealth-like secondary-like places, and then kept 
up to date, then we should pursue that, because moore's law and the 
privatization and commercialization of the internet have made it now 
practical.

if we lack a vision and we're going to pursue small discrete targets of 
opportunity based on the business problems faced by each industry participant, 
then we'd be making hairball soup, and i'd ask that we not.

see also:

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

vixie

---

From: George Michaelson <[email-masked]>
Date: Fri, 8 Sep 2017 08:03:27 +1000

add client-intent signalling, and irrespective add server signalling
of action, and I could be there.

I'd support adoption.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 7 Sep 2017 18:12:41 -0400

> default case where such signaling is absent, data shall not be used beyond its 

	Would you see the querying application informing you of intent via 
option code saying "If I'm unable to talk to you once TTL expires, I may serve 
your last known good answer"?

	What would a server then do if this intent were known?  serve some
alternate data, or even return REFUSED?  I could see sending a secure notify
to anyone who requested the QNAME after change, but holding this state may
end up with complexity similar to what's some have seen with ECS.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Sep 2017 12:07:09 +1000

Part of the problem is that we have one TTL value for both freshness
and don't use beyond.

This is fixable.  It is possible to specify two timer values.  It
does require adding signaling between recursive servers and
authoritative servers, on zone transfers and update requests.

You basically add a additional timer field to every record immediately
after the TTL field.  This is only returned if the client has
signalled support for the extended field, I suggest using the last
DNS header bit for this as you can determine how you will parse the
response base on whether the bit is set in the response or not.
This field is used to expire records from the cache and its value
is set to the TTL field if the server has learnt the record from
server that doesn't support the extension.

The existing TTL field is used for freshness checking.  When a query
comes in after that value has expired a freshness check is performed
similar to the existing prefetches that happen today.  A TTL of 1
is returned unless the original TTL was 0 in which case 0 is returned.

New client - new recursive server - new authservers

	example.com. 300 86400 IN A 1.2.3.4

		+300 seconds

	example.com. 1 86100 IN A 1.2.3.4
	 (background query is in process)

Old client - new recursive server - new authservers

	example.com. 300 IN A 1.2.3.4

		+300 seconds

	example.com. 1 IN A 1.2.3.4
	 (background query is in process)

New client - new recusive server - old auth servers

	example.com. 300 300 IN A 1.2.3.4

		+300 seconds
	 (record has expired from cache,
	  new query is performed)

	example.com. 300 300 IN A 1.2.3.4

For UPDATE a replacement opcode would be cleanest way to signal the
new format is being used.  NOTIMP should be returned by servers
that don't support the new opcode.

There will be a few broken servers that just echo back the new
header bit.

This way the authoritative servers still control how long records
are stored for.  Dead servers will get a little bit of traffic until
the the refresh completes.  If the authorative servers are under
attack the clients still see a answer.

The alternative is to perform the refresh query and if it fails to
complete within X milliseconds return the cached data rather than
returning the cached data and doing the refresh in the background.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 8 Sep 2017 09:56:42 +0200

On Thu, Sep 07, 2017 at 02:25:14PM -0400,
 Joe Abley <[email-masked]> wrote 
 a message of 35 lines which said:

> 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

I'm not convinced by this reasoning. Either the opinion of the IETF
carries some weight with some actors, or it doesn't. In the first
case, we have to be careful of what we publish. In the second case, we
should close the shop immediately and go back playing video games,
since we are useless.

Also, in the specific case of draft-tale-dnsop-serve-stale, there is
another point: it is a local, unilateral decision by the resolver, not
_directly_ affecting interoperability. People can do strange things on
their resolvers (they already do). We should set rules (see first
paragraph) but, on resolver behavior, we have to be modest. So, I
don't think "a standard approach" is _mandatory_ in that specific
case.

---

From: Davey Song(宋林健) <[email-masked]>
Date: Fri, 8 Sep 2017 17:15:56 +0800

I just notice it asks for "Standards Track" document. If it aims to
introduce a special use of resolver to achieve some features for their
users' benefit, I think informational document may be more appropriate ? I
guess, like what RFC7706 does. 

Davey

> -----邮件原件-----
> 发件人: DNSOP [mailto:[email-masked]] 代表 Stephane Bortzmeyer
> 发送时间: 2017年9月7日 23:43
> 收件人: tjw ietf
> 抄送: dnsop
> 主题: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
> 
> On Tue, Sep 05, 2017 at 03:25:39PM -0400,  tjw ietf <[email-masked]>
> wrote  a message of 77 lines which said:
> 
> 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.
> 
> There is also an opportunity that it masks failures and prevents people
from
> properly assigning blame: "example.com works if I use Something Public DNS
> but not if I use my ISP's resolver, therefore my ISP is broken".
> 
> Also, the current draft does not make crystal-clear that stale data MUST
NOT
> be served unless no authoritative name server replies.
> 
> If it is adopted, I think that requesting some way to convey the fact it
is stale to
> the client (Davey Song's message) is necessary.
> 
> Regarding the draft, I'm surprised by the paragraph starting with "Paul
Vixie
> has suggested", paragraph which seems to completely ignore RFC 8020.
>

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 8 Sep 2017 11:23:41 +0200

> guess, like what RFC7706 does. 

It was argued that the draft modifies the meaning of TTL and therefore
"updates" 1034+1035 which are on Standards Track.  I agree with that
point of view.

--Vladimir

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Sep 2017 15:16:52 +0100

Stephane Bortzmeyer <[email-masked]> wrote:
> more reliable, not on adding something to a pile of already fragile
> protocols.

I like this draft because it should help if we lose off-campus
connectivity. We've had a few incidents in recent years such as flooded
comms rooms and DDoS attacks on our providers. Those problems have been
addressed at the network layer, but if we have another outage for whatever
reason I would like our recursive servers to be able to handle it more
gracefully.

We have set things up so it should be possible to resolve on-site names in
our own domains when there is an outage - but not if the client does
DNSSEC validation. It isn't possible to distribute trust anchors to BYOD
clients with validating stubs, so the only way to keep going through an
outage is to retain the DS/DNSKEY chain in the cache.

It's also mildly annoying that loss of connectivity often looks like a DNS
problem, since client software never gets as far as trying to connect off
site. I would selfishly prefer it if our users would blame the network
rather than the DNS :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: Northwest 5 to 7, occasionally gale 8 later. Rough or very rough.
Showers. Good.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Sep 2017 12:57:05 -0400 (EDT)

On Fri, 8 Sep 2017, Tony Finch wrote:

> It isn't possible to distribute trust anchors to BYOD
> clients with validating stubs

That's not entirely true,

https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-02

It supports sending INTERNAL_DNSSEC_TA trust anchors.

Paul

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Sep 2017 18:11:24 +0100

> It supports sending INTERNAL_DNSSEC_TA trust anchors.

Nice!

But I'm not sure it's entirely sensible to depend on a VPN to make an
on-campus connection work properly :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Rockall: Northwest 6 to gale 8, decreasing 4 or 5 later. Rough or very rough.
Rain or showers. Moderate or good.

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 8 Sep 2017 15:53:16 -0400

> This call for adoption ends: 19 September 2017

Hi,

I support the adoption of this document.

Comments:

This document is marked as updating 1034 and 1035 but it's not clear
what text from those documents is being updated. E.g. compare to
"NXDOMAIN: There Really Is Nothing Underneath" (RFC 8020) which
explicitly documents its revisions in its Section 3.

I think the claim in the introduction, "Notably, the original DNS
specification does not say that data past its expiration cannot be used"
should either be justified further or removed. The "should again be
consulted" text from STD 13 could be read in isolation as permitting
serve stale, but it's the weakest text out of these three TTL
definitions given in STD 13:

RFC 1034 §3.6:

    "The TTL describes how long a RR can be cached before it should be
    discarded. […] The meaning of the TTL field is a time limit on how
    long an RR can be kept in a cache."

RFC 1035 §3.2.1:

    "a 32 bit […] integer that specifies the time interval that the
    resource record may be cached before the source of the information
    should again be consulted."

RFC 1035 §4.1.3:

    "a 32 bit […] integer that specifies the time interval (in seconds)
    that the resource record may be cached before it should be
    discarded."

That is, if "the original DNS specification does not say that data past
its expiration cannot be used" is true, then this document doesn't need
to update STD 13, and maybe it should only be an informational document.
But if it's not true (and I don't think it is, based on the other two
TTL definitions in STD 13), then a new TTL definition should be given
that permits the serve stale mechanism.

Also, just for fun, this text from RFC 882 exists (p.28 "Resolvers with
cache management") and is even stronger than the text in STD 13:

    "When a resolver caches a returned resource record it must also
    remember the TTL field.  The resolver must discard the record when
    the equivalent amount of time has passed."

-- 
Robert Edmonds

---

From: 神明達哉 <[email-masked]>
Date: Fri, 8 Sep 2017 13:11:27 -0700

At Thu, 07 Sep 2017 13:42:45 -0700,

> more state and more signaling at a cost higher than what we would get for it.

I'm not sure specifically what you mean by these, but...

> wire cutters, squirrels, circuit breakers, and bad design/provisioning.

...I agree here.  I'm well aware of the generic nature of the issue,
but I mentioned one specific instance of the problem in my previous
message just because that's the most obvious one.

> authenticate later messages. sort of a super-lightweight session protocol.

I guess we are also on the same page in a sense here.  One possible
justification for a behavior like draft-tale-dnsop-serve-stale is that
it can be considered a recursive server variant of a secondary
authoritative server that keeps using primary's zone content even if
the auth server is unreachable for a certain period (until, of course,
the entire zone expires).  If this makes some sense, we may be able to
develop a cleaner solution than serve-stale by expanding the
observation.

I'm not necessarily a fan of the specific approach described in
draft-tale-dnsop-serve-stale, but I have to admit it's a practical
workaround (if not a "solution") for a real-world problem happening
today.  I'd be happier if the wg agrees on working on a better
solution, but in that case we should also be pragmatic.  That includes
the recognition that any protocol extension that requires changes to
both recursive and authoritative servers will take quite long to
deploy.  Since the problem is real and current, the solution should
have an intermediate state that might look a mere hack.

--
JINMEI, Tatuya

---

From: Lanlan Pan <[email-masked]>
Date: Sat, 09 Sep 2017 02:04:57 +0000

> guess, like what RFC7706 does.

+1,  I support the adoption of this document if it is informational.

recursive can choose to support this "cache operation improvement feature"
or not, but not update 1034/1035's TTL definition.

recursive may use stale data/extend the TTL for some special scenario, for
example:

==not ddos attack==
1)  some domains' A TTL are set to 1s, and they will not change it, because
they think that will help new RR spreads faster...
recursives offen have to extend the TTL = 90s or 600s or 3600s.

2)  network temporary failure on resolution path ( recursive ->
authoritative ) , SERVFAIL / TIMEOUT, offen short time
trigger some "use stale bread" callback function to deal with the
SRRVFAIL/TIMEOUT failure,  the data is snapshot from online hot cache
LRU/cache aging heuristic.

==ddos attack==
3)  recursive encounter ddos attack
trigger "proxy top-N important domain's dns response" on the ddos
firewall,  the top-N important domain's data is generated from the whole
latest-M days query log.

4) important SLD authoritative encounter ddos attack
SLD authoritative wants recursives trigger above 2) solution on its hot
domains, for its most visited service.
SLD authoritative wants recursives have some knowledge about its subdomain
wildcards, to avoid not-visited subdomain wildcard failure.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Bob Harold <[email-masked]>
Date: Mon, 11 Sep 2017 14:11:25 -0400

> returning the cached data and doing the refresh in the background.

While I like the idea of a  "don't use beyond" timer, I think it will be a
very long time before it is widely deployed (and actually configured by
zone owners), and therefore won't solve our immediate need.  It would be
great if clients could opt-in, but again I don't see that happening anytime
soon.  So I would start with resolver-operators deciding what seems best
for their clients (which is hat is happening whether we like it or not).
Adding client opt-out/opt-in would be good.   Signalling to say that a
response is stale would be good.  Adding the second timer (both per-RR and
as a zone default value, like TTL is handled) would be good.

On a related note - the SOA "expire" timer tells a slave how long to keep
serving "stale" zone data when the master cannot be reached.  Would that be
a reasonable default value for how long a resolver should serve "stale"
data when the authoritative servers cannot be reached?   (Currently I think
most people set a very high value compared to the TTL.)

-- 
Bob Harold

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 11 Sep 2017 11:52:05 -0700

I support the adoption of this document. Was there a discussion of any
actual downsides besides "I'd like to know if it's stale" and
monitoring?

On Mon, Sep 11, 2017 at 11:11 AM, Bob Harold <[email-masked]> wrote:
> very long time before it is widely deployed (and actually configured by zone
> owners), and therefore won't solve our immediate need.  It would be great if
> clients could opt-in, but again I don't see that happening anytime soon.  So
> I would start with resolver-operators deciding what seems best for their
> clients (which is hat is happening whether we like it or not).  Adding
> client opt-out/opt-in would be good.   Signalling to say that a response is
> stale would be good.  Adding the second timer (both per-RR and as a zone
> default value, like TTL is handled) would be good.
>
> a reasonable default value for how long a resolver should serve "stale" data
> when the authoritative servers cannot be reached?   (Currently I think most
> people set a very high value compared to the TTL.)
>
> --
> Bob Harold
>
>
>