Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mlh78750 opened this issue Nov 29, 2016 · 7 comments

Comments

Projects
None yet
4 participants
@mlh78750
Copy link

commented Nov 29, 2016

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

This comment has been minimized.

Copy link
Author

commented Nov 29, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Nov 29, 2016

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 quentinmit closed this Nov 29, 2016

@quentinmit quentinmit changed the title net: mishandling dns looking w/ multiple RR records where CNAME is first. net: go resolver rejects response containing both CNAME and A for the same label Nov 29, 2016

@mlh78750

This comment has been minimized.

Copy link
Author

commented Nov 29, 2016

@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

This comment has been minimized.

Copy link
Author

commented Nov 29, 2016

Here is the offending response.

dns-packet

@mdempsky

This comment has been minimized.

Copy link
Member

commented Nov 29, 2016

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

This comment has been minimized.

Copy link
Author

commented Nov 29, 2016

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

This comment has been minimized.

Copy link
Author

commented Nov 29, 2016

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

@golang golang locked and limited conversation to collaborators Nov 29, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.