Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00

Andrew Sullivan <ajs@shinkuro.com> Fri, 23 April 2010 17:11 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BE23A6829; Fri, 23 Apr 2010 10:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.018
X-Spam-Level:
X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1]
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 6pJNKiurEbLO; Fri, 23 Apr 2010 10:11:31 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8B9D3A6A59; Fri, 23 Apr 2010 10:11:30 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1O5MLl-000NNs-Nm for namedroppers-data0@psg.com; Fri, 23 Apr 2010 17:07:33 +0000
Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <ajs@shinkuro.com>) id 1O5MLj-000NNF-4x for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 17:07:31 +0000
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E19F31ECB400 for <namedroppers@ops.ietf.org>; Fri, 23 Apr 2010 17:07:29 +0000 (UTC)
Date: Fri, 23 Apr 2010 13:07:28 -0400
From: Andrew Sullivan <ajs@shinkuro.com>
To: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00
Message-ID: <20100423170728.GL3611@shinkuro.com>
References: <5C8B7499CFD24579BD7B75CB8050FDA1@local> <4BD0521B.9090803@nic.cz> <986F4044CBEE422BB769C7BA94B90BF2@local> <4BD064E4.9060700@nic.cz> <201004230031.o3N0VRQb069783@drugs.dv.isc.org> <4BD1558D.5090703@nic.cz> <472013124.07253@cnnic.cn> <472015463.07253@cnnic.cn> <472026586.10639@cnnic.cn> <4BD1CDAB.6080809@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4BD1CDAB.6080809@nic.cz>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On Fri, Apr 23, 2010 at 06:41:15PM +0200, Ondřej Surý wrote:
> I think that this part of SMTP standard is wrong.  Users (applications  
> or end users) of DNS should not resolve CNAMEs on their own.  

Woah, nelly.  Let's not put ourselves in the position of telling other
applications what they should or should not be doing with data in the
DNS, if for no other reason than that it runs exactly opposite to
years of other advice.

> a) MTA implements a query cache
> b) the query cache is very strict on CNAMEs
> c) mail is sent to target.dname.cz and CNAME for target.dname.cz is  
> stored in the cache
> d) mail is sent to www.target.dname.cz and the query cache tries to  
> store everything received (including the DNAME) into the query cache.
>
> => error is reported when storing the DNAME record into the query cache
>
> But I dare to say that such implementation of dns client is broken.

Why is it broken?  The CNAME rules say nothing else should be at the
CNAME.  Your proposal violates that rule.  You can't then say that
someone checking that the CNAME doesn't have anything else at that
name is actually broken: it isn't, at least today.

I'm not saying we shouldn't make this change to CNAME and DNAME, but
let us not dismiss the objection that we're making a change by begging
the question.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.