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

Question

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?

Solution 1

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

Solution 2

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.

Comments

[olivierg]

in my company we use SRV records a lot, and most of them are using CNAMEs and it works fine, so against the rules or not, it works nicely :)

[Andrew B]

Keep in mind that "smart enough" is relative. Some software designers are of the mind that putting up with braindead implementations only encourages more implementations of the same. RFC 2781 has only been updated by a single RFC and the language about what to expect is very firm, so I would not expect much mercy here.

[Massimo]

Most client applications just rely on system libraries to perform DNS queries, and most libraries (especially in higher level languages) will try their best to resolve whatever query you throw at them, and will happily and silently follow a CNAME to its destination A record and IP address.

[Massimo]

The application doesn't need much smartness, it will simply ask the O.S. to connect to "alias.domain.com" on port 4443 and leave all details to it.

[Andrew B]

The client application and system libraries won't have the opportunity to follow the alias if the upstream recursor rejects the authoritative data and refuses to continue. (which is the relative smartness I was referring to) BIND's handling of NS records and forbidden aliasing is the classic example of this. Regardless, we're agreed that it's anyone's game with unpredictable results.

[Simon Catlin]

Agree that it normally works, but its not recommended, as CNAME records often get removed without regard for bigger impact.

[Marcel Waldvogel]

Some mail servers started actively ignore MXes to CNAMEs, e.g. GMX medienconsulting.at/…