On Wed, Sep 28, 2016 at 06:44:27PM +0200,
Ralf Weber wrote
a message of 26 lines which said:
> I consider anything in the cache where the TTL is still valid to be
> valid data that can be send to clients even if below the nxdomain
> cut. My understanding is that this is how the current draft i
On Tue, Sep 27, 2016 at 07:28:57PM +,
White, Andrew wrote
a message of 284 lines which said:
> True. When a resolver gets an NXDOMAIN for, say x.example.com, would
> it better to say the resolver SHOULD drop from cache all descendents
> of x.example.com, or MAY?
The current state of the d
On Tue, Sep 27, 2016 at 03:46:16PM -0700,
Matthew Pounsett wrote
a message of 137 lines which said:
> My rationale is that if foo.bar.example.org were still a valid name
By "valid name", do you mean "something which existed less than $TTL
seconds ago"?
> at the time that the bar.example.org
On Wed, Sep 28, 2016 at 01:42:19PM +,
Edward Lewis wrote
a message of 84 lines which said:
> As far as DNSSEC, this only works with DNSSEC in place, right? You
> need the missing span proofs or you are NXDOMAIN'ing entire zones,
> not just entire domains (within a zone).
This is covered
On Mon, Sep 26, 2016 at 05:42:31PM +,
Edward Lewis wrote
a message of 92 lines which said:
> For consistency, the SHOULD's in the first paragraph ought to be
> MAY's.
Process-wise, I don't think it is reasonable to ask for a change in
RFC2119 terms after the Working Group Last Call *and*
On Wed, Sep 28, 2016 at 2:37 PM, Matthew Pounsett
wrote:
>
>
> On 28 September 2016 at 10:29, Shumon Huque wrote:
>
>> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett
>> wrote:
>>
>>>
>>>
>>> On 28 September 2016 at 06:42, Edward Lewis
>>> wrote:
>>>
On 9/27/16, 18:46, "Matthew Pounset
On 28 September 2016 at 10:29, Shumon Huque wrote:
> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett
> wrote:
>
>>
>>
>> On 28 September 2016 at 06:42, Edward Lewis
>> wrote:
>>
>>> On 9/27/16, 18:46, "Matthew Pounsett" wrote:
>>> >Would it be better then to leave early expiry as an impleme
On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett
wrote:
>
>
> On 28 September 2016 at 06:42, Edward Lewis
> wrote:
>
>> On 9/27/16, 18:46, "Matthew Pounsett" wrote:
>> >Would it be better then to leave early expiry as an implementation choice
>>
>>
>> Ultimately, the goal of the draft is to t
On Wed, Sep 28, 2016 at 12:44 PM, Ralf Weber wrote:
> Moin!
>
> On 28 Sep 2016, at 17:21, Shumon Huque wrote:
> > To be precise, I would say we are not necessarily always pruning out
> entire
> > zones. For a leaf zone, we are pruning all names within that zone below
> the
> > nxdomain-cut, modul
Moin!
On 28 Sep 2016, at 17:21, Shumon Huque wrote:
> To be precise, I would say we are not necessarily always pruning out entire
> zones. For a leaf zone, we are pruning all names within that zone below the
> nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes,
> for non-leaf
On 28 September 2016 at 06:42, Edward Lewis wrote:
> On 9/27/16, 18:46, "Matthew Pounsett" wrote:
> >Would it be better then to leave early expiry as an implementation choice
>
>
> Ultimately, the goal of the draft is to tell a recursive server that if it
> can conclusively deduce existence of a
On Wed, Sep 28, 2016 at 9:42 AM, Edward Lewis
wrote:
> On 9/27/16, 18:46, "Matthew Pounsett" wrote:
> >Would it be better then to leave early expiry as an implementation choice
>
> I think it comes down to implementer's choice. The goal of the (IETF in
> general) documents is interoperability.
On 9/27/16, 18:46, "Matthew Pounsett" wrote:
>Would it be better then to leave early expiry as an implementation choice
I think it comes down to implementer's choice. The goal of the (IETF in
general) documents is interoperability. Whether or not a cache chooses to keep
the cached entries or r
On 27 September 2016 at 12:28, White, Andrew
wrote:
> Hi Shumon,
>
>
>
> True. When a resolver gets an NXDOMAIN for, say x.example.com, would it
> better to say the resolver SHOULD drop from cache all descendents of
> x.example.com, or MAY?
>
>
>
> It may be computationally expensive to search ca
On Tue, Sep 27, 2016 at 3:28 PM, White, Andrew
wrote:
> Hi Shumon,
>
>
>
> True. When a resolver gets an NXDOMAIN for, say x.example.com, would it
> better to say the resolver SHOULD drop from cache all descendents of
> x.example.com, or MAY?
>
>
>
> It may be computationally expensive to search
On Tue, Sep 27, 2016 at 3:10 PM, Shumon Huque wrote:
> On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew
> wrote:
>
>> Hi Shumon,
>>
>>
>> What about this?
>>
>>
>>
>> # When an iterative caching DNS resolver receives a response with RCODE
>> being NXDOMAIN,
>>
>> # the resolver SHOULD store the re
w
Cc: Edward Lewis; dnsop@ietf.org
Subject: Re: [DNSOP] Comment on section 2 of
draft-ietf-dnsop-nxdomain-cut-05.txt
On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew
mailto:andrew.whi...@charter.com>> wrote:
Hi Shumon,
What about this?
# When an iterative caching DNS resolver receives a r
On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew
wrote:
> Hi Shumon,
>
>
> What about this?
>
>
>
> # When an iterative caching DNS resolver receives a response with RCODE
> being NXDOMAIN,
>
> # the resolver SHOULD store the response in its (negative) cache. During
> the time the response
>
> # i
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Comment on section 2 of
draft-ietf-dnsop-nxdomain-cut-05.txt
On Tue, Sep 27, 2016 at 1:55 PM, Edward Lewis
mailto:edward.le...@icann.org>> wrote:
I'd written up a response, but perhaps the intent of the text is fine. The way
it is written is
On Tue, Sep 27, 2016 at 1:55 PM, Edward Lewis
wrote:
>
> I'd written up a response, but perhaps the intent of the text is fine.
> The way it is written is what is throwing me.
>
> Perhaps instead of this:
>
> # When an iterative caching DNS resolver receives a response NXDOMAIN,
> # it SHOULD
On 9/26/16, 20:49, "Mark Andrews" wrote:
>No. SHOULD is not MUST. Every SHOULD has a implict UNLESS
>. In this case we actually have a reason for
>the why the second and third SHOULD are not MUSTs.
>
>I could turn first SHOULD into a MUST and still reach the MAY.
I have to admit I
In message <29b4a430-80c7-44c8-a6fa-54a1560d3...@icann.org>, Edward Lewis writ
es:
> #2. Rule
> #
> # When an iterative caching DNS resolver receives a response NXDOMAIN,
> # it SHOULD store it in its cache and all names and RRsets at or below
> # that node SHOULD then be considered to be u
#2. Rule
#
# When an iterative caching DNS resolver receives a response NXDOMAIN,
# it SHOULD store it in its cache and all names and RRsets at or below
# that node SHOULD then be considered to be unreachable. Subsequent
# queries for such names SHOULD elicit an NXDOMAIN response.
#
# B
23 matches
Mail list logo
