On 1 Nov 2015, at 3:36, Tim Wicinski wrote:
This starts a Working Group Last Call for
draft-ietf-dnsop-edns-chain-query
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/
Please review the draft and offer relevant comments. Also, if someone
feels the document is *not* ready for publication, please speak out
with your reasons.
I have read this document and believe it needs a bit more work. Sorry
for not reviewing this document earlier (e.g. before the wg last call).
Currently the document is marked “Standards Track”, but due to
lack of implementations at this time (though some are being worked), I
am suggesting we apply the “Experimental” label to this. The
working group is welcome to chime inhere.
According to RFC 2026 section 4.1.1, "Proposed Standard":
A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has
received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation.
I don't think a lack of implementation reports should be a deal breaker
for proposed standard. No doubt our illustrious AD could shed some light
here, however, since I am far from familiar with this stuff.
Suggestions
General
The introduction and overview are littered with phrases like
"stub-mode", "DNS client" and "host" that, because of the nineteen
different varieties of name server we have to deal with come across as
ambiguous. Worse, there are different world-views about DNSSEC
validation on end hosts, e.g. those that trust an unsigned AD bit,
expecting validation to occur upstream, and those who do validation
themselves.
I think the context of the whole document would be much easier to grasp
for a new reader if there was a clear diagram as close to the top of the
text as possible that clearly outlined the precise deployment scenario
we're talking about. I realise there is plenty of text that describes
the use case here, but starting with a picture I think would be a great
kindness to the reader.
Specification
The "Closest Trust Point (FQDN)" field in the EDNS(0) option as
described in section 4 is a bit vague, I think. You're talking about an
owner name, but you don't mention that phrase; you talk about "lowest"
without context (is the root at the top or the bottom?) You don't
specify the encoding of the owner name; I think it's natural to assume
that it's a series of run-length encoded labels with a zero-length label
indicating the end, but as written it could be taken as being in
presentation format with a trailing dot (a nod to the use of "FQDN"
which is generally in presentation format).
I have some reservations about the idea of inferring capabilities based
on previous experience interacting with a server at a particular
address. Authority servers are frequently built in clusters, and the
origin server that responds to one query at one address might be
different from the one that responds next time. Similarly, clients are
frequently deployed behind NATs, and inferring capabilities based on
source address there seems like a bad idea.
More fundamentally, I'm not sure I understand the benefit of
capabilities discovery. A client surely should add the option to all
queries; if it gets useful information back in the response it can use
it, and if it doesn't, it has to re-query along the chain anyway. If the
concern is related to dealing with servers that don't deal with unknown
EDNS(0) options correctly, then I think the preferred approach would me
to let them fail, forcing operator intervention on one or both sides.
Aside from capabilities disovery, I'm not sure what the purpose is of a
server including the CHAIN option in a response. The sections in the
response will either contain additional, useful information or they
won't -- it's not clear to me what benefit the CHAIN signalling from
server to client provides.
Section 5.4 indicates that extra RRSets included because of CHAIN
processing should be included in the authority section. Wouldn't the
additional section make more sense, except in the case of RRSIGs over an
NS RRSet?
Section 6.4 contains the intriguing word "partian" that I had not
encountered before, although I have to say I like it.
Section 8.1 uses the phrase "source IP address verification" which is
vague. Do you mean that the implementation needs to have convincing
indications that a query is not spoofed, e.g. by using DNS cookies? Or
do you mean that the server should not be an open resolver? Or that if
it's an open resolver, it should be operated mindful of the fact that
there is amplification potential?
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
