net: go resolver rejects response containing both CNAME and A for the same label #18108
Comments
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:
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. |
It hasn't been allowed since RFC 973:
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. |
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.
The text was updated successfully, but these errors were encountered: