Moin! On 21 May 2014, at 10:50, Klaus Malorny <klaus.malo...@knipp.de> wrote: > please take into account that a CNAME + DNAME, the previously discussed BNAME > or the now discussed ENAME solution is still interesting for domain name > registries that have to deal with (maybe lots of) IDN variants. I don't think > that SRV records are a viable solution for their use case. A combination of DNAME (which exists) and SRV should work or? But am not sure if it is a good thing.
Just let me give you an operational subjective observation from dealing with certain kinds of *NAME based redirection over 20 years running DNS servers. They caused mostly grief and problems since they been around. This of course is caused by the different semantics (a CNAME redirects every record type, and thus their can't be another record type at that node) compared to other resource records, that even the authors of some software did not understood (some versions of bind could load CNAME and other data at the same node). Once people understood this DNSSEC came around and changed that assumption again as even a CNAME needs signatures. Oh and then came DNAME for redirecting whole domain trees and that might have been a nice idea if I have a couple of domains and want them all to have the same data. But I do not know of Registries/Registrars that picked that up. Or is there widespread deployment? Now having an ENAME that initially will break all existing DNSSEC resolvers (Who can't validate any longer, because they don't support the algorithm yet) is IMHO not the right message when we want people to deploy DNSSEC and especially do validation. SRV has been defined for some time, there are applications using it and the application we are most interested in the Browser has a much shorter update cycle than the typical DNS Infrastructure, so why not use it, as they fallback/backwards compatibility mechanism also is there and understood (publish an A/AAAA record). So lets go for it. SO long -Ralf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
