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

From: [email-masked]
Date: Mon, 21 Mar 2016 06:08:39 -0700

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-client-subnet-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 21 Mar 2016 19:21:59 +0530

Hi all

>    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

---

From: 神明達哉 <[email-masked]>
Date: Mon, 21 Mar 2016 11:38:35 -0700

At Mon, 21 Mar 2016 19:21:59 +0530,

> > for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and

I'm confused about the revised Section 7.2.1 regarding overlapping
prefixes.  The 07 version of the draft now states:

   [...]  Because it can't be guaranteed that queries for all
   longer prefix lengths would arrive before one that would be answered
   by the shorter prefix length, an Authoritative Nameserver MUST NOT
   overlap prefixes.

But the above "trivial example" seems to talk about what an
authoritative nameserver would do if it overlaps prefix...doesn't it
simply break the MUST NOT in the first place?

Also (ignoring the MUST NOT), what if a query is sent with a source
prefix 1.2.1/24?  The best matching prefix is 1.2.0/20, so isn't the
tailored response A with the scope prefix length of 20?  I mean,
shouldn't the above deaggregated prefixes be incomplete?

--
JINMEI, Tatuya

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 22 Mar 2016 01:15:48 +0530

Hi Jinmei

> simply break the MUST NOT in the first place?

When overlapped address prefixes occur in zone data (the configuration
provided by an administrator to the authoritative nameserver), the
authoritative server should resolve the overlap by deaggregating
prefixes such that the prefixes in the Authoritative Nameserver's reply
messages do not overlap.

The "Authoritative Nameserver MUST NOT overlap prefixes" requirement is
in the reply messages that it generates. But it can accept overlapping
prefixes as configuration and deaggregate to non-overlapping prefixes.

> shouldn't the above deaggregated prefixes be incomplete?

The 1.2.1/24 case would be covered by 1.2.0/23 listed in the example.
So a query with 1.2.1/24/0 would be replied to with 1.2.1/24/23.

If the auth had responded instead with 1.2.1/24/20, that would be cached
at address prefix 1.2.0/20 in the resolver's cache and a future query
for 1.2.3/24 would match it.

		Mukund

---

From: 神明達哉 <[email-masked]>
Date: Mon, 21 Mar 2016 18:22:52 -0700

At Tue, 22 Mar 2016 01:15:48 +0530,

> prefixes such that the prefixes in the Authoritative Nameserver's reply

At least to me, "MUST NOT overlap" can't obviously read that way.  I
think some more wording clarification is needed.  Also, what about
the "warn and continue" behavior of this one?

   2.  Alert the operator that the order of queries will determine which
       answers get cached, and either warn and continue or treat this as
       an error and refuse to load the configuration.

If it's not considered a violation of the MUST NOT, I think we need
more explanation here, too.

> So a query with 1.2.1/24/0 would be replied to with 1.2.1/24/23.

Ah, right, I should have had another cup of coffee before asking it:-)

--
JINMEI, Tatuya

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 22 Mar 2016 21:35:00 +0530

> more explanation here, too.

You're right. It should be described more clearly.

		Mukund