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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
21 matches
Mail list logo