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

[Mark Andrews <[e-mail]>]

In message <9497997BEBD1436AA9B3BB63A1DBB7D7@local>, "George Barwood" writes:
> > ----- Original Message ----- 
> > From: "George Barwood" <[e-mail]>
> > To: "Jiankang YAO" <[e-mail]>; <[e-mail]>
> > 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. "

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. 

> > 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?
> 
> 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: [phone]                 INTERNET: [e-mail]