Changes

The use of CNAME records introduces complexities into this system that have yet to be ironed out. First, if a CNAME record is present at a node, there are supposed to be no other records for that node. So, if foo.bar.com is CNAMEd to foo.bar.org, there should be no other records for foo.bar.com, and in particular there will be no TLSA record. Thus, when a client connects to foo.bar.com, no DNSSEC chain appropriate for this system can be created. (Note that it may be the case that the prefix mechanism can be used to circumvent this issue. That is, there could be a TLSA record for _443._tcp.foo.bar.com. This however does not solve all of the issues.) One way to deal with CNAMEs is to essentially build one chain per CNAME. That is, if foo.bar.com is CNAMEd to foo.bar.org, then a chain for foo.bar.com will be constructed using the CNAME record, and then a chain for foo.bar.org will be constructed using the TLSA record for foo.bar.org. If and only if both of these chains verify correctly and the hostname matches that of the first chain will the information in the TLSA record be used in the TLS connection. This could even be extended to multiple CNAMEs. If foo.bar.com is CNAMEd to foo.bar.org is CNAMEd to foo.bar.cn, then three chains will be present. This introduces a trust issue, however. If foo.bar.com is CNAMEd to foo.bar.cn, anyone in those two hierarchies can masquerade as foo.bar.com. As before, the owners of bar.com, .com, and . can create valid DNSSEC chains that appear to come from foo.bar.com. However, unlike before, now the owners of bar.cn and .cn can do the same. More importantly, just by looking at the domain name "foo.bar.com", it is not apparent that anyone outside that hierarchy has this power, when in fact they do. The issue is that while the owner of foo.bar.com may be fine with this, visitors to that site may not be, and yet they have no indication that such a thing may be taking place. Thus, it is not clear that allowing this form of delegation is desirable for the end user.