Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
net: target domain names in SRV records should not be compressed #10622
The current spec for SRV records (RFC 2782) says "Target: The domain name of the target host. [...] Unless and until permitted by future standards action, name compression is not to be used for this field."
The main way I've seen this manifest as a problem (not with Go specifically) is:
This fails because the client interprets the compressed domain name pointers as offsets into the intermediate server's DNS message, but they were actually computed according to the authoritative server's DNS message. With good luck, the client will notice they're obviously bogus and reject them; but it's also possible the pointers happen to look valid and the client ends up with subtly-bogus SRV records.
The Go standard library contains support for packing and unpacking of DNS messages, but it is not exported, doesn't follow Go style, and is not very well optimized. Low level DNS functionality is clearly useful to the Go community as evidenced by the success of github.com/miekg/dns. This implementation endeavors to avoid the limitations of both the standard library and github.com/miekg/dns implementations and is an almost complete rewrite of the code currently found in on net/dnsmsg.go and net/dnsmsg_test.go. Goals: * Minimize heap allocations. * Allow parsing only what is needed. Avoid unnecessary parsing and heap allocations for parts of the message that you don't care about. Parsing should be allowed on as small of a granularity as is useful, but no smaller as to avoid complicating the interface. * Parse and pack each byte of the message at most one time. Updates golang/go#16218 Updates golang/go#10622 Change-Id: Ib754d0007609a617d88be867f21c2feb15b6fcd7 Reviewed-on: https://go-review.googlesource.com/35237 Run-TryBot: Mikio Hara <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Mikio Hara <email@example.com>