net: go resolver rejects response containing both CNAME and A for the same label

[mlh78750]

golang 1.7
linux 64

add entry in mac's /etc/host file for name.test.foo pointing to some ip address.
Start vmware fusion.
boot linux vm inside of vmware fusion.

write code that tries to resolve name.test.foo.
Will get failure with too many redirects.

What did you expect to see?

Expected it to resolve to the IP in the mac's /etc/hosts as that is what fusion's dns proxy thing sends for the request.

Fusion will return a DNS response with both a CNAME and an A RR in the response.

The code in dnsclient.go around line 75 doesn't check the number or records in the header and just looks at the first one. If it is a CNAME, it redirects and in this case gets the same response. rinse. repeat. until too many redirects.

While Fusion doesn't really need to send this CNAME record, the RFC allows multiple RR per header. And the answer that your looking for is in there just after the CNAME but golang jumps out as soon as it sees the CNAME RR.

[mlh78750]

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.

[quentinmit]

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.

[mlh78750]

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

[mlh78750]

Here is the offending response.

[mdempsky]

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.

[mlh78750]

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.

[mlh78750]

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