On Wed, Feb 25, 2015 at 12:24 PM, 神明達哉 jin...@wide.ad.jp wrote:
At Mon, 23 Feb 2015 15:23:23 -0500,
Warren Kumari war...@kumari.net wrote:
- Section 6.1
A Stub Resolver MAY generate DNS queries with an edns-client-subnet
option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to
Apologies to everyone for it having taken so long to address your comments.
I'm finally going through and trying to capture and incorporate comments.
Because we've taken so long to release an updated draft, making sure
we are capturing all the points if a bit tricky. In order to try avoid
having
I've read this draft again and my comments are below.
6.3. Handling edns-client-subnet Replies and Caching:
If the SCOPE NETMASK in the reply is longer than the SOURCE NETMASK, it
means that the reply might be suboptimal. A Recursive Resolver MUST return
this entry from cache only to queries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 18-02-15 18:19, Marcus Grando wrote:
If the SCOPE NETMASK in the reply is longer than the SOURCE
NETMASK,
it means that the reply might be suboptimal. A Recursive Resolver
MUST return this entry from cache only to queries that do not
Hello All,
Some time ago (when there was a Verisign coauthor on this draft) I was asked
to review it internally. I'm not sure if all of my comments were passed
back, so I am sending them here. Hopefully I have correctly accounted and
adjusted for changes between the current version and the one
At Thu, 8 Jan 2015 19:36:00 +,
Wilmer van der Gaast wil...@google.com wrote:
Re NETMASK: Yeah, sorry, poor choice of terminology early on in the
doc. Prefix length is the right term to use, it just felt like the
point was clear and it was too late to change it. But feel free, of
course,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/31/2014 08:31 PM, 神明達哉 wrote:
- Section 6.3
If the address of the client is within any of the networks in the
cache, then the cached response MUST be returned as usual. If the
address of the client matches multiple networks in the
At Thu, 08 Jan 2015 15:52:12 +0100,
Yuri Schaeffer y...@nlnetlabs.nl wrote:
If I understand this (and Section 6.3 in general), the following
suboptimal scenario could happen: - The Authoritative Server is
configured with two prefixes for optimized responses: 2001:db8::/32
and
Hello everyone,
Only just spotted this thread after a coworker pointed me at it. I
won't be able to follow up to everything, but will try to address some
of the questions.
Re NETMASK: Yeah, sorry, poor choice of terminology early on in the
doc. Prefix length is the right term to use, it just
On Thu, Jan 8, 2015 at 10:58 AM, jin...@wide.ad.jp wrote:
- Using my server side configuration example of 2001:db8::/32 and
2001:db8:2::/48 again. With this definition of SCOPE and caching
behavior at the Recursive Server, the Recursive Server would have
to cache separate responses for
Hi,
I have been reading this draft with a view to designing an implementation.
In an attempt to understand section 6 I tried to pull it apart in to
more sections. I have attempted to describe the behaviour of each possible
type of name server (e.g., auth, recursive, caching, forwarding, stub,
I've read the draft and have the following comments.
- Section 5
o SOURCE NETMASK, unsigned octet representing the length of the
netmask pertaining to the query. In replies, it mirrors the same
value as in the requests. It can be set to 0 to disable client-
based lookups,
12 matches
Mail list logo
