net: mishandling of dotted labels in domain names #10631
The DNS master zone and wire formats in RFC 1035 allow arbitrary binary strings within labels. This is explicitly reaffirmed in section 11 of RFC 2181: "Those [length] restrictions aside, any binary string whatever can be used as the label of any resource record. [...] Implementations of the DNS protocols must not place any restrictions on the labels that can be used."
However, currently the Go DNS resolver decodes DNS wire format domain names into dotted notation without accounting for dots within a label. For example, "dig" correctly resolves the following CNAME chain:
But this Go program:
fails on Linux with the output:
(I'm curious what it outputs on Windows and/or Plan 9, since Go uses the native OS resolver library on those platforms.)
Fixing net.LookupTXT would be relatively easy, but it's less clear what the other net.LookupFoo methods should return if they would need to return a dotted label to the caller.
For comparison, the BIND DNS client library's ns_name_ntop function uses RFC 1035 escaping: the "special" characters
In issue #1167, @rsc interpreted RFC 2181 as saying "clients can impose whatever restrictions they choose"** to justify disallowing querying arbitrary domain names. Taking that as precedent, it could instead be appropriate to make these functions return a similar "invalid domain name" DNSError if a dotted label is discovered. And relevantly, the BIND DNS client library returns "host not found" errors if during host name resolution it finds a CNAME record that points to a non-host-name. E.g., running
** Though I think that's a misinterpretation of "Clients of the DNS can impose whatever restrictions are appropriate to their circumstances on the values they use as keys for DNS lookup requests, and on the values returned by the DNS." I believe it's actually referring to how specific applications of DNS such as host name resolution might apply the stricter host name requirements from RFC 1123, even though domain names are more general. Notably, LookupHost and LookupIP are documented as resolving "host"s, whereas LookupMX, LookupNS, LookupSRV, and LookupTXT resolve "domain name"s.
The text was updated successfully, but these errors were encountered:
Ran into this writing a fuzzer for x/net/dns/dnsmessage, which exposes pack and unpack methods for DNS messages. In particular, a name like
To answer the past questions: I don't know of any evidence of it affecting real world applications. I think it would be reasonable to explicitly error when parsing packets that contain dots within labels. I think it's risky to mis-parse the packets though.