Aliasing a domain any implications for DNSSEC/DANE

John john at
Sat Jan 17 15:11:19 CET 2015

On 1/16/2015 12:17 PM, Viktor Dukhovni wrote:
> On Fri, Jan 16, 2015 at 11:59:41AM -0500, John wrote:
>> this is about half of my original message, it looks as though the moths have
>> been at it.
> That's a relief, at least you tried to give us some context! :-)
Yep, it looks as though my (now) previous router was glitching!
>> 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 ( and
>> But this should mean that I only have maintain one zone file for all three
>> domains.
> Using a single source file may work, but the DNSKEY, RRSIG and
> NSEC3 records have to be external to that file (as with auto-maintain
> in BIND) and merged in as part of building the signed zones.
They already are, as I am using maintain and inline signing.
> BIND 9.10.1 or 9.9.6 or later should be able to do this, and avoid
> aliases if all three zones are intended to look identical, but this
> requires some careful analysis to make sure you never need any
> non-DNSSEC differences of any kind.
The more I think about it the less need for aliasing I see. Neither 
alias accepts email (SPF, DMARC are (will) be setup to indicate this) 
any services that might be duplicates can be handled by a CNAME pointing 
to the equivalent service in active domain.
The only down side that I see is that the aliases will not themselves be 
using DNSSEC. I am not sure this matters as "real" services will.

I think I will do a little experimenting!!
John Allen
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: <>

More information about the dane-users mailing list