Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document
Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 24 October 2011 22:50 UTC
Return-Path: <jhutz@cmu.edu>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C58111E81D3; Mon, 24 Oct 2011 15:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.249
X-Spam-Level:
X-Spam-Status: No, score=-107.249 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L6j9wsUbB0E; Mon, 24 Oct 2011 15:50:46 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 10B3511E81CD; Mon, 24 Oct 2011 15:50:42 -0700 (PDT)
Received: from [66.233.146.161] (66-233-146-161.pit.clearwire-wmx.net [66.233.146.161] (may be forged)) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p9OMoQWP023425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 18:50:28 -0400 (EDT)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Keith Moore <moore@network-heretics.com>
In-Reply-To: <28623_1319491641_p9OLRK2S028590_45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com>
References: <F2045A70-6314-41CF-AC3C-01F1F1ECF84C@network-heretics.com> <96472FB7-8425-4928-8F55-2ABF2CB59A93@conundrum.com> <628C128E-BDA8-46C3-BF07-364A482FE199@network-heretics.com> <20111024.080822.74700976.sthaug@nethelp.no> <59274CC1-611A-445B-A1CF-A0F49329DC1F@network-heretics.com> <E68B291B136EE9E8CFBF68F0@Ximines.local> <EEE0996F-FE4D-4ECF-A685-DD69DFCC87B9@network-heretics.com> <AFC2B32D1BE5A9E449B8D8A1@Ximines.local> <FAB38B5D-9B44-4B25-9268-9DE4A5DDC9FE@network-heretics.com> <4EA5D012.9090708@dougbarton.us> <28623_1319491641_p9OLRK2S028590_45E6700D-4207-4807-B8A4-2CFC56440038@network-heretics.com>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 24 Oct 2011 18:50:24 -0400
Message-ID: <1319496624.28149.399.camel@destiny.pc.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 8bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
X-Mailman-Approved-At: Mon, 24 Oct 2011 20:24:55 -0700
Cc: mif@ietf.org, dnsop@ietf.org, dnsext@ietf.org, Doug Barton <dougb@dougbarton.us>, pk@isoc.de, Alex Bligh <alex@alex.org.uk>, dhcwg@ietf.org, jhutz@cmu.edu
Subject: Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call for MIF DNS server selection document
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 22:50:47 -0000
On Mon, 2011-10-24 at 16:58 -0400, Keith Moore wrote: > On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > > > On 10/24/2011 05:16, Keith Moore wrote: > >> That's the point - search lists are not appropriate most of the time, and it's very hard for software to distinguish the cases where they are potentially appropriate from the cases when they're not, and it's not possible for software to do this in all cases. > > > > There's been something missing from this discussion, and I finally put > > my finger on it. TMK most stub resolvers have an option similar to this > > one from ISC's: > > > > ndots:n > > sets a threshold for the number of dots which > > must appear in a name given to res_query() (see > > resolver(3)) before an initial absolute query > > will be made. The default for n is “1”, mean‐ > > ing that if there are any dots in a name, the > > name will be tried first as an absolute name > > before any search list elements are appended to > > it. > > > > So it seems that this question is already a matter of local policy, > > which given the number and quality of the divergent views seems > > eminently reasonable. Can we move on now? > > No, because relying on "local policy" is not sufficient for interoperability. For interoperability, one can use absolute names, with the trailing dot, or specify that in the context of whatever protocol, all names are to be taken as relative to the root, or use other than a printed representation. In some cases this may require that implementations use resolver interfaces which make it clear that a name to be resolved is absolute, or that they append the empty label to relative names before passing them on to the resolver. On the other hand, in user interface, which is primarily where relative names are intended to be used, local policy is quite sufficient. As long as I and the software on my machine agree on what a name I type means, it's none of the IETF's business. Can an enterprise change the name of every domain name? On machines they control, yes. While I agree wholeheartedly with the notion of a unique domain name space, I also believe that mapping a relative or abbreviated name onto that namespace is _entirely_ a matter of local policy. It is perhaps appropriate for the IETF to provide mechanisms for distributing that policy, for those who wish to use them, but not to dictate what the policy must be. > I think there's a need for IETF to document why any other value than 1 > is a Bad Idea, and more to the point, why it will break things. It's not a Bad Idea, and it doesn't break things, or at least not so badly that the convenience isn't worth it. In this, I speak from years of operational experience, not only of personal use of also that of the many users of systems I operate support. Do things get worse as new TLDs appear? Yes, sometimes. Have we mostly had to abandon use of relative names ending in .cs and other two-letter suffixes? Yes, but we _mostly_ didn't use them anyway, due to our deep namespace and the appearance of those domains in our search list (here, "foo.bar" usually means "foo.bar.cs.cmu.edu"). Does that mean we're abandoning "options ndots:2"? Not aggressively. It has faded over time, but more due to a failure to actively apply it to newer systems than to any conscious decision that it's a problem. Further, given this position, I wonder why you think even a value of 1 is acceptable in the face of vanity TLDs. I know why I do, both from the perspective of an IETF (it's a local policy matter, period) and for myself (search for local names first, don't trust DNS results (yet) for security, and write absolute names when you want to bypass search lists). > The > problem isn't entirely specific to hosts with multiple interfaces. > But given that using multiple interfaces makes the problem worse, MIF > might want to take on some of the work of documenting why it will > break things. I can see how using an untrusted search list makes it worse. I can also see how using multiple sets of nameservers which provide different views of the namespace makes things worse, and I can see how using multiple interfaces makes this more likely. But, that has nothing to do with search lists and occurs even if every name is always treated as absolute. I can see two answers to this: 1) Use DNSSEC 2) Don't trust results from unsecured DNS for anything important. I fail to see how using multiple interfaces makes the problem worse, in itself. Can you elaborate? -- Jeff
- [mif] 2nd Last Call for MIF DNS server selection … Hui Deng
- Re: [mif] 2nd Last Call for MIF DNS server select… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Ray Bellis
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- [mif] bare names (was: [dnsext] 2nd Last Call for… Andrew Sullivan
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Keith Moore
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Andrew Sullivan
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Keith Moore
- Re: [mif] [dhcwg] 2nd Last Call for MIF DNS serve… Ted Lemon
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Margaret Wasserman
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Ted Lemon
- Re: [mif] bare names (was: [dnsext] 2nd Last Call… Keith Moore
- Re: [mif] [dhcwg] 2nd Last Call for MIF DNS serve… teemu.savolainen
- Re: [mif] [dhcwg] 2nd Last Call for MIF DNS serve… Ted Lemon
- Re: [mif] bare names Brian E Carpenter
- Re: [mif] [dnsext] [dhcwg] 2nd Last Call for MIF … Brian Dickson
- Re: [mif] [dnsext] bare names (was: 2nd Last Call… Mark Andrews
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… SM
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Brian E Carpenter
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Ray Bellis
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… David Conrad
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Mark Andrews
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … sthaug
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Brian Dickson
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Mark Andrews
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… teemu.savolainen
- Re: [mif] [dnsext] 2nd Last Call for MIF DNS serv… Brian E Carpenter
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Doug Barton
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Matthew Pounsett
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Alex Bligh
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Mark Andrews
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call … Donald Eastlake
- Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call … Mark Andrews
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Alex Bligh
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Alex Bligh
- Re: [mif] [DNSOP] [dnsext] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Doug Barton
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Keith Moore
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Doug Barton
- Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call … Keith Moore
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Mark Andrews
- Re: [mif] [dhcwg] [DNSOP] [dnsext] 2nd Last Call … Danny Mayer
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Lawrence Conroy
- Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call … Jeffrey Hutzelman
- Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call … Jeffrey Hutzelman
- Re: [mif] [dhcwg] [dnsext] [DNSOP] 2nd Last Call … Jeffrey Hutzelman
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Ted Lemon
- Re: [mif] [dnsext] [DNSOP] 2nd Last Call for MIF … Doug Barton
- Re: [mif] 2nd Last Call for MIF DNS server select… teemu.savolainen