IETF Logo Mail Archive

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

Ondřej Surý <ondrej.sury@nic.cz> Fri, 23 April 2010 16:44 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 C65F23A6A24; Fri, 23 Apr 2010 09:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.814
X-Spam-Level:
X-Spam-Status: No, score=-97.814 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_50=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 R6+utYsR+Umx; Fri, 23 Apr 2010 09:44:48 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A0FB3A69A2; Fri, 23 Apr 2010 09:44:48 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1O5LwO-000HAT-Ux for namedroppers-data0@psg.com; Fri, 23 Apr 2010 16:41:20 +0000
Received: from [2001:1488:800:400::400] (helo=mail.nic.cz) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <ondrej.sury@nic.cz>) id 1O5LwL-000H9J-Tw for namedroppers@ops.ietf.org; Fri, 23 Apr 2010 16:41:18 +0000
Received: from [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2] (unknown [IPv6:2001:1488:ac14:1400:ac14:1a29:0:2]) by mail.nic.cz (Postfix) with ESMTPSA id EB407734365; Fri, 23 Apr 2010 18:41:15 +0200 (CEST)
Message-ID: <4BD1CDAB.6080809@nic.cz>
Date: Fri, 23 Apr 2010 18:41:15 +0200
From: Ondřej Surý <ondrej.sury@nic.cz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Yao Jiankang <yaojk@cnnic.cn>
CC: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00
References: <4BC720DE.8080900@nic.cz> <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>
In-Reply-To: <472026586.10639@cnnic.cn>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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 23.4.2010 14:43, Yao Jiankang wrote:
>
> ----- Original Message -----
> From: "Ondřej Surý"<ondrej.sury@nic.cz>
> To: "YAO Jiankang"<yaojk@cnnic.cn>
> Cc: "Mark Andrews"<marka@isc.org>;<namedroppers@ops.ietf.org>
> Sent: Friday, April 23, 2010 5:37 PM
> Subject: Re: [dnsext] Fwd: New Version Notification for draft-sury-dnsext-cname-dname-00
>
>
>> On 23.4.2010 10:58, YAO Jiankang wrote:
>>>
>>>> So it looks like those two common existing implementation are already
>>>> ready for CNAME+DNAME.
>>>>
>>>> And that's exacly  my point - with very simple change in CNAME semantics
>>>> we can get full alias in the DNS tree, which is already supported by
>>>> majority of DNS servers in the wild (at least those supporting DNAME).
>>>>
>>>
>>> the CNAME is the basic record. many protocols base on it.
>>
>> That's not true.  No protocol I know except DNS rely on CNAME.  All
>> other protocols asks for A,AAAA (usually via getaddrinfo via your
>> resolver), MX, SRV, etc.  I am not aware of any protocol directly asking
>> for CNAME records.
>
> but many protocols will deal with the CNAME issues.
>
> for example RFC 2821 5321

I think that this part of SMTP standard is wrong.  Users (applications 
or end users) of DNS should not resolve CNAMEs on their own.  It should 
be handled either by full resolver or stub resolver in standard system 
library.

Anyway the only breakage which could happen (AFAIK) is when:

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.

In normal circumstances all cases will be handled by DNAME compatibility 
layer (ie. returning autogenerated CNAMEs), so I still don't see where 
the breakage can be.

Again I checked my MTA source code - postfix - there is not query cache 
in the code, there is no handling of DNAMEs, so I don't see how any 
breakage could occur by allowing CNAME+DNAME to live together.

>>> if you want to break CNAME,  you are trying to shake the basis of DNS.
>>
>> I am not breaking CNAME.  If you think I am breaking CNAME please prove
>> it or stop saying that.  I am enhancing CNAME semantics to allow
>> coexistence with DNAME.
>
> whether you use "breaking" or "enhancing",
> the fact is that you will change some rules set for CNAME.

I do, and I could change "enhancing" to "changing/modifying", but I am 
convinced that this change will have no bad impact on general internet, 
and I am not breaking CNAME in any way.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:ondrej.sury@nic.cz    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

v2.23.0 | Report a Bug | By Email