net: builtin DNS stub resolver returns query results including the second best records unconditionally #11081
Comments
|
Please try to reproduce with Go tip (Go 1.5). No further work is planned for Go 1.4. |
|
@bradfitz sure, I'll try with 1.5. My main goal is to make sure the bug is resolved if it still exists in 1.5, and the netgo resolver code still looks very similar to 1.4.2. I'll verify by testing with tip to make sure it hasn't been resolved in some way that isn't clear from a quick look at the code. |
|
/cc @mikioh |
|
The problem still exists in tip/Go 1.5: |
|
Where is the testdial code? |
|
https://gist.github.com/estesp/89ec461423e3d4e10ab4 package main
import (
"fmt"
"net"
"os"
)
func main() {
addrs, err := net.LookupIP(os.Args[1])
if err != nil {
fmt.Println(err)
os.Exit(1)
}
for _, addr := range addrs {
fmt.Printf("addr: %s\n", addr)
}
} |
mikioh
changed the title
|
CL https://golang.org/cl/10836 mentions this issue. |
mikioh
changed the title
|
CL https://golang.org/cl/10931 mentions this issue. |
|
@mikioh I see that Go 1.5 beta 1 is out--do we still think the resolver fix(es) can make Go 1.5? It would be very helpful to have proper IPv6/IPv4 response ordering and bug fixes in 1.5. |
|
I don't know, sorry. The project owners will decide. |
This change does clean up as preparation for fixing #11081. - renames cfg to resolvConf for clarification - adds a new type resolverConfig and its methods: init, update, tryAcquireSema, releaseSema for mutual exclusion of resolv.conf data - deflakes, simplifies tests for resolv.conf data; previously the tests sometimes left some garbage in the data Change-Id: I277ced853fddc3791dde40ab54dbd5c78114b78c Reviewed-on: https://go-review.googlesource.com/10931 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
|
CL https://golang.org/cl/12214 mentions this issue. |
net.LookupIP()program compiled both with-tags "netgo"and withoutsearch <somedomain>in your/etc/resolv.confand thenameserverin use needs to have a catch-all in the zone def'n responding with an AAAA record for all matches on*.somedomain.<somedomain>netgowill receive incorrect results from a DNS client lookup for this specific DNS server setup; for a real-world scenario see this issue in Docker, which is compiled statically with Go 1.4.2 with-tags "netgo": Go-lang "netgo" DNS resolver bug with catch-all DNS server entries moby/moby#10863While I would like to say I have the exact set of changes in
net/dnsclient_unix.gofigured out as to the difference, it seems to hinge on two things--one is that the requests to the nameserver now come from two different connections (source ports) from the Go resolver (because of the go routines used in 1.4.2 that aren't used in cgo, or in 1.3.3 cgo or netgo), and secondly, the initial AAAA response is not found instead of the nameserver doing a forward-request to upstream (e.g. Google public DNS) which you see in the 1.3.3 trace below. Whichever is the exact root cause, the result is that the 1.4.2 netgo code decides it is time to append the search domain and try again for the AAAA record, which hits the "catch-all" set up in the nameserver, which then responds with the catch-all AAAA record for that domain, which means a client may decide to select that as the valid response, when the hostname really has no AAAA record, but has a valid A record which is also returned.We can debate about the ugliness of catch-all entries in a DNS setup, but the root issue seems to be that netgo has different behavior in this particular scenario than cgo/libc and also from 1.3.3, not to mention we can't control whether certain users will have DNS configurations and backends beyond their control.
go 1.3.3 trace from a simple
net.LookupIP("index.docker.io"):go 1.4.2-netgo trace from a simple
net.LookupIP("index.docker.io"):Additional resources available--I have a container with the BIND setup shown above, as well as the simple program performing
net.LookupIP(). Also you can see moby/moby#10863 for further discussion although fair warning that some of it is off-track as the problem was being narrowed down.The text was updated successfully, but these errors were encountered: