On Wed, Feb 25, 2015 at 12:24 PM, 神明達哉 wrote:
> At Mon, 23 Feb 2015 15:23:23 -0500,
> Warren Kumari 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 indicate that
>> >
>> >
At Mon, 23 Feb 2015 15:23:23 -0500,
Warren Kumari 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 indicate that
> >
> > I'd suggest: s/i.e./e.g./ since this may also be an IPv6
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 t
-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 no
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 t
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 t
At Thu, 8 Jan 2015 19:36:00 +,
Wilmer van der Gaast 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, it's definitely
On Thu, Jan 8, 2015 at 10:58 AM, 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 all of the 64
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 felt
At Thu, 08 Jan 2015 15:52:12 +0100,
Yuri Schaeffer 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 2001:db8:2::/48 - Th
-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 c
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, et
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,
13 matches
Mail list logo
