On Jun 12, 2015, at 5:07 PM, Dave Lawrence <t...@dd.org> wrote:
> 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?
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.
>
> 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?
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.
> 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.
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.
>
> 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."
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
