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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
