Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-03.txt
Shane Kerr <shane@time-travellers.org> Tue, 06 October 2015 15:05 UTC
Return-Path: <shane@time-travellers.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C921B40BC for <dnsop@ietfa.amsl.com>; Tue, 6 Oct 2015 08:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDQLDpxZTbFy for <dnsop@ietfa.amsl.com>; Tue, 6 Oct 2015 08:05:11 -0700 (PDT)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B051B40BB for <dnsop@ietf.org>; Tue, 6 Oct 2015 08:05:11 -0700 (PDT)
Received: from 143-245-128-083.dynamic.caiway.nl ([83.128.245.143] helo=casual) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1ZjTnd-0006V2-Uq; Tue, 06 Oct 2015 15:05:06 +0000
Date: Tue, 06 Oct 2015 15:05:06 +0000
From: Shane Kerr <shane@time-travellers.org>
To: Paul Wouters <pwouters@redhat.com>
Message-ID: <20151006150506.1935afdc@casual>
In-Reply-To: <20151003203753.29292.37650.idtracker@ietfa.amsl.com>
References: <20151003203753.29292.37650.idtracker@ietfa.amsl.com>
X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Zt3wcEXvUp6kjsH0Q1eeDM2nObc>
Cc: dnsop mailing list <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2015 15:05:13 -0000
Paul, On Sat, 03 Oct 2015 13:37:53 -0700 internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations Working Group of the IETF. > > Title : Chain Query requests in DNS > Author : Paul Wouters > Filename : draft-ietf-dnsop-edns-chain-query-03.txt > Pages : 15 > Date : 2015-10-03 I think this draft makes sense - I like it. I see it was updated with basically no updates. Here are some thoughts. * Possibly running through a spell-checker would be useful, although not super important. * I note that the terminology section has been superseded a bit by the terminology draft, now approved for an informational RFC. I didn't follow that work too closely, but I notice that that document declares that "validating resolver" is referred to but not defined anywhere... and then uses the term "validating resolver" later in the document! :P Anyway, the soon-to-be-RFC still doesn't seem to define the two terms you want, so you may be stuck with defining them. You may want to also use "Forwarder" rather than "DNS Forwarder", as that seems to be what is in the terminology draft. * It's not clear whether answers should always be limited to TCP or something like DNS cookies, or whether this is only for answers more than 512 bytes. I assume always, but this text implies only sometimes: Servers answering with chain query data exceeding 512 bytes should ensure that the transport is TCP or source IP address verified UDP. See Section 8. This avoids abuse in DNS amplification attacks. Just remove "with chain query data exceeding 512 bytes" and it should be fine. * I guess that the "Last Known Query Name" disallows compression as part of a general rule for queries. That's fine. It might be worthwhile changing "No compression is allowed for this value." to say "No DNS name compression is allowed for this value." just to be completely clear. * The discovery mechanism seems to imply that a DNS Forwarder that has not done discovery MUST NOT use this option. My own feeling is that this is not true (a forwarder could just add the option to the first packet and do just-in-time discover, as it were). Perhaps this should be clarified? (Reading forward to section 5.3 shows that this is actually discussed!) * I don't understand the motivation for keeping query size to less than 512 bytes. I guess because there is no way in the protocol to specify support for larger query packets? It is a very rare case (I guess when the header+QNAME+EDNS option have long QNAME and long entry point), and seems unlikely to hurt anything in practice. If one wanted to be extra careful it could specify that UDP packets SHOULD limit packet size to 512 bytes - certainly this is unlikely to harm anything in TCP? (I suppose it is possible, but I'd like a check of a few popular servers before I am convinced. I suppose I can do this if you'd like...) * I'm not sure about handling large responses. The advice seems to be to to send a REFUSED response. Should a client try again without the EDNS option? There are other reasons for REFUSED, and maybe it makes more sense to have a way for a resolver to signal to the forwarder the reason for the refusal, so the forwarder knows this is the best way to react. * There doesn't seem to be advice for a resolver when support for Chain Query is disabled when it was previously working. Probably something like "A resolver MUST handle the case where a Chain Query does not return the full chain. It MAY change resolvers in this case. It MAY periodically attempt to try getting a Chain Query at that server." * A comment: It is possible for DNSKEY and RRSIG to time out at different intervals (and DS, I suppose), right?. It seems that this will result in a bit of extra data now and then, the resolver needs to specify an entire "last known query name". I think this is okay, but it might be possible to avoid this by specifying which particular records are needed. Probably that is unneeded complication for this case. * A wayward thought: this technique reveals a small amount of information about the cache on the forwarder side in the "last known query name". Maybe not worth mentioning because this is basically irrelevant when compared to, well, all the DNS resolution the resolver is doing? Anyway, I support it moving forward with or without any changes. Cheers, -- Shane
- [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-q… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cha… Shane Kerr
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cha… Paul Wouters
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cha… Paul Wouters
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-cha… Shane Kerr