Re: [dnsext] Name equivalence: No protocol change solution

fujiwara@jprs.co.jp Mon, 13 September 2010 11:44 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1E823A698B; Mon, 13 Sep 2010 04:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.08
X-Spam-Level:
X-Spam-Status: No, score=-98.08 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_36=0.6, J_CHICKENPOX_39=0.6, 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 N9+9cG5Rumbh; Mon, 13 Sep 2010 04:43:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7921B3A697B; Mon, 13 Sep 2010 04:43:58 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Ov7NU-000EXg-Kx for namedroppers-data0@psg.com; Mon, 13 Sep 2010 11:39:16 +0000
Received: from send12.jprs.co.jp ([2001:df0:8:6::72]) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.72 (FreeBSD)) (envelope-from <fujiwara@jprs.co.jp>) id 1Ov7NR-000EXJ-EY for namedroppers@ops.ietf.org; Mon, 13 Sep 2010 11:39:13 +0000
Received: from sendsms12.jprs.co.jp (sendsms12.jprs.co.jp [202.11.17.114]) by send12.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id o8DBclNU001073; Mon, 13 Sep 2010 20:38:47 +0900 (JST)
Received: from sendsms12.jprs.co.jp (unknown [127.0.0.1]) by sendsms12.jprs.co.jp (Symantec Mail Security) with ESMTP id 9BBEC338E; Mon, 13 Sep 2010 20:38:47 +0900 (JST)
X-AuditID: ca0b1172-0000000700000914-0a-4c8e0d462293
Date: Mon, 13 Sep 2010 20:38:46 +0900
Message-Id: <20100913.203846.59667019.fujiwara@jprs.co.jp>
To: alex@alex.org.uk
Cc: fujiwara@wide.ad.jp, namedroppers@ops.ietf.org
Subject: Re: [dnsext] Name equivalence: No protocol change solution
From: fujiwara@jprs.co.jp
In-Reply-To: <10C6B276E6E7A36DEEB147BA@Ximines.local>
References: <20100910.003741.276219111671353143.fujiwara@wide.ad.jp> <10C6B276E6E7A36DEEB147BA@Ximines.local>
X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
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/>

> From: Alex Bligh <alex@alex.org.uk>
>    OWNERNAME   IN   SNAME   TARGET
>    TARGET      IN   NS ...
>                IN   DS ...
> 
>> New DNS Server answers are:
>>
>>     QNAME            |          Answer
>>     -----------------+----------------
>>     OWNERNAME        |     OWNERNAME     IN CNAME TARGET
>>     SUB.OWNERNAME    |     SUB.OWNERNAME IN CNAME SUB.TARGET
>>     SUB.TARGET       |     TARGET IN NS + TARGET IN DS
>>     TARGET           |     TARGET IN NS + TARGET IN DS
>>     ...
>>
>> We can sign synthesized CNAME RR using RFC 4470.
>> It does not need new algorithm numbers.
> 
> I think you are not synthesizing NS/DS records or DNAME
> records for OWNERNAME (the 'copy').

Adding NS/DS with synthesized CNAME is OK, but not necessary.
Resolvers follow CNAME.

# Adding NS/DS with CNAME is very easy.

> The only NS/DS returned
> are for TARGET. You are synthesizing a CNAME for
> SUB.OWNERNAME and SUB1.SUB2.OWNERNAME even if SUB (in TARGET)
> would be beyond a zone cut.

if SUB.TARGET is zone cut, querying SUB1.SUB2.OWNERNAME is synthesized
"SUB1.SUB2.OWNERNAME CNAME SUB1.SUB2.TARGET" and the resolver can resolve
SUB1.SUB2.TARGET.

if SUB.TARGET is zone cut, querying SUB1.SUB.OWNERNAME is synthesized
"SUB1.SUB.OWNERNAME CNAME SUB1.SUB.TARGET" and the resolver can
resolve SUB1.SUB.TARGET even if SUB.TARGET is zone cut.

> If I am right about this, and OWNERNAME and TARGET are TLDs,

I intended that OWNERNAME and TARGET are second level domain name within 
a TLD which supports variant resolution.

> doesn't that mean that the TLD operator running OWNERNAME
> will have to do RFC4470 online signing for every query of
> every domain name within the OWNERNAME TLD?

the TLD's DNS server has to do RFC 4470 online signing for every query.

> To put it mildly,
> that would be a large increase in DNS traffic, and very expensive
> DNS traffic at that given the online signing requirement.

In my opinion, DNS traffic will not change because CNAME is cachable.

Online signing requirement is not so hard, I think.
Recent PC's CPU can sign 10000 RRs / sec (1024bit RSA).
Or using accelerator card solves performance problem.
We can write new DNS server and new online signer.

My program is very slow because it is written by perl.

--
Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>