Re: [DNSOP] Another suggestion for "any"

Mark Andrews <marka@isc.org> Wed, 11 March 2015 23:23 UTC

Return-Path: <marka@isc.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 EDDC01A892E for <dnsop@ietfa.amsl.com>; Wed, 11 Mar 2015 16:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VpcCcKBNJchh for <dnsop@ietfa.amsl.com>; Wed, 11 Mar 2015 16:23:42 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344891A8924 for <dnsop@ietf.org>; Wed, 11 Mar 2015 16:23:42 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id A6B761FCACF; Wed, 11 Mar 2015 23:23:38 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DD9F7160067; Wed, 11 Mar 2015 23:30:41 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-175-41.carlnfd1.nsw.optusnet.com.au [211.30.175.41]) by zmx1.isc.org (Postfix) with ESMTPSA id AAD69160057; Wed, 11 Mar 2015 23:30:41 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3F7182B3E449; Thu, 12 Mar 2015 10:23:39 +1100 (EST)
To: Jared Mauch <jared@puck.Nether.net>
From: Mark Andrews <marka@isc.org>
References: <CAH1iCiqdZn10oB_vYh0ePXkaAwX_iY+No3XKyfqk_c3zJyFuAA@mail.gmail.com> <55000443.8020000@redbarn.org> <C6827F66-14DD-4267-A259-C05310B14889@vpnc.org> <20150311162220.GA18808@puck.nether.net>
In-reply-to: Your message of "Wed, 11 Mar 2015 12:22:20 -0400." <20150311162220.GA18808@puck.nether.net>
Date: Thu, 12 Mar 2015 10:23:38 +1100
Message-Id: <20150311232339.3F7182B3E449@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/-2M8-VHwRt4Iq3JZfTmylGGuF04>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [DNSOP] Another suggestion for "any"
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: <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, 11 Mar 2015 23:23:44 -0000

In message <20150311162220.GA18808@puck.nether.net>, Jared Mauch writes:
> On Wed, Mar 11, 2015 at 07:12:55AM -0700, Paul Hoffman wrote:
> > On Mar 11, 2015, at 2:00 AM, Paul Vixie <paul@redbarn.org> wrote:
> > > djb doesn't want QTYPE=ANY deprecated in any form.
> > > 
> > > olafur doesn't want to "do_ANY", under any conditions.
> > > 
> > > so i'm baffled by why you're offering this alternative?
> > 
> > Neither djb nor Olafur are automatically the consensus of this WG. None of 
> us are.
> > 
> 
> <mostly-ot>
> 	I've had trouble emailing djb about this and received bounces
> from his mailer, so feel trustrated trying to have a conversation that includ
> es
> him at least.
> </mostly-ot>
> 
> 	This does seem to fall into the whole "undefined" category just
> like many people feel that TCP is optional where my reading of 1035
> 4.2.2 defines how queries over TCP should be performed.

RFC 1123, Section 6.1.3.2 Transport Protocols, introduced the SHOULD with
the current well known description.

         *    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

If you read that along with Section 6.1.3.2 I don't see how any
vendor could ship a recursive DNS server that doesn't support TCP.
I can understand how you could ship a authoritative server where
you have full control over the data you are sending.

Mark

> 	At the most recent NANOG John Kristoff presented on the
> TCP part: 
> 
> https://www.nanog.org/sites/default/files/nanog63-dnstrack-kristoff-dnstcp.pd
> f
> 
> 	There is a gap, neither positive or negative in the behavior of
> these things, which I'm sure will rage along for a bit re: ANY, TCP, etc...
> 
> 	I'm working on a project right now that should collect some data
> and help better study the behavior of systems.  once it's ready, I will share
> more data.  If you are a researcher or PHD candidate interested in DNS,
> please contact me off-list.
> 
> 	- jared
> 
> -- 
> Jared Mauch  | pgp key available via finger from jared@puck.nether.net
> clue++;      | http://puck.nether.net/~jared/  My statements are only mine.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org