Aliasing a domain any implications for DNSSEC/DANE

[John]

Hi,
this is about half of my original message, it looks as though the moths 
have been at it.

### My original message###

I have three domains two of which are effectively aliases for the other 
(klam.ca --> klam.biz and klam.com).

++++ poorly expressed klam.ca is my main domain, I would like the other 
two to be aliases.

Currently all three zones are DNSSEC signed, klam.ca has TLSA records 
for things like the email  system and some web services.
I would like to setup domain aliases  klam.biz and klam.com.

I originally thought of using DNAME records for the domain aliases and 
cname records for the TLSA records.

But for this to work I would need  to enable recursion on the 
authoritative server. I understand that for very good reasons this is 
considered a very
bad idea., therefor I wont go in this direction.

++++ I had this wrong, recursion is not needed.

As an alternative I am considering is using the same zone file for all 
three zones. I assume that I would need to turn off maintain and inline 
for the alias zones (klam.biz and klam.ca).
But this should mean that I only have maintain one zone file for all 
three domains.

Is this the "best" way of  aliasing? What gotchas should I be aware of?

### End of Original ###



### added since ###
I set up klam.biz with a DNAME to klam.ca and then ran the DNSSEC and 
ran dnssec-debugger at Verisign which produced a number of errors.
Which I think are related to how (at least my understanding of how) 
DNAME work, a DNAME applies to the sub-tree, while DNSSEC is at the 
domain level.
taking the example:
klam.biz   IN DNAME klam.ca

DNSSEC will try to find keys for klam.biz NOT klam.ca, which results in 
DNSSEC failure.
####

I had not got as far as looking at CNAME for TLSA records yet. I had 
thought of using it for WEB services (webdav, davical, ...)
>> I originally thought of using dname records for the domain aliases and cname
>> records for the TLSA records.
> You seem to be adding the list into the middle of a conversation.  Can you
> start at the beginning.  What are you trying to achieve?  Be specific.
>
>> But for this to work I would need  to enable recursion on the authoritative
>> server. I understand that for very good reasons this is considered a very
>> bad idea., therefor I wont go in this direction.
> Again, what are you talking about?  There are in fact valid
> deployments in which CNAME and DNAME records are used for TLSA
> records in the same way they work for any other DNS RRtype.
>
> CNAMEs are specifically recommended for certificate usage DANE-TA(2)
> configurations where the organization's issuing CA TLSA RRs are kept
> in one place, and CNAME aliases point there from multiple hosts.
>
>      https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.2
>
> When a host is an alias to another host, the same draft
> suggests that its TLSA records should automatically be sought there
> and this is required by the SMTP DANE draft.  So you don't need to
> do anything special for that.  However you can also:
>
> 	www.example.com. IN CNAME cdn.example.net.
> 	_tcp.www.example.com. IN DNAME _tcp.cdn.example.net.
>
>> As an alternative I a considering using the same zone file for all three
>> zones.
> I don't see how this changes much of anything.
>
>> I assume that I should only have maintain and inline on the main domain
>> domain entry in bind.
>> Is this the "best" way of  aliasing? What gotchas should I be aware of?
> The first gotcha is that we are not mind readers, and you should
> explain with some specificity what problem you're trying to solve.
>


-- 
John Allen
KLaM
------------------------------------------
we should be careful not to ascribe to malice what could equally be 
explained by incompetence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.sys4.de/cgi-bin/mailman/private/dane-users/attachments/20150116/b811f52e/attachment-0001.html>
-------------- 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/20150116/b811f52e/attachment-0001.bin>