Re: [dnsext] (BNAME) Naked domain resolution with DNSSEC

" Jiankang Yao " <yaojk@cnnic.cn> Sun, 27 October 2013 02:23 UTC

Return-Path: <yaojk@cnnic.cn>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA8011E8215 for <dnsext@ietfa.amsl.com>; Sat, 26 Oct 2013 19:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.389
X-Spam-Level:
X-Spam-Status: No, score=-99.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 0apFFe+oIueO for <dnsext@ietfa.amsl.com>; Sat, 26 Oct 2013 19:23:31 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 64F7221F9E89 for <dnsext@ietf.org>; Sat, 26 Oct 2013 19:23:29 -0700 (PDT)
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown127.0.0.1 (HELO smtpbg299.qq.com) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 27 Oct 2013 10:23:18 +0800
X-QQ-SSF: 0000000000000010000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 125.33.225.40
In-Reply-To: <20131025093648.GB12997@mx1.yitter.info>
References: <21069.41000.63116.736893@gro.dd.org> <F04702D34F7A2740A330302703120864384C8916@SINEX14MBXC421.southpacific.corp.microsoft.com> <21074.61535.976353.482373@gro.dd.org> <E66B38BB793BAF439EF374F3E7EBEE464B6202F6@SINEX14MBXC415.southpacific.corp.microsoft.com> <21095.58207.781300.353688@gro.dd.org> <E66B38BB793BAF439EF374F3E7EBEE464B620758@SINEX14MBXC415.southpacific.corp.microsoft.com> <C94CB03B-44C8-4792-9097-141D812EC01C@rfc1035.com> <E66B38BB793BAF439EF374F3E7EBEE464B620972@SINEX14MBXC415.southpacific.corp.microsoft.com> <21096.7524.908259.719737@gro.dd.org> <2013102517253369957870@cnnic.cn> <20131025093648.GB12997@mx1.yitter.info>
X-QQ-STYLE:
X-QQ-mid: webmail667t1382840588t2499544
From: Jiankang Yao <yaojk@cnnic.cn>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_526C790C_08EC2A60_1EB31163"
Content-Transfer-Encoding: 8bit
Date: Sun, 27 Oct 2013 10:23:08 +0800
X-Priority: 3
Message-ID: <tencent_7AE857AF44FCB1A53979D2D0@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 904426643
X-QQ-SENDSIZE: 520
X-QQ-FName: 8396CE3ABEA64EB58E2FC8473FB3E5A1
X-QQ-LocalIP: 163.177.66.155
Cc: Sourav Sain <sosain@microsoft.com>, "dnsext@ietf.org Group" <dnsext@ietf.org>, Thirunadha Reddy <thirunr@microsoft.com>
Subject: Re: [dnsext] (BNAME) Naked domain resolution with DNSSEC
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Oct 2013 02:23:37 -0000

I think that BNAME is compatible with DNSSEC. If you say BNAME is not compatible with DNSSEC, I think that it is due to protocol overhead.
 I suggest the following upadting to BNAME to reduce the protocol overhead:
  
  
If the query is a DNSSEC query, the BNAME enabled resolvers MUST set the UB (understand BNAME) bit in the query. The server receiving the UB bit MUST not issue synthesized CNAMEs or DNAME. Servers copy the UB bit to the response, and should delete the synthesized CNAMEs and DNAME from the answer if there has one. If the query is the DNSSEC query but the UB bit is not set, the server should follow the rules below:
 
a. If the owner name of the BNAME is same with the name queried, when preparing a response, a DNSSEC enabled server performing a BNAME substitution will not include the relevant BNAME  RR and its RRSIG RR in the answer section unless the type queried is BNAME . A CNAME RR with TTL=0 and its signed record will be included in the answer section unless the type queried is BNAME .
 
 b. If the owner name of the BNAME is the suffix of the name queried but not identical with the suffix, when preparing a response, a server performing a BNAME substitution will in all cases include the relevant BNAME RR in the answer section. A DNAME RR synthesized with TTL=0 and its signed DNAME RR are included in the answer section. This will help the client to reach the correct DNS data.

   
  
 Jiankang Yao

 

 ------------------ Original ------------------
  From:  "Andrew Sullivan";<ajs@anvilwalrusden.com>;
 Date:  Fri, Oct 25, 2013 05:36 PM
 To:  "Jiankang Yao"<yaojk@cnnic.cn>; 
 Cc:  "Dave Lawrence"<tale@dd.org>; "Kumar Ashutosh"<askuma@microsoft.com>; "Thirunadha Reddy"<thirunr@microsoft.com>; "dnsext@ietf.org Group"<dnsext@ietf.org>; "Sourav Sain"<sosain@microsoft.com>; 
 Subject:  Re: [dnsext] Naked domain resolution with DNSSEC

 

On Fri, Oct 25, 2013 at 05:25:48PM +0800, Jiankang Yao wrote:
> 
> BNAME, which directs both itself and its children, may solve it. the draft about BNAME was discussed 3 years ago.

> _______________________________________________

Yes, and if it were compatible with DNSSEC, perhaps people would have
pursued it.  But it won't work with DNSSEC.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com