Published SRV records pointing to CNAME alias in violation of RFC 2782?
The Wikipedia article you are quoting reports what the relevant RFC 2782 for SRV records states:
Target
The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181).
What you are seeing is a clear violation of the rules; however, it might work (and it usually does), if whatever client application is looking for that SRV record is smart enough to properly handle a CNAME record, even if it should only be expecting an A record in the response.
But it also might not work at all: it's unsupported and completely dependent on the client application; thus it should be avoided, because it's not following the proper rules and could lead to erroneous and/or unpredictable results.
This is similar to pointing a MX record to a CNAME, which is defined as just wrong in not only one, but two RFCs, and yet it's quite common practice (and no mail server seems to have a problem with it).
That's an example of the restricted behavior, yes. The restriction itself comes from RFC 2781 in the definition of "target":
Target
The domain name of the target host. There MUST be one or more
address records for this name, the name MUST NOT be an alias (in
the sense of RFC 1034 or RFC 2181). Implementors are urged, but
not required, to return the address record(s) in the Additional
Data section. Unless and until permitted by future standards
action, name compression is not to be used for this field.
A Target of "." means that the service is decidedly not
available at this domain.
DNS server software allowing forbidden configurations is nothing new, unfortunately. It can and does happen, as it does with other record types where aliased targets are forbidden such as NS
and MX
. (mentioned above)
Just because it can be found in the wild doesn't mean that it's "okay", and what happens when a standard is ignored varies from product to product. I haven't tested interaction with SRV
records, but a very well-known design decision by ISC BIND in regards to NS
records pointing at aliases is to drop the record entirely if found during recursion. If all NS
records get dropped in this fashion, the result of all queries will be SERVFAIL
for the subdomain in question.
In short, stick to the standard. It's the only safe thing to do.