On Wed, Sep 16, 2015 at 9:05 AM, Suzanne Woolf <[email protected]> wrote:
> This begins the working group last call for
> draft-ietf-dnsop-edns-client-subnet, "Client Subnet in DNS Queries.” The
> document has gotten significant feedback and the editors have worked hard to
> document current use of the client-subnet EDNS option.
>
> We’re seeking consensus to advance it to the IESG with an intended status of
> Informational. If you support it, please say so. If you don’t, please say
> why.
I'm not necessarily opposed to advancing it, but I have one high level
question. It would be nicer if it can be clarified before advancing
it: are we expecting newer implementations are developed based on this
specification, or is this document literally for describing the
current practice for the record (and newer implementations should
rather wait for more complete specification in the assumed revised
publication)? This point wasn't clear to me, and I hope it's more
clearly stated in the final version of the document. Also, if the
intent is the latter, I wonder we might rather avoid using RFC2119
keywords (but that's not a strong opinion).
Some more specific comments on the draft text follow, most of which I
think are minor and non-blocking:
- Section 4: the term "Forwarder" is used without a definition. I
think it's often confusing (different people tend to use it for
different meanings), so it would be better to give its definition
for the purpose of this document.
- Section 6
o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost
significant bits of ADDRESS to be used for the lookup.
I think it'll be more accurate if it says: "representing the number
of leftmost significant bits". Same for SCOPE PREFIX-LENGTH.
- Section 7.1.1
An ECS-aware resolver MUST retry the query without ECS to distinguish
the response from a lame delegation, which is the common convention
for a REFUSED status.
Is this true? To me it's a rather unusual choice to indicate a lame
delegation. For example, if I remember it correctly ISC BIND 9
returns SERVFAIL if all supposed-to-be-authoritative servers are
lame.
- Section 7.2.1
If the Authoritative Nameserver operator configures a more specific
(longer prefix length) Tailored Response within a configured less
specific (shorter prefix length) Tailored Response, then
implementations can either:
Just checking: is this an attempt to address the suboptimal scenario
I raised in my review of a previous version of draft?
- Section 7.4, first paragraph:
The prohibition against tying ECS data to records from the Authority
and Additional section left an unfortunate ambiguity in the original
specification, primarily with regard to negative answers. The
expectation of the original authors was that ECS would only really be
used for address records, the use case that was driving the
definition of the protocol.
The second sentence sounds a bit awkward to me, since the issue of
negative answers should basically be irrelevant to whether the query
is for "address records". Perhaps it's intended to explain the
background on the issue with delegation cases?
- Section 10
Special awareness of ECS in devices that perform Network Address
Translation (NAT) as described in [RFC2663] is not required; queries
can be passed through as-is. The client's network address SHOULD NOT
be added, and existing ECS options, if present, SHOULD NOT be
modified by NAT devices.
I'm not sure if I fully understand the second sentence. Does it
assume this NAT device acts as something like DNS-ALG? If so, I
think it's better to say so more explicitly (RFC2663 is quite
broad).
- Section 10
In other cases, Recursive Resolvers sited behind a NAT device SHOULD
NOT originate ECS options with their external IP address, and instead
Does this assume that the operator of the recursive resolver knows
it's behind a NAT and configures that way? If so, I'd suggest
stating that explicitly. In its current form it could read as if
the recursive server implementation somehow automatically detects
that it's behind a NAT (it might be possible but not very trivial),
and therefore sounds a bit awkward to me.
- Section 12.1
Additionally, Recursive Resolvers SHOULD be configured to never send
the option when querying root, top-level, and effective top-level
domain servers.
I suspect the meaning of term "effective top-level domain" is not
very clear (I actually have almost no idea about what it is -
something like "co.jp"?). If there's a reference I'd add it.
Otherwise, I'd explain what it intends to mean more specifically.
- Section 15: s/Internet Software Consortium/Infoblox/ (please keep my
current employer happier:-)
... Tatuya Jinmei from Internet Software Consortium;
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
