Subject: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 15 Jun 2010 16:56:15 +0800

Dear all,

   new version of bname draft is published with some improved text and dnssec discussion.

  any comments are welcome.

thanks.

Jiankang Yao

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 15, 2010 9:30 AM
Subject: I-D Action:draft-yao-dnsext-bname-02.txt 

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Bundle DNS Name Redirection
> Author(s)       : J. Yao, et al.
> Filename        : draft-yao-dnsext-bname-02.txt
> Pages           : 12
> Date            : 2010-06-14
> 
> This document defines a new DNS Resource Record called "BNAME", which
> provides the capability to map itself and its subtree of the DNS name
> space to another domain.  It differs from the CNAME record which only
> maps a single node of the DNS name space, from the DNAME which only
> maps the subtree of the DNS name space to another domain.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yao-dnsext-bname-02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 16 Jun 2010 12:22:03 +0800

----- Original Message ----- 
From: "George Barwood" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 15, 2010 5:42 PM
Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt 

> The draft states
> 
> "Without the BNAME mechanism, current mechanisms
> such as DNAME or CNAME are not enough capable to solve all the
> problems with the emergence of internationalized domain names."
> 
> Can you give a more detailed account of what the problems are,
> and how they cannot be solved by other means?

there will have a new problem statement draft, which discuss the related situations.

I think that suzanne Woolf with co-author with me, xiaodong and Niall will update it soon.

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 16 Jun 2010 19:21:41 +0800

----- Original Message ----- 
From: "George Barwood" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 15, 2010 5:42 PM
Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt 

> As far as I can see, DNAME is capable of preventing an exponential increase
> in records, and the necessity of mirroring any data records in the zone apex
> that are not redirected by DNAME is a relatively minor administrative inconvenience,
> that can probably be mitigated by judicious use of the $INCLUDE directive.
> 

there is a dname discussion related to the draft http://tools.ietf.org/id/draft-yao-dnsop-idntld-implementation-01.txt
in dnsop list.  you may see it in dnsop list

> The draft does not seem to mention the incompatibility of BNAME with existing validating
> resolvers. I think some discussion of how a transition might be managed ( new algorithms?),

do you want to make the existing validating  resolvers to recognize the bname?
if yes, you need to update the validating resolvers to support bname.
if not, the  existing validating  resolvers will do it as if there were not bname.
so the draft said " In order to make BNAME valid in DNSSEC
   verification, the DNSSEC enabled resolvers and servers MUST support
   BNAME. "

your possible suggestion  ( new algorithms?) also need update the resolvers or servers.

if you doesn't update anything but make the existing validating  resolvers to recognize the bname, it seems to be impossible to do so.

do u have good idea about it?

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Jun 2010 07:37:28 +1000

> >   verification, the DNSSEC enabled resolvers and servers MUST support

Correct which is why we need to signal BNAME support with a algorithm number
change the same way as we did for NSEC3.
 
> This is an obstacle for the introduction of BNAME. If existing algorithms are used, then
> resolvers that have not been updated would get validation errors ( Bogus => SERVERFAIL ),
> since the CNAME records cannot be validated. This is almost certainly unacceptable.
> 
> If new algorithms are used, resolvers that have not been updated will get Insecure, which is probably
> more acceptable, but still a major disadvantage.

Which is what I've been recommending all along.
 
> Either way, a long time would have to elapse before (for example) the root zone could use BNAME,
> to allow people time to update their resolver software.

No.  Lots of validators out there don't support RSASHA256 but the
root is using that.  BNAME doesn't require resolvers to be upgraded for
it to be used. 

> I think relaxing the restriction on CNAME+DNAME, as per 
> 
> http://tools.ietf.org/id/draft-sury-dnsext-cname-dname-00.txt
> 
> may be a more practical way forward, since apparently it is not necessary in practice for resolvers to be updated.
> This assertion needs to be checked carefully - I have personally checked BIND and Unbound (via the public resolvers at https://www.dns-oarc.net/oarc/services/odvr ) and my own implementation, and they all appear to work fine. Only the authoritative server software need be updated, which is under the control of anyone who wishes to publish CNAME+DNAME.

CNAME+DNAME also has DNSSEC validation issues.  CNAME is used instead of a
NSEC to prove non-existance of the type.  Change the rules requires old
servers to send NSEC's as well as the CNAME records to answer DNAME queries.
 
> Regards,
> George Barwood

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Jun 2010 09:36:22 +1000

In message <C02599DCDCFD45408B3E56E853D617EC@local>, "George Barwood" writes:
> From: "Mark Andrews" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: "Jiankang YAO" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, June 16, 2010 10:37 PM

> I think the issue you are referring to is that if a cache has the CNAME cached, it will restart the query at
> the target and not return the DNAME that may be present (but not cached). That means that to reliably query for 
> [foo DNAME], you actually need to send a query [xx.foo A], and see if the DNAME is present in the response.
> It's a bit odd, but I think there are similar issues with NSEC/NSEC3. I don't see any big problem,
> since explicit DNAME queries are not needed in "normal" operation.

Just because they are not normally needed doesn't mean we should
not be able to cryptographicaly prove that the answer is correct
when they are made.

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 25 Jun 2010 17:28:55 +0800

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Jiankang YAO" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 17, 2010 5:37 AM
Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt 

> change the same way as we did for NSEC3.

I suppose the follow text to bname draft about the problem of unware validator trying to validating the bname:

In order to prevent BNAME-unaware resolvers from attempting to
   validate responses from BNAME-signed zones,
   this specification allocates two new DNSKEY algorithm identifiers.
   Algorithm X, DSA-BNAME-SHA1 is an alias for algorithm
   3, DSA.  Algorithm Y, RSASHA1-BNAME-SHA1 is an alias for algorithm 5,
   RSASHA1.  These are not new algorithms, they are additional
   identifiers for the existing algorithms.

   Zones signed according to this specification MUST only use these
   algorithm identifiers for their DNSKEY RRs. The BNAME-unaware
   resolvers will not know these new
   identifiers and treat responses from the BNAME
   signed zone as insecure, otherwise the bname RR will
  be regarded as bogus if there is no such a mechanism. 

   These algorithm identifiers are used with the BNAME hash algorithm
   SHA1.  Using other BNAME hash algorithms requires allocation of a new
   alias.
   Validating resolvers which follow the BNAME specification MUST
   recognize the new alias algorithm identifier.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 25 Jun 2010 17:01:25 -0400

A better solution is to put in the IANA considerations section
note like this:

ID-EDITOR: before this document goes to WG Last call list all DNSSEC
algorithms that need to be aliased to reflect compatibility with this
extension.

I have a strange felling that the list is going to be longer than 2 then.
It is a separate discussion to assess what algorithms need to be aliased.

	Olafur

On 25/06/2010 5:28 AM, Jiankang YAO wrote:
> From: "Mark Andrews"<[email-masked]>
> To: "George Barwood"<[email-masked]>
> Cc: "Jiankang YAO"<[email-masked]>;<[email-masked]>
>> In message<9497997BEBD1436AA9B3BB63A1DBB7D7@local>, "George Barwood" writes:
>>>> From: "George Barwood"<[email-masked]>
>>>> To: "Jiankang YAO"<[email-masked]>;<[email-masked]>

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 28 Jun 2010 10:22:49 +0800

----- Original Message ----- 
From: "Olafur Gudmundsson" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: "George Barwood" <[email-masked]>; "Mark Andrews" <[email-masked]>; <[email-masked]>
Sent: Saturday, June 26, 2010 5:01 AM
Subject: Re: [dnsext] bname new algorithm identifier

> algorithms that need to be aliased to reflect compatibility with this

thanks, I will add this text.

> It is a separate discussion to assess what algorithms need to be aliased.

not strange, 

Over time, sure, there will have more.