net: a better builtin DNS stub resolver

[mikioh]

This is a meta bug for tracking the status of the issues regarding builtin DNS stub resolver.

• Refabrication
  • proposal: x/net/dns, vendor/golang.org/x/net/dns: new package #16218
• Transport
  • net: issue with DNS response > 512 bytes (cannot unmarshal DNS message) #21160
  • net: better DNS transport for builtin DNS stub resolver #23866
  • net: don't keep reading from UDP resolver after truncated packet #23873
  • net: support DNS-over-HTTPS #27552
• Labels
  • net: reject Lookup("www.google.com..") on all systems #7122
  • net: LookupSRV and search domains when name is empty #9391
  • net: mishandling of dotted labels in domain names #10631
  • net: target domain names in SRV records should not be compressed #10622
  • net: isDomainName rejects valid domains #17659
  • net: LookupHost IDN support #22782
  • proposal: net: add support for "let localhost be localhost" #22826
• RRs
  • net: go 1.11 DNS client incompatible with SRV records from kube-dns #27546
• Error handling
  • net: dns lookup sometimes fails with "no such host" when there are too many open files #18588
• Options
  • net: add EDNS0 support to builtin DNS stub resolver #6464
  • net: validate DNSSEC in Go's DNS resolver #13279
• Testing
  • net: more complete DNS stub resolver tests for uncommon scenarios #13295

[pemensik]

In my opinion applications should not do DNS over HTTPS directly, but should use integrated daemon caching responses. DNS over HTTPS or DNS over TLS has much higher overhead than simple UDP packets. Local daemon caching responses received over such channels should help to improve overall performance.

It is worth noting there are still non-DNS resolution protocols, like mdns provided by avahi. Those should be easy to use without specific support in end applications.

[msangel]

Looking for mDNS support aswell.
rclone/rclone#8152