Re: [DNSOP] Priming query transport selection

Olafur Gudmundsson <ogud@ogud.com> Wed, 13 January 2010 22:41 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625F93A6804 for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 14:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level:
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+b96Mg1RY0V for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 14:41:32 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 67FF73A67B0 for <dnsop@ietf.org>; Wed, 13 Jan 2010 14:41:32 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0DMfOO3070819; Wed, 13 Jan 2010 17:41:24 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001132241.o0DMfOO3070819@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 13 Jan 2010 17:41:14 -0500
To: Jim Reid <jim@rfc1035.com>, Alex Bligh <alex@alex.org.uk>
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <E87EE584-97B5-4FE8-B47D-21048A702B51@rfc1035.com>
References: <201001131823.o0DINxYv068180@stora.ogud.com> <555CFB98-BB21-4AD4-9D4A-3AF3BD98E4B2@rfc1035.com> <D9CCEA0D18D9D5B457A90853@Ximines.local> <631E7931-47D4-4AAF-B2C6-62DA6DA5A4CA@rfc1035.com> <CDE7E0414BC50C42E4FCC54F@Ximines.local> <E87EE584-97B5-4FE8-B47D-21048A702B51@rfc1035.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Priming query transport selection
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 13 Jan 2010 22:41:33 -0000

At 16:16 13/01/2010, Jim Reid wrote:
>On 13 Jan 2010, at 20:49, Alex Bligh wrote:
>
>>Current operational practice would result in DO clear packets
>>fitting within 4096 bytes, so no need for TCP when DO is clear.
>
>I don't think that's always the case Alex. See the lengthy discussion
>in this list about datagram fragmentation and broken middleware boxes
>that don't grok EDNS0. [Or do EDNS0 with a 512 byte buffer size.
>Sigh.] Mind you, some of those boxes will also barf on TCP DNS traffic.

EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations
will not send more even if client ask for it. Firewalls will
enforce this.


>>Thinking about it, a total prohibition (at MUST level) of using TCP
>>is probably a bit harsh given we don't even know they have UDP
>>connectivity. Perhaps "MUST issue the priming query *first*
>>over UDP", or use a SHOULD.
>
>SHOULD is more appropriate than a MUST IMO. If the resolver has a
>priori knowledge that UDP/EDNS0 will fail for some reason, forcing
>them to do that and then revert to TCP or whatever would be a Bad Thing.

We are talking about the priming query, assume no prior knowledge
only hints that the resolver is configured with i.e. the SBELT.

>The preferred approach might probably be along these lines:
>         [1] EDNS0 + DO with a buffer of 5-8K (ish)
>         [2] TCP + DO when [1] fails
>         [3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails
>         [4] EDNS0 (no DO) with a 1.5K (ish) buffer
>         [5] Vanilla UDP (no EDNS0) if [4] fails

1 is not an option

>I think it would be helpful if the guidance on priming queries was
>split into 3 categories: resolvers that speak DNSSEC, those that are
>not DNSSEC-aware but speak EDNS0 and resolvers that are ignorant of
>both protocols. They'd start at [1], [4] and [5] respectively in the
>scenario above. The optimal priming behaviour for each may well be
>different, particularly wrt EDNS0 buffer minima and maxima. It would
>be good to give an explanation for those buffer sizes too in case
>we've all forgotten about that when revisiting the issue 5-10 years
>from now.
>
>Perhaps the recommended resolver behaviour should apply to all queries
>and not just the priming query?

No the priming query is different from all other queries.
Yes there should be guidance on fall back for ENDS0 and that
should be discussed in the ENDS0bis document context.

         Olafur