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

;_https._tcp.alpha.domain.com.    IN    SRV

_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com

> dig alias.domain.com

;alias.domain.com.    IN    A

alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A
canonical.name.amazonaws.com. 35 IN A
canonical.name.amazonaws.com. 35 IN A

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?

  • 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 :)
    – olivierg
    Aug 1, 2017 at 19:47

2 Answers 2


The Wikipedia article you are quoting reports what the relevant RFC 2782 for SRV records states:


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

  • 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.
    – Andrew B
    Mar 23, 2016 at 22:57
  • 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
    Mar 23, 2016 at 23:02
  • 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.
    – Massimo
    Mar 23, 2016 at 23:04
  • 1
    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.
    – Andrew B
    Mar 23, 2016 at 23:06
  • 2
    Some mail servers started actively ignore MXes to CNAMEs, e.g. GMX medienconsulting.at/… Aug 22, 2017 at 14:14

That's an example of the restricted behavior, yes. The restriction itself comes from RFC 2781 in the definition of "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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .