Subject: [DNSOP] draft-ietf-dnsop-edns-client-subnet-01

From: Dave Lawrence <[email-masked]>
Date: Fri, 12 Jun 2015 20:07:24 -0400

I'd like to call your attention to a few of the open issues called out
in the draft.

The first:

  The specific logic that an Authoritative Nameserver uses to choose a
  tailored response is not in the scope of this document.
  Implementers are encouraged, however, to consider carefully their
  selection of SCOPE PREFIX-LENGTH for the response in the event that
  the best tailored response cannot be determined. [Open issue: This
  seems so very vague; More text here about possible strategy?]

Does this need more text around the issues that should be
"consider[ed] carefully"?  Is the vagueness here acceptable?

Next up:

  When an Intermediate Nameserver uses ECS, whether it passes an ECS
  option in its own response to its client is predicated on whether
  the client originally included the option. Because a client that did
  not use an ECS option might not be able to understand it, the server
  MUST NOT provide one in its response. If the client query did
  include the option, the server MUST include one in its response,
  especially as it could be talking to a Forwarder which would need
  the information for its own caching. [Open issue: if the Forwarder
  sent 0s for FAMILY and ADDRESS, how could it take back a response
  with non-zero FAMILY and ADDRESS when the spec says this mismatch
  MUST be dropped?]

This issue basically centers around the protocol allowing for a query
coming into a recursive resolver to specify its own SOURCE
PREFIX-LENGTH to restrict how much of its address is exposed to the
authority nameservers.  If SOURCE PREFIX-LENGTH is 0, there is no
problem at all (because the resolver will then also still have 0 for
FAMILY and ADDRESS).  However, if say the originating query was from
1.2.3.4 and specified /16, the recursor would use 1.2/16 and when it
got the answer presumably need to communicate that back for suitable
caching.  However, per section 6.3 and section 10, if the FAMILY and
ADDRESS mismatch should cause the response to be dropped.

I'm not really sure to do about this.  One approach would be to allow
a client which sent out ECS solely to specify SOURCE PREFIX-LENGTH to
accept whatever family/address came back.  Another would be to just
remove the restriction for everyone that the response must match
family/address.  I'm not entirely convinced that having the
requirement is providing any sort of meaningful security benefit.
(See, for example, the note in 10.2 about how the requirement to treat
a missing ECS option in the reply as meaning that an attacker doesn't
have to worry about matching anything at all.)

Thoughts?

Next up:

  In the cache, all resource records in the answer section MUST be
  tied to the network specified by the FAMILY, ADDRESS and SCOPE
  PREFIX-LENGTH fields, as limited by the Intermediate Nameserver's
  own configuration for maximum cacheable prefix length. Note that the
  additional and authority sections from a DNS response message are
  specifically excluded here. Any records from these sections MUST NOT
  be tied to a network. [Open issue: this conflicts a bit with
  draft-kumari-dnsop-multiple-responses, which wants to put data in
  the additional section that an authoritative nameserver that does
  ECS would probably want to tailor.] 

Warren's other draft basically allows an operator to say "hey, when
I'm asked about www.example.com, I also want to immediately tell the
requester about {images,css,data}.example.com's addresses."  Obviously
a CDN would want those to be mapped as well.  Does that proposal need
to be reconciled with suitable text here regarding caching of the
additional section?  How?

I'm not sure why these sections are explicitly excluded from ECS
caching, other than perhaps the problem that already exists in even
just caching only the answer section, where only one ECS option is
available to cover multiple RRsets.  Given that the problem exists
regardless, should they be excluded?

Oh, I just realized that the problem I referring to is in text that is
not yet pushed out.  It says:

  Since some queries can result in multiple RRsets being added to the
  response, there is an unfortunate ambiguity from the original draft
  as to how SCOPE PREFIX-LENGTH would apply to each individual RRset.
  For example, multiple types in response to an ANY metaquery could
  all have different applicable SCOPE PREFIX-LENGTH values, but this
  protocol only has the ability to signal one.  The response SHOULD
  therefore include the longest relevant PREFIX-LENGTH of any RRset in
  the answer, which could have the unfortunate side-effect of
  redundantly caching some data that could be cached more broadly. For
  the specific case of a CNAME chain, the Authoritative Nameserver
  SHOULD only place the CNAME, likely with a SCOPE-PREFIX LENGTH of 0,
  to have it cached unambiguously appropriately. Most modern Recursive
  Resolvers restart the query with the canonical name, so the
  remainder of the chain is typically ignored anyway.

Remember, this draft is only attempting to document the existing
in-use protocol and some issues observed with it, and does not have
the latitude to fix the issues.

The final open issue called out in the current version:

  In other cases, Recursive Resolvers sited behind a NAT device SHOULD
  NOT originate ECS options with their external IP address, and
  instead rely on downstream Intermediate Nameservers to do so. They
  MAY, however, choose to include the option with their internal
  address for the purposes of signaling a shorter, more anonymous
  SOURCE PREFIX-LENGTH. [Open issue: this sounds like a configuration
  requirement, since a resolver might well not have any idea that it
  behind NAT.  Should this be described better?  Stricken?] </t>

As noted, I'm not sure the document should even be headed down this
rathole.  As phrased it is also making an unwarranted assumption, that
the resolver behind the NAT would even be talking to an intermediate
resolver; what if it's doing its own recursive resolution?

I understand the basic motivation in the original draft, not wanting
to have private address space uselessly going to the authorities.
(I'd bet our collective operational experience on the Internet is
almost certainly telling all of us that it is bound to happen anyway,
no matter what we say.)  But does an ECS resolver now need to know
whether it is going through NAT, when a resolver has never needed to
know that before?  Should this be hand-waved with something along the
lines of, "Recursive Resolvers behind NAT devices have complications
for ECS that are beyond the scope of this document."

Thanks for considering these issues.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 13 Jun 2015 08:24:57 -0700

> "consider[ed] carefully"?  Is the vagueness here acceptable?

This should be left unspecified (and the bracketed comment removed) for the simple reason that we don't know the basis of the DNS request. People here might be assuming "web query", but there are a lot of DNS requests that are not web queries. Further, once a DNS cache has a value that came from a web client, it will still serve that value for non-Web-client queries.

> have to worry about matching anything at all.)

The DNS protocol is meant to help applications get the information they need. Saying "you must ignore some information because we don't like it" goes against that basic principle. Allowing a client to accept a mis-match seems to be in the spirit of the DNS.

> the latitude to fix the issues.

Then don't. :-) If the WG adopts dnsop-multiple-responses, then that document should say what would be done with ECS. Trying to predict where a -00 draft might go is not a good use of our time.

> for ECS that are beyond the scope of this document."

The latter. Recursive resolvers that get their addresses from DHCP have no idea whether or not they are behind a NAT unless they try to map the address received against the still-changing list of addresses that might be NATish. And let's not forget IPv6, which will probably continue to have "creative" NAT solutions created for it for some time. It is better to say "this is a mess, do your best" and let the DNS servers that are using the information do their best.

> Thanks for considering these issues.

Thanks for continuing to work on this important document.

--Paul Hoffman