On Tue, Mar 26, 2019 at 2:19 PM Dave Lawrence wrote:
>
> On the other hand I have direct operational experience that says if a
> problem is being caused not by a generalized DOS or other transient
> network issue, then it can indeed take multiple days to resolve.
> Start of a long weekend?
On Tue, Mar 26, 2019 at 12:48 PM Tony Finch wrote:
>> I think the suggested max stale timer of 7 days is excessive. The aim is
>> to cope with an outage, so I think 1 day is much more reasonable (though I
>> have configured my servers with a 1 hour limit).
Olli Vanhoja writes:
> I agree. At
On Tue, Mar 26, 2019 at 12:48 PM Tony Finch wrote:
>
> Dave Lawrence wrote:
> > Ray Bellis writes:
> > > Serve stael must not become a vector whereby malware can keep its C
> > > systems artificially alive even if the parent has removed the C domain
> > > name.
> >
> > I wholeheartedly agree
Dave Lawrence wrote:
> Ray Bellis writes:
> > Serve stael must not become a vector whereby malware can keep its C
> > systems artificially alive even if the parent has removed the C domain
> > name.
>
> I wholeheartedly agree with this ideal, and am very open to
> considering text improvements.
Puneet Sood wrote on 2019-03-25 08:07:
Hi Paul,
On Sun, Mar 24, 2019 at 12:37 PM Paul Vixie wrote:
i object to serve-stale as proposed. my objection is fundamental and
goes to the semantics. no editorial change would resolve the problem.
i would withdraw that objection if this draft
Ray Bellis writes:
> Serve stael must not become a vector whereby malware can keep its C
> systems artificially alive even if the parent has removed the C domain
> name.
I wholeheartedly agree with this ideal, and am very open to
considering text improvements.
The document already has guidance
bert hubert writes:
> I too object. This is partially due to the apparently unresolved IPR issue
> from Akamai, who are known not to be shy asserting their IPR.
This is definitely a problem. Even though Akamai had previously
agreed to specify under what IETF-acceptable terms the IPR would be
Paul Vixie writes:
> i would withdraw that objection if this draft incorporates section 2 of
> https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit:
I always liked resimprove. Warren and I were talking about it, and if
you would like we'd be quite happy to pick it up and get it
On Mon, Mar 25, 2019 at 04:30:01PM +0100, Ray Bellis wrote:
>
>
> On 25/03/2019 16:08, Puneet Sood wrote:
>
> > you mean lots of changes or lots of agreement with the quoted text?
> > They mean very different things.
>
> I was agreeing with the quoted text - I believe that any serving of
>
On 25/03/2019 16:08, Puneet Sood wrote:
you mean lots of changes or lots of agreement with the quoted text?
They mean very different things.
I was agreeing with the quoted text - I believe that any serving of
stale records must be predicated on the presence of a valid delegation
from the
On 24/03/2019 12:36, Paul Vixie wrote:
in other words, we'd be negotiating for the right to re-interpret
existing signaling (the authority's TTL no longer purely governs the
data's lifetime) by insisting that the parent zone's delegating TTL be
given absolute power for revocation.
+lots
On Sun, Mar 24, 2019 at 04:36:50AM -0700, Paul Vixie wrote:
> i object to serve-stale as proposed. my objection is fundamental and goes to
> the semantics. no editorial change would resolve the problem.
I too object. This is partially due to the apparently unresolved IPR issue
from Akamai, who
i object to serve-stale as proposed. my objection is fundamental and
goes to the semantics. no editorial change would resolve the problem.
i would withdraw that objection if this draft incorporates section 2 of
https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit:
2.
Hi,
On 08/03/2019 21:29, Dave Lawrence wrote:
> Huh, My understanding from a hallway conversation with Benno was that
> the immediate response is only sent for names that would have been
> subject to pre-fetching, such that the immediate response in this case
> is sufficiently covered under the
Thank you very much for the feedback, Jinmei.
Combined with previous changes we made following the other messages on
the draft we expect to republish it before the Monday IETF 104
submission deadline, after one last review by all of the co-authors.
Jinmei:
>> The definition of TTL in [RFC1035]
I've read draft-ietf-dnsop-serve-stale-03. In addition to the
high-level draft organization matter I mentioned in another thread,
here are my other comments on this version:
- Section 4:
The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is
amended to read:
TTL [...] If the
16 matches
Mail list logo
