Re: [dns-dir] DNSEXT charter and treating DNS names as "the same"

Patrik Fältström <paf@cisco.com> Thu, 05 August 2010 05:26 UTC

Return-Path: <paf@cisco.com>
X-Original-To: dns-dir@core3.amsl.com
Delivered-To: dns-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCB23A69E6 for <dns-dir@core3.amsl.com>; Wed, 4 Aug 2010 22:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.194
X-Spam-Level:
X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 7OHWK1zH0OQB for <dns-dir@core3.amsl.com>; Wed, 4 Aug 2010 22:26:01 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C20153A6AA7 for <dns-dir@ietf.org>; Wed, 4 Aug 2010 22:25:46 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: PGP.sig : 186
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAAvoWUxAZnwN/2dsb2JhbACgNHGnZZskhToEiSU
X-IronPort-AV: E=Sophos; i="4.55,319,1278288000"; d="sig'?scan'208"; a="143561674"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Aug 2010 05:26:16 +0000
Received: from [192.165.72.14] (ams3-vpn-dhcp6582.cisco.com [10.61.89.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o755QFK7009752; Thu, 5 Aug 2010 05:26:15 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Apple-Mail-70--116418999"
From: Patrik Fältström <paf@cisco.com>
In-Reply-To: <20100805040358.GE37817@shinkuro.com>
Date: Thu, 05 Aug 2010 07:26:15 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <3BB283ED-30B2-4B9D-814C-8CD54B501370@cisco.com>
References: <20100805040358.GE37817@shinkuro.com>
To: Andrew Sullivan <ajs@shinkuro.com>
X-Pgp-Agent: GPGMail 1.2.3
X-Mailer: Apple Mail (2.1081)
Cc: dns-dir@ietf.org
Subject: Re: [dns-dir] DNSEXT charter and treating DNS names as "the same"
X-BeenThere: dns-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNS directorate discussion list <dns-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dns-dir>, <mailto:dns-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-dir>
List-Post: <mailto:dns-dir@ietf.org>
List-Help: <mailto:dns-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-dir>, <mailto:dns-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2010 05:26:07 -0000

I think this is fine. I still feel the title of the draft of Suzanne makes sense, and the problem I see is the following:

Given that someone has decided that resolution of A and B (and children of A and B) should result in the "same thing", how should the domain holder implement that?

Just by provisioning? Works if the there is the same registry for A and B, but otherwise it is very difficult.

I think personally your alternative four is probably "good enough for now" until we have more data. The problem in the live is that too many people still say "DNAME is dangerous -- do not use it" but I have not really seen any real evidence for problems with DNAME, specifically if one say DNAME is to be implemented only within one zone and similar restrictions. And of course it is easier when we have the push for DNSSEC.

So I think your note is good.

   Patrik

On 5 aug 2010, at 06.04, Andrew Sullivan wrote:

> [NOTE: Olafur & I send this to the directorate for comment before we
> send it to the WG.  If we hear nothing by Friday afternoon, we'll send
> this to the namedroppers list, and also send it (maybe with a
> background note) to the APP and INT area discussion lists.]
> 
> Dear colleagues,
> 
> One of our primary goals for DNSEXT at IETF 78 was to get feedback
> from the user community (in particular, application developers) who
> have the "aliasing" and "sameness" problem(s) with the DNS.
> Unfortunately, we were unable to attract many such participants. 
> 
> It is clear to us that none of the proposals now before DNSEXT
> addresses all the problems that people have.  As far as we are able to
> tell, there are needs with respect to domain names, with respect to
> whole trees in the DNS, and perhaps with respect to individual labels
> no matter where they might appear in a domain name.  None of the
> proposals handles all of these, and some of these needs are not
> addressed at all.
> 
> We appear to be faced with a choice among three basic strategies:
> 
>    1.  Experiment: Since we don't know what the problems are, but we
>    have people proposing solutions, we could adopt the proposed
>    solutions experimentally, and evaluate in (say) five years whether
>    the proposals solved the problems people have.
> 
>    2.  Limp along: We could accept that no proposal will solve
>    everything, and "limp along" by standardizing properly the
>    proposals we have, working towards clarity and precision in the
>    problem statement and then proceeding to work on the proposals
>    themselves.
> 
>    3.  Kick it upstairs: A basic problem in all of this is that the
>    DNS does not have a presentation layer.  Domain names end up being
>    used in presentation contexts, and that's what's broken.  So, we
>    could say that there is no problem here for the DNS, but that we
>    are ready and willing to support building a presentation layer
>    atop the DNS.  Such a specification needs to come from elsewhere.
> 
> The problem with (1) is that some of the proposals are simply
> impossible to do as experiments (if we change the rules for CNAME,
> they're effectively changed forever whether we like it or not).  In
> addition, we think it would be a very bad idea to perform such an
> experiment in the root, but we expect that there would be operational
> pressures to do so.
> 
> The problem with (2) is that we make the DNS more complicated without
> solving all or perhaps even most of the problems people really have.
> The complication will be greater than many people seem to think: for
> instance, the BNAME proposal as it is currently written is, as far as
> we can tell, simply incompatible with all the deployed validators in
> the world.  That seems like a problem that needs addressing, and we
> can't see how to do so easily.
> 
> The problem with (3) is that it was suggested before, and got no
> traction.  Moreover, it's very complicated, such that the work might
> never complete; and in the meantime, people who have a problem have no
> help.
> 
> We DNSEXT chairs are mostly convinced that there is no current
> proposal that is any simpler than just duplicating zone apex data and
> adding a DNAME to the "alias" zones.  (This suggests an option 4,
> which is "document how to do this by provisioning, thereby explaining
> why the WG is not doing anything else.)  Before we propose another
> charter for the WG, we'd like to hear more arguments why any work is
> needed, and which of the options 1-3 seem like the best bet for that
> work.
> 
> Best regards,
> 
> Andrew and Olafur
> 
> -- 
> Andrew Sullivan
> ajs@shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> dns-dir mailing list
> dns-dir@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-dir