Aliasing a domain any implications for DNSSEC/DANE
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 tin this direction.
As an alternative I a considering using the same zone file for all three zones. 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?
-- John Allen KLaM ------------------------------------------ Save the whales. Collect the whole set.
On Fri, Jan 16, 2015 at 08:35:11AM -0500, John wrote:
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.
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.2When 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.
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! :-)
### 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.
Note at least in some cases, registrars create aliases between domains, these can even be DNSSEC validated:
$ dig +ad +noall +comment +ans -t mx nic.li. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16620 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; ANSWER SECTION: nic.li. 3599 IN CNAME switch.ch. switch.ch. 86400 IN MX 10 presunto.switch.ch. switch.ch. 86400 IN MX 20 jinhua.switch.ch. switch.ch. 86400 IN MX 20 bresaola.switch.ch. switch.ch. 86400 IN MX 10 elenski.switch.ch.
Though I must admit I don't know what it takes to register a domain as an alias to another rather than as a separate zone.
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.
Go ahead and do that.
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 don't think so. Any required recursion will be done by resolvers and applications.
++++ I had this wrong, recursion is not needed.
Correct, not in the sense of allowing recursive DNS queries.
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.
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.
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.
Is this the "best" way of aliasing? What gotchas should I be aware of?
Use CNAME and/or DNAME to alias either single domain name or sub-trees as you see fit.
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 (klam.biz and klam.ca). 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!!
On Sat, Jan 17, 2015 at 09:11:19AM -0500, John wrote:
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.
In that case, with care, you should be able to get away with a single source file for multiple domains.
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.
[ I meant "avoid the need for aliases", rather than "avoid aliases". Aliases are fine. ]
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 don't see why this follows. A CNAME from a signed into another signed zone "uses DNSSEC".
On 1/17/2015 12:31 PM, Viktor Dukhovni wrote:
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 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. 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
I have not tried it and my guess is that if it even passes validity checks it will produce unexpected consequences. In the mean time I will stick to the single zone file for the moment. Thanks on and all
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
does not work, I forgot that CNAME cannot have any other resource records associated with it, and a DNAME is a resource record.
Ah well!
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.
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.
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.
participants (2)
-
John -
Viktor Dukhovni