net: go 1.11 DNS client incompatible with SRV records from kube-dns

[jnewmano]

What version of Go are you using (go version)?

go1.11

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

linux amd64

What did you do?

Running the following application in Kubernetes exits with an error:

https://play.golang.org/p/EW5NVeHJMrV

What did you expect to see?

Expected to get SRV records back

What did you see instead?

When running in Kubernetes with kube-dns 1.14.10 the application exits with error: "cannot unmarshal DNS message" (underlying error is "Target: compressed name in SRV resource data")

https://play.golang.org/p/EW5NVeHJMrV

A pcap of the DNS request: https://github.com/jnewmano/kube-dns/blob/master/dns_111_2.pcap

When built with Go1.10, it behaves as expected.

Golang-nuts discussion https://groups.google.com/forum/#!searchin/golang-nuts/dns%7Csort:date/golang-nuts/vAbjprJNPV0/HSh9635hBQAJ

[andybons]

@mikioh

[jnewmano]

kube-dns 1.14.11 has now been tagged. This version works with go1.11

https://github.com/kubernetes/dns/releases/tag/1.14.11

[paddycarver]

I'm not sure if this is the same underlying issue, but SRV responses from systemd-resolved can't be parsed on ubuntu 18.04, and return the same error message (though I'm not sure how to get to the underlying error message, unfortunately). go test . within the net directory fails with the mentioned error. Disabling systemd-resolved and setting the DNS server to 8.8.8.8, then running go test net passes, as expected.

[iangudger]

This was an intentional change. See #10622.

[mikioh]

For what it's worth, the reason I requested to file this issue is that I guess this could be a roadblock for operating DNS-SD in near future. Nowadays DNS-SD is becoming important not only for consumer plug-and-pray-or-play use but for label distribution over unicast DNS with k8s-like scheduler stuff. As described in RFC 8222, we still don't see the end of the label handling conflict between classical/conventional unicast DNS, and latest unicast and/or multicast DNS and DNS-SD, but need to find out a comprimise for both use cases.

One easy option would be just adding a control knob to net.Resolver and x/net/dnsmessge package without changing the current defaut, classical/conventional unicast DNS, behavior in the net package of standard library (see also #24870).

[iangudger]

Doesn't the DNS client in the standard library only support unicast DNS? Multicast DNS is different in a number of ways. For example, I believe the way that it uses the truncated bit is incompatible with our DNS client.

SRV records in unicast DNS must not be compressed. DNS servers which compress SRV records are either broken or doing multicast DNS.

[jnewmano]

A line item in the go1.11 release notes and a control knob to continue permitting non compliant DNS SRV responses would have been sufficient for us to have a smooth upgrade to 1.11.

[iangudger]

@jnewmano I agree that mentioning the DNS changes in the release notes would have been nice.

[mikioh]

Doesn't the DNS client in the standard library only support unicast DNS?

Yup, basically we don't want to bring fancy and complicated features into the "built-in" DNS stub resolver in the net package, though, GODEBUG=netdns=cgo allows to use the external stub resolvers.

SRV records in unicast DNS must not be compressed.

For now, I agree with you, but won't ignore the https://tools.ietf.org/html/draft-ietf-dnssd-hybrid endeavor in near future.

[iangudger]

The reasoning for rejecting these malformed responses was laid out in #10622.

[iangudger]

It appears that this issue has been fixed on the kube-dns end. Does anyone know if this is still an issue?

[andybons]

@mikioh what do you think?

[gnydick]

It's still an issue as long as the language != the ability of dig. That should be the barometer. Everyone and their uncle is going to say "man, dig works, but my software doesn't. WTF?"

…

On Sun, Aug 18, 2019, 3:46 PM Andrew Bonventre ***@***.***> wrote: @mikioh <https://github.com/mikioh> what do you think? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#27546?email_source=notifications&email_token=AACFHRHCDKKPCPSMM43MN23QFHGMJA5CNFSM4FTXNSL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4RKFZQ#issuecomment-522363622>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACFHRHYQZLG5WIZA4IIRYDQFHGMJANCNFSM4FTXNSLQ> .

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[strk]

I also think behavioral difference with dig should be taken into account