libnetwork: get rid of truncation red herring

The TC flag in a DNS message indicates that the sender had to
truncate it to fit within the length limit of the transmission channel.
It does NOT indicate that part of the message was lost before reaching
the recipient. Older versions of github.com/miekg/dns conflated the two
cases by returning ErrTruncated from ReadMsg() if the message was parsed
without error but had the TC flag set. The version of miekg/dns
currently vendored no longer returns an error when a well-formed DNS
message is received which has its TC flag set, but there was some
confusion on how to update libnetwork to deal with this behaviour
change. Truncated DNS replies are no longer different from any other
reply message: they are normal replies which do not need any special-
case handling to proxy back to the client.

Signed-off-by: Cory Snider <csnider@mirantis.com>

libnetwork/resolver.go

@@ -509,9 +509,7 @@ func (r *resolver) forwardExtDNS(proto string, maxSize int, query *dns.Msg) *dns
 		}
 
 		resp, err = co.ReadMsg()
-		// Truncated DNS replies should be sent to the client so that the
-		// client can retry over TCP
-		if err != nil && (resp == nil || !resp.Truncated) {
+		if err != nil {
 			r.forwardQueryEnd()
 			logrus.WithError(err).Warnf("[resolver] failed to read from DNS server: %s, query: %s", extConn.RemoteAddr().String(), query.Question[0].String())
 			continue