Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

[Mukund Sivaraman <[e-mail]>]

Hi all

On Mon, Mar 21, 2016 at 06:08:39AM -0700, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
>         Title           : Client Subnet in DNS Queries
>         Authors         : Carlo Contavalli
>                           Wilmer van der Gaast
>                           David C Lawrence
>                           Warren Kumari
> 	Filename        : draft-ietf-dnsop-edns-client-subnet-07.txt
> 	Pages           : 32
> 	Date            : 2016-03-21
> 
> Abstract:
>    This document describes an EDNS0 extension that is in active use to
>    carry information about the network that originated a DNS query, and
>    the network for which the subsequent response can be cached.  Since
>    it has some known operational and privacy shortcomings, a revision
>    will be worked through the IETF for improvement.

This revision is a welcome improvement on the previous revision of the
draft.

There are still some minor topics that need consideration (after
off-list discussions among people on the dnsop list). These have been
sent to the author. I'm listing them here for completeness:

(1) Section 7.2.1.  Authoritative Nameserver:

> When deaggregating to correct the overlap, prefix lengths should be
> optimized to use the minimum necessary to cover the address space, in
> order to reduce the overhead that results from having multipe copies
> of the same answer.  As a trivial example, if the Tailored Response
> for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then
> the Authoritative Nameserver would need to provide Tailored Responses
> for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and
> 1.2.3/24 to B.
			
This is a greatly improved description. It would be good to add here
that the authoritative server would also have to provide the following
*exact-match* tailored responses in ADDRESS/SOURCE/SCOPE syntax (for
corresponding ADDRESS/SOURCE queries):

1.2.2/23/24 pointing to A
1.2.0/22/24 pointing to A
1.2.0/21/24 pointing to A
1.2.0/20/24 pointing to A

which should be cached to exactly match the SOURCE prefix length.

(2) Section 7.3.2.  Answering from Cache:

> o  If there was an ECS option specifying SOURCE PREFIX-LENGTH but no
>    ADDRESS, the client's address is used but SOURCE PREFIX-LENGTH is
>    initially ignored. 

Wouldn't this be a FORMERR according to section 6 (option format)?

(3)

An authoritative server replies with SCOPE > SOURCE in some cases. This
is now described in detail in the -07 revision of the draft.

Let's assume a local resolver as SOURCE=16 configured as policy.  A
client 10.0.0.1 queries the resolver and the resolver's cache is
empty. The resolver queries a remote nameserver with 10.0.0.0/16 and the
auth server responds with 10.0.0.0/16/24.  It means that the answer is
strictly valid for 10.0.0.0/16 only, because it has a more specific /24
answer for some subnet under 10.0.0.0/16.

In this case, the resolver caches the answer at 10.0.0.0/16 with an
exact-match flag set to true.

Now assume that the same client 10.0.0.1 sends a second query to the
resolver for the same question. Now, these two cases can happen:

(a) the resolver looks in cache for 10.0.0.0/16 for a previously cached
answer because SOURCE=16 and finds the exactly matching answer.

(b) the resolver looks in cache for 10.0.0.1/32 and does not find the
previously cached answer.

It seems that (a) is the correct or desirable behavior. However, the
draft seems to suggest (b) which is not optimal. See section 7.3.2
(Answering from Cache):

> Cache lookups are first done as usual for a DNS query, using the
> query tuple of <name, type, class>.  Then the appropriate RRset MUST
> be chosen based on longest prefix matching.  The client address to
> use for comparison will depend on whether the Intermediate Nameserver
> received an ECS option in its client query.
>
> o  If no ECS option was provided, the client's address is used.

This should be updated to say something like "If no ECS option was
provided, the client's address and the value of its maximum cacheable
prefix length are used to construct an address prefix to search in the
cache".

(4)

This observation is from Stephen Morris:

From section 7.3.1 (Caching the Response):

> If SOURCE PREFIX-LENGTH is shorter than the configured maximum and
> SCOPE PREFiX-LENGTH is longer than SOURCE PREFIX-LENGTH, store SOURCE
> PREFIX-LENGTH bits of ADDRESS and mark the response as only valid to
> answer client queries that specify exactly the same SOURCE PREFIX-
> LENGTH in their own ECS option.
	       
When there are overlapping answers, and SCOPE > SOURCE is returned, if
the SOURCE PREFIX-LENGTH that is returned by the authoritative server is
the *shortest* prefix length of a more specific answer that the
authoritative server has under /SOURCE, the answer would be valid
not just for subsequent queries exactly matching /SOURCE, but
all the way from SOURCE to SCOPE-1.

Example 1:

(1) Let's say that for a question Q, the authoritative server has answer
A1 for /0, answer A2 for 10.0.0/24, answer A3 for 10.0.1/24.

(2) The caching resolver queries for Q with ECS=10.0/16. The
authoritative server returns 10.0/16/24.

Here, the answer is not just valid for 10.0/16, but also for 10.0.x/17,
10.0.x/18, ... 10.0.x/23 (where "x" address bits are don't-care bits,
i.e., they can be 0 or 1 valued). This is because /24 is the shortest
address prefix length under /16 for which the authoritiative server has
overlapping answers.

Example 2:

(1) Let's say that for a question Q, the authoritative server has answer
A1 for /0 and answer A2 for 10.0.0/20, and answer A3 for 10.0.0/24.

(2) The caching resolver queries for Q with ECS=10.0/16. The
authoritative server returns 10.0/16/20.

Here, the answer is not just valid for 10.0/16, but also for 10.0.x/17,
10.0.x/18 and 10.0.x/19 (where "x" address bits are don't-care bits,
i.e., they can be 0 or 1 valued). This is because /20 is the shortest
address prefix length under /16 for which the authoritiative server has
overlapping answers.

Depending on what the authors decide, the draft may be updated to permit
this case.

		Mukund