the cgo resolver works in this case BTW. Just the go resolver fails. I've also opened an issue with the fusion team to try and get rid of the extra CNAME. But regardless, golang should do the right thing here.

Am I to understand that Fusion returns a CNAME and an A record both with the same name? That is in fact forbidden by the RFCs:

An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data. That is, for any label in the DNS (any domain name) exactly one of the following is true:
+ one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.

https://tools.ietf.org/html/rfc2181#section-10.1

If I've misunderstood the DNS response, can you provide the output of dig against this DNS server so I can see the records involved? Thanks.

@quentinmit: That is when DNSSEC is in use. And in this case it is not. It is permitted under older RFCs. Regardless, fusion shouldn't be doing it. But if DNSSEC is not in use it should work and does with the c resolver.

Here is the offending response.

It is permitted under older RFCs.

It hasn't been allowed since RFC 973:

UPDATES

   This section discusses changes to the specification which are final,
   and should be incorporated in all domain system software.

[...]

   CNAME usage

      The specification allows CNAME RRs to exist with other RRs at the
      same node.  This creates difficulties since the other RRs stored
      with the CNAME at the alias might not agree with the RRs stored at
      the primary name.

      If a node has a CNAME RR, it should have no other RRs.

The "dns.test.foo CNAME dns.test.foo" record seems extra invalid because RFC 1034 also says "CNAME loops [should be] signalled as an error".

I'm looking to see how libresolv handles this, but I'm really reluctant to try to match its behavior here because it seems very wrong.

Nevermind. Looks like this was clarified even for non DNSSEC in https://tools.ietf.org/html/rfc1912#section-2.4

I'm working on getting fusion to do the right thing. This might affect workstation as well in case anyone else stumbles onto this via a search.

I agree @mdempsky. Don't need to change anything on golang side. I'll get the fusion/workstation folks to fix this.