Published SRV records pointing to CNAME alias in violation of RFC 2782

cname-recorddomain-name-systemsrv-record

In the course of some work responsibilities I need to bone up on SRV records, and I'm trying to reconcile a Wikipedia statement with what I'm seeing in DNS digs.

According to Wikipedia's SRV record entry,

the target in SRV records must point to hostname with an address record (A or AAAA record). Pointing to a hostname with a CNAME record is not a valid configuration.

but I see records where dig returns an SRV record pointing to a name which is the alias in a CNAME record.

That is, something like this:

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

It seems like the SRV record is configured exactly the way the Wikipedia entry says is not allowed. What am I misunderstanding? Isn't it showing that the SRV record points at alias.domain.com, which has a CNAME record, not an address record?

Best Answer

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).

Related Topic