On Thursday, September 07, 2017 11:08:43 PM Joe Abley wrote:
> >> 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"?
> >
> > i don't think so. if it was "m
Apologies in advance for iPad MIME-crime. See below for crimes committed by
workman rather than tools.
> On Sep 7, 2017, at 21:37, Paul Vixie wrote:
>
> note, there's a proposal contained here.
>
> Jared Mauch wrote:
>>> On Thu, Sep 07, 2017 at 01:29:47PM -0700, Paul Vixie wrote:
>>> if the dr
In message
, Ted Lemon writes:
> The discussion had covered the failure mode problem. There is substantial
> agreement that it's better for a stub that issues a query for localhost to
> fail than to succeed. You seem to disagree.
There are lots of people that don't want to deal with ICANN politi
The discussion had covered the failure mode problem. There is substantial
agreement that it's better for a stub that issues a query for localhost to
fail than to succeed. You seem to disagree.
You haven't stated a reason for disagreeing—instead you've vigorously
asserted that this is true. It's fi
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
note, there's a proposal contained here.
Jared Mauch wrote:
On Thu, Sep 07, 2017 at 01:29:47PM -0700, Paul Vixie wrote:
if the draft being considered was clear on two points, i'd support adoption.
...
Would you see the querying application informing you of intent via
option code sayi
In message , Ted Lemon writes:
>
> On Sep 7, 2017, at 12:59 AM, Mark Andrews wrote:
> > I shouldn't BE FORCED to hard code special LOCALHOST rules into DNS
> > tools. Lookups should "just work" like they did before the root
> > zone was signed.
>
> Because...?
Because there are things you can
It's not sensible to presume the action of an independent
decision-making body. It's sensible to discuss it, but it should only
inform our own process logic, not decide it categorically (I think)
I might share your expectation of the outcome, but I would hesitate to
reject a draft on a supposition
On Thu, Sep 07, 2017 at 01:29:47PM -0700, Paul Vixie wrote:
> 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 m
add client-intent signalling, and irrespective add server signalling
of action, and I could be there.
I'd support adoption.
On Fri, Sep 8, 2017 at 6:42 AM, Paul Vixie wrote:
> On Thursday, September 07, 2017 11:33:22 AM 神明達哉 wrote:
>> ...
>>
>> If we don't work on a proposal like this, I'd love
On Sep 7, 2017, at 10:32 AM, Stephane Bortzmeyer wrote:
> draft-wkumari-dnsop-internal-00 proposes to reserve .internal for
> RFC1918-like domain names. There is clearly a strong demand for that.
> (There is also a strong demand for happy sex, great food, excellent
> wines and diamong rings, but
On Thursday, September 07, 2017 11:33:22 AM 神明達哉 wrote:
> ...
>
> 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 whe
there will be two replies here. one to wes, one to joe.
On Thursday, September 07, 2017 10:36:50 AM Wes Hardaker wrote:
> Stephane Bortzmeyer writes:
> > I'm not enthousiastic. We should focus on making the DNS
> > infrastructure more reliable, not on adding something to a pile of
> > already fra
At Thu, 07 Sep 2017 10:36:50 -0700,
Wes Hardaker wrote:
> > 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.
>
> I don't believe we have any ideas how to make infrastructure more
> reliab
On 09/07/2017 08:25 PM, Joe Abley wrote:
> 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 exp
On Thu, 7 Sep 2017, 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 con
On 7 Sep 2017, at 11:42, Stephane Bortzmeyer wrote:
> On Tue, Sep 05, 2017 at 03:25:39PM -0400,
> tjw ietf wrote
> a message of 77 lines which said:
>
>> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
>>
>> The draft is available here:
>> https://datatracker.ietf.org
Stephane Bortzmeyer writes:
> 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.
I don't believe we have any ideas how to make infrastructure more
reliable in the face of DDoS attacks. Is you
Stephane Bortzmeyer wrote:
On Tue, Sep 05, 2017 at 03:25:39PM -0400,
tjw ietf wrote
a message of 77 lines which said:
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/
I'm
On Tue, Sep 05, 2017 at 03:25:39PM -0400,
tjw ietf wrote
a message of 77 lines which said:
> 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/
I'm not enthousiastic. We sho
On Thu, Sep 07, 2017 at 11:21:07AM -0400,
Paul Wouters wrote
a message of 11 lines which said:
> > This way, requests for anything.internal which leaked at the root
> > would receive an insecure denial of existence (since there is no
> > DS for .internal). Problem solved, no?
>
> Wouldn't tha
On Thu, 7 Sep 2017, Stephane Bortzmeyer wrote:
This way, requests for anything.internal which leaked at the root
would receive an insecure denial of existence (since there is no DS
for .internal). Problem solved, no?
Wouldn't that be a secure denial of existence?
AFAIK, the root isn't using N
On Thu, Sep 07, 2017 at 04:32:39PM +0200,
Stephane Bortzmeyer wrote
a message of 57 lines which said:
> draft-wkumari-dnsop-internal-00 proposes to reserve .internal for
> RFC1918-like domain names.
And I forgot to say that it could be a good idea to add a reference to
draft-lewis-user-assign
On 7 Sep 2017, at 7:32, Stephane Bortzmeyer wrote:
The document clearly documents that it will not happen, since it
requires an entire new process at ICANN.
That is a non sequitur. ICANN regularly creates new processes at the
request of its communities.
--Paul Hoffman, not speaking for ICAN
draft-wkumari-dnsop-internal-00 proposes to reserve .internal for
RFC1918-like domain names. There is clearly a strong demand for that.
(There is also a strong demand for happy sex, great food, excellent
wines and diamong rings, but let's ignore it for the moment).
The document clearly documents t
On Sep 7, 2017, at 12:59 AM, Mark Andrews wrote:
> I shouldn't BE FORCED to hard code special LOCALHOST rules into DNS
> tools. Lookups should "just work" like they did before the root
> zone was signed.
Because...?
___
DNSOP mailing list
DNSOP@ietf.o
On 09/05/2017 09:25 PM, tjw ietf wrote:
> 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 wo
27 matches
Mail list logo
