Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

["Joe Abley" <[e-mail]>]

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