Jinmei:
> I also found it confusing on my fresh re-read of serve-stale-03 in
> that the "example method" section contains normative descriptions
> using RFC2119 keywords.
You're in good company in that co-author Puneet has voiced the same
opinion.
My own take is that it's appropriate because if
At Fri, 1 Mar 2019 15:54:39 -0500,
Dave Lawrence wrote:
> > I'm not sure a standards track document that updates RFC 1034/1035
> > should be recommending a minimum TTL.
>
> As previously noted, we're making no such recommendation and that will
> be clarified. The first definition of "resolution
On 6 Mar 2019, at 11:27, Dave Lawrence wrote:
> Joe Abley writes:
>> if you can find a set of DNS authority servers that silently
>> discards a particular kind of query, sending such queries through
>> resolvers that are known to support serve-stale might suppress other
>> queries and trigger the
Joe Abley writes:
> if you can find a set of DNS authority servers that silently
> discards a particular kind of query, sending such queries through
> resolvers that are known to support serve-stale might suppress other
> queries and trigger the serve-stale behaviour even though the
> authority ser
Tony Finch writes:
> This sounds like it will lead to stale answers being given instead of
> re-trying other potentially working servers.
The document is explicit that you need to keep trying to get an
answer, so if an implementation is not retrying other potentially
working servers that is its ow
Joe Abley wrote:
>
> How recently should a server have been checked and found not to respond
> to conclude that it's unresponsive? What does unresponsive mean?
> Presumably this involves a timeout; how long? Perhaps these questions
> are already answered in practice by existing implementations, bu
On 06.03.19 15:37, Joe Abley wrote:
> if you can find a set of DNS authority servers that silently discards
> a particular kind of query, sending such queries through resolvers
> that are known to support serve-stale might suppress other queries
> and trigger the serve-stale behaviour even though
On 6 Mar 2019, at 08:03, Tony Finch wrote:
> Dave Lawrence wrote:
>
>> REFUSED is slightly murkier as to its exact meaning, thanks to
>> overloading, but in its most commonly seen usage for lameness
>> indicates a clear problem with the delegation. Even in its other use
>> cases, notably an ED
Dave Lawrence wrote:
> REFUSED is slightly murkier as to its exact meaning, thanks to
> overloading, but in its most commonly seen usage for lameness
> indicates a clear problem with the delegation. Even in its other use
> cases, notably an EDNS Client Subnet error or an actual "I am
> authorita
On Tue, 5 Mar 2019, Dave Lawrence wrote:
I can sort of see how someone might infer from "It is predicated on
the observation that authoritative server unavailability can cause
outages ..." that it means this whole idea is constrained to DDoS, and
presumably you would include as well other networ
Tony Finch writes:
> If the zone has a mixture of lame and working servers, the lame servers
> should not trigger serve-stale, because the resolver still needs to try
> asking the working servers.
Yes, complete agreement. That is the thrust of what the document says.
Christopher Morrow writes:
> My point is that the recursive reoslver has no idea why an authoritative
> is unreachable and that doing anything like sending stale records is
> going to cause unintended problems.
Given the operational benefit that has already been observed in
production with serve-
Paul Wouters writes:
> I am a bit confused here. The goal of the draft is to keep data past
> the TTL in case you cannot reach the authoritative servers during a
> DDOS attack.
There are many different failure modes in operating the DNS and
the goal of this draft has been to accommodate the ones t
Tony Finch wrote:
>
> Say you have a partially-lame zone, where some servers might have an
> expired copy (returning SERVFAIL) and some might not know about the zone
> at all (returning REFUSED or referrals to the root). Typically (without
> serve-stale) a resolver will react by adding a lame serv
Paul Wouters wrote:
>
> I am a bit confused here. The goal of the draft is to keep data past the
> TTL in case you cannot reach the authoritative servers during a DDOS
> attack.
Right.
There's a tricky interaction between lameness and serve-stale.
Say you have a partially-lame zone, where some
On Mar 5, 2019, at 9:39 AM, Christopher Morrow wrote:
>
>
> So, sorry I added an example set and we rat-holed on those.
>
> My point is that the recursive reoslver has no idea why an authoritative
> is unreachable and that doing anything like sending stale records is
> going to cause unintende
On 4 Mar 2019, at 23:52, Christopher Morrow wrote:
> I don't know how long it takes to get ICANN to 'do something creative' for
> the root zone, but I'm guessing this isn't always feasible in normal
> timelines (hours to a day or so).
The IANA created an official, supported mechanism for emerg
So, sorry I added an example set and we rat-holed on those.
My point is that the recursive reoslver has no idea why an authoritative
is unreachable and that doing anything like sending stale records is
going to cause unintended problems.
-chris
___
DN
On Tue, 5 Mar 2019, Paul Hoffman wrote:
On Mar 5, 2019, at 7:59 AM, Dave Lawrence wrote:
Paul Wouters writes:
In the non-DDOS case, the auth server is reachable and none of the data
is getting additional TTL added:
Answers from authoritative servers that have a DNS Response Code of
ei
On Mar 5, 2019, at 7:59 AM, Dave Lawrence wrote:
>
> Paul Wouters writes:
>> In the non-DDOS case, the auth server is reachable and none of the data
>> is getting additional TTL added:
>>
>>Answers from authoritative servers that have a DNS Response Code of
>>either 0 (NOERROR) or 3 (NXD
Paul Wouters writes:
> In the non-DDOS case, the auth server is reachable and none of the data
> is getting additional TTL added:
>
> Answers from authoritative servers that have a DNS Response Code of
> either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have
> refreshed the data
Paul Vixie writes:
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> > can I ask, what happens when a domain is intentionally down though? For
> > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> > master/shadow NS go down, hard. All public auth servers ev
On Mon, 4 Mar 2019, Christopher Morrow wrote:
"If the recursive server is unable to contact the
authoritative servers for a query "
So make the DNS server reachable, but return ServFail or NXDOMAIN. If
the owner doesn't cooperate and there is legal stan
On Mon, Mar 4, 2019 at 11:00 PM Paul Wouters wrote:
> On Tue, 5 Mar 2019, Mark Andrews wrote:
>
> >> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> >>> can I ask, what happens when a domain is intentionally down though? For
> >>> instance, take .eg... ~4yrs back? (maybe 5?) Som
> On 5 Mar 2019, at 2:59 pm, Paul Wouters wrote:
>
> On Tue, 5 Mar 2019, Mark Andrews wrote:
>
>>> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?) Some
On Tue, 5 Mar 2019, Mark Andrews wrote:
On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
master/shadow NS go down, hard. All public auth
> On 5 Mar 2019, at 1:26 pm, Paul Vixie wrote:
>
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
>> can I ask, what happens when a domain is intentionally down though? For
>> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
>> master/shadow NS go down,
On Mon, Mar 4, 2019 at 9:26 PM Paul Vixie wrote:
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> > can I ask, what happens when a domain is intentionally down though? For
> > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> > master/shadow NS go down,
On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> can I ask, what happens when a domain is intentionally down though? For
> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> master/shadow NS go down, hard. All public auth servers eventually (in a
> day or so)
can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
master/shadow NS go down, hard. All public auth servers eventually (in a
day or so) went dark too.
If someone is 'ordered' to make a zone dark, there may
"Proposal: Put all recommendations in Section 4, and talk about them
(instead of introducing them) in the other sections. That way, a lazy
developer who only reads Section 4 will know all the recommendations."
I totally agree here. It also makes it easier if the document passed WGLC
and moves alo
> On Mar 1, 2019, at 12:54 PM, Dave Lawrence wrote:
>
> Paul Hoffman writes:
>> I'm not sure a standards track document that updates RFC 1034/1035
>> should be recommending a minimum TTL.
>
> As previously noted, we're making no such recommendation and that will
> be clarified.
"Attempts
Paul Hoffman writes:
> I'm not sure a standards track document that updates RFC 1034/1035
> should be recommending a minimum TTL.
As previously noted, we're making no such recommendation and that will
be clarified. The first definition of "resolution recheck timer" in
section 5 does already say
Following up on my previous message:
The document is actively confusing about recommendations.
- Section 4 has the actual update to the RFC 1035, and that update contains MAY
and SHOULD statements.
- Section 5 is called "Example Method" but also contains recommendations.
- Section 6, "Implemen
On Mar 1, 2019, at 9:33 AM, Dave Lawrence wrote:
>
> Bob Harold writes:
>> Will the "resolution recheck timer" cause ttl's less than the timer
>> to be effectively lengthened, by refusing to look them up again? I
>> think 'serve-stale' should focus on the situation where the auth
>> server is no
35 matches
Mail list logo
