Aliasing a domain any implications for DNSSEC/DANE

[John]

On 1/17/2015 1:10 PM, Viktor Dukhovni wrote:
> On Sat, Jan 17, 2015 at 01:00:53PM -0500, John wrote:
>
>>> I don't see why this follows.  A CNAME from a signed into another signed
>>> zone "uses DNSSEC".
>> "from a signed into another signed" neither klam.biz or .com will be in
>> themselves signed, they will inherit the signing of klam.ca.
> No such "inheriting" is possible.  Each domain's DNSKEY, SOA and
> associated RRSIG records are its own.
Yep, I realized that shortly after I posted.
>> I did wonder about adding both a dname and a  cname for /klam.com /might
>> work.
>>
>> Something like:
>>
>> klam.com    IN DNAME klam.ca    # this handles the subtree of klam.com
>> klam.com    IN CNAME klam.ca    # this handles klam.com itself
> This is illegal.  You cannot combine CNAME records with records
> other than RRSIG and NSEC.  The DNAME is fine, but any records at
> the zone apex need to be duplicates, not CNAMEs.
>
> Only the ".com" registry can create a working CNAME from one .com
> domain to another.
>
Which leads me to the conclusion that it is not possible to have a what 
I consider a true alias, that is a situation where domain_B IS domain_A.
Had I thought this through a little more thoroughly I should have 
realized this. DNSSEC is designed to prevent  this sort of aliasing, 
after all what is a MITM attack but the presentation of domain_B as 
being domain_A.
Which in turn means that both domain_A and domain_B have to be 
separately signed, even if every sub level of domain_B is in fact 
provided by domain_A through a DNAME, thus allowing each domain to prove 
its legitimacy.

-- 
John Allen
KLaM
------------------------------------------
How many of you believe in telekinesis? Raise my hand...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4268 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.sys4.de/cgi-bin/mailman/private/dane-users/attachments/20150118/a3b7b62e/attachment.bin>