[go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ndots behavior seems wrong #1198

Closed
rewiko opened this issue Dec 7, 2020 · 6 comments
Closed

ndots behavior seems wrong #1198

rewiko opened this issue Dec 7, 2020 · 6 comments

Comments

@rewiko
Copy link
rewiko commented Dec 7, 2020 •
edited
Loading

Hi,

I have been using this library to resolve kubernetes.default with ndots config set to 1, and I was expecting to get a NXDOMAIN response but I actually got a NOERROR because this function seems to append the search domain even if the ndots is set to 1 and the hostname contains 1 dots.

I have tested the behavior with nslookup, dig and host on alpine (musl) and ubuntu (libc) and they all honor the ndots and does not append the search domain.

I think it would make sense to have

  dotCount := CountLabel(name) -1
  if dotCount > c.Ndots {
      for _, s := range c.Search {
		names = append(names, Fqdn(name+s))
      }
  }

To do not append search domain when the number of dots in the hostname is greater than the ndots config.
@miekg
Copy link
Owner
miekg commented Dec 23, 2020

can add a test that show explicitly what you expect.

note we already countlabel ones in this function, we shouldn't do it twice

@miekg
Copy link
Owner
miekg commented Dec 23, 2020

we should also update the doc string

@tmthrgd
Copy link
Collaborator
tmthrgd commented Dec 29, 2020

What does the netgo resolver in the standard library (package net) do?

@rewiko
Copy link
Author
rewiko commented Dec 29, 2020 •
edited
Loading

What does the netgo resolver in the standard library (package net) do?

https://github.com/golang/go/blob/9e2acf94fe1baa8bdffb21c2d54e0186ac88b68b/src/net/dnsclient_unix.go#L446

which has the same logic than this lib

Go can use the internal go resolver or libc/musl on the host.
https://golang.org/pkg/net/#hdr-Name_Resolution

Test Setup

cat /etc/resolv.conf

nameserver 8.8.8.8

search kube-system.svc.cluster.local svc.cluster.local cluster.local
options ndots:2

main.go

package main

import (
        "fmt"
        "net"
        "os"
)

func main() {
        ips, err := net.LookupIP("unknown.google.com")
        if err != nil {
                fmt.Fprintf(os.Stderr, "Could not get IPs: %v\n", err)
                os.Exit(1)
        }
        for _, ip := range ips {
                fmt.Printf("google.com. IN A %s\n", ip.String())
        }
}

Using netgo resolver

Resolving unknown.google.com to get a NXDOMAIN and try the search domain using netgo resolver

CGO_ENABLED=0 go run main.go                                                                                
Could not get IPs: lookup unknown.google.com on 8.8.8.8:53: no such host
exit status 1

tcpdump when using netgo resolver

09:22:04.430687 IP 10.0.2.15.48673 > 8.8.8.8.53: 9966+ AAAA? unknown.google.com. (36)
09:22:04.430751 IP 10.0.2.15.32821 > 8.8.8.8.53: 34057+ A? unknown.google.com. (36)
09:22:04.461094 IP 8.8.8.8.53 > 10.0.2.15.48673: 9966 NXDomain 0/1/0 (86)
09:22:04.461869 IP 8.8.8.8.53 > 10.0.2.15.32821: 34057 NXDomain 0/1/0 (86)
09:22:04.462192 IP 10.0.2.15.47949 > 8.8.8.8.53: 3681+ AAAA? unknown.google.com.kube-system.svc.cluster.local. (66)
09:22:04.462406 IP 10.0.2.15.34587 > 8.8.8.8.53: 50987+ A? unknown.google.com.kube-system.svc.cluster.local. (66)
09:22:04.478216 IP 8.8.8.8.53 > 10.0.2.15.47949: 3681 NXDomain 0/1/0 (141)
09:22:04.478915 IP 8.8.8.8.53 > 10.0.2.15.34587: 50987 NXDomain 0/1/0 (141)
09:22:04.479224 IP 10.0.2.15.39175 > 8.8.8.8.53: 62692+ AAAA? unknown.google.com.svc.cluster.local. (54)
09:22:04.479241 IP 10.0.2.15.45926 > 8.8.8.8.53: 46127+ A? unknown.google.com.svc.cluster.local. (54)
09:22:04.495631 IP 8.8.8.8.53 > 10.0.2.15.39175: 62692 NXDomain 0/1/0 (129)
09:22:04.496899 IP 8.8.8.8.53 > 10.0.2.15.45926: 46127 NXDomain 0/1/0 (129)
09:22:04.497102 IP 10.0.2.15.51205 > 8.8.8.8.53: 25977+ AAAA? unknown.google.com.cluster.local. (50)
09:22:04.497177 IP 10.0.2.15.32973 > 8.8.8.8.53: 26527+ A? unknown.google.com.cluster.local. (50)
09:22:04.513703 IP 8.8.8.8.53 > 10.0.2.15.51205: 25977 NXDomain 0/1/0 (125)
09:22:04.514444 IP 8.8.8.8.53 > 10.0.2.15.32973: 26527 NXDomain 0/1/0 (125)

Using libc resolver

Resolving unknown.google.com to get a NXDOMAIN and try the search domain using libc resolver

CGO_ENABLED=1 go run main.go                                                                                         
Could not get IPs: lookup unknown.google.com on 8.8.8.8:53: no such host
exit status 1

tcpdump when using libc resolver

09:24:43.703713 IP 10.0.2.15.43547 > 8.8.8.8.53: 42739+ AAAA? unknown.google.com. (36)
09:24:43.703774 IP 10.0.2.15.48068 > 8.8.8.8.53: 1315+ A? unknown.google.com. (36)
09:24:43.728829 IP 8.8.8.8.53 > 10.0.2.15.48068: 1315 NXDomain 0/1/0 (86)
09:24:43.729541 IP 8.8.8.8.53 > 10.0.2.15.43547: 42739 NXDomain 0/1/0 (86)
09:24:43.729861 IP 10.0.2.15.56518 > 8.8.8.8.53: 45056+ AAAA? unknown.google.com.kube-system.svc.cluster.local. (66)
09:24:43.729904 IP 10.0.2.15.53236 > 8.8.8.8.53: 8330+ A? unknown.google.com.kube-system.svc.cluster.local. (66)
09:24:43.746160 IP 8.8.8.8.53 > 10.0.2.15.56518: 45056 NXDomain 0/1/0 (141)
09:24:43.746904 IP 8.8.8.8.53 > 10.0.2.15.53236: 8330 NXDomain 0/1/0 (141)
09:24:43.747279 IP 10.0.2.15.59542 > 8.8.8.8.53: 22609+ A? unknown.google.com.svc.cluster.local. (54)
09:24:43.747321 IP 10.0.2.15.37436 > 8.8.8.8.53: 40936+ AAAA? unknown.google.com.svc.cluster.local. (54)
09:24:43.764167 IP 8.8.8.8.53 > 10.0.2.15.59542: 22609 NXDomain 0/1/0 (129)
09:24:43.764965 IP 8.8.8.8.53 > 10.0.2.15.37436: 40936 NXDomain 0/1/0 (129)
09:24:43.765284 IP 10.0.2.15.32954 > 8.8.8.8.53: 9007+ AAAA? unknown.google.com.cluster.local. (50)
09:24:43.765447 IP 10.0.2.15.46032 > 8.8.8.8.53: 27829+ A? unknown.google.com.cluster.local. (50)
09:24:43.782041 IP 8.8.8.8.53 > 10.0.2.15.32954: 9007 NXDomain 0/1/0 (125)
09:24:43.783395 IP 8.8.8.8.53 > 10.0.2.15.46032: 27829 NXDomain 0/1/0 (125)

Using nslookup with libc

nslookup unknown.google.com                                                                                     
Server:         8.8.8.8
Address:        8.8.8.8#53

** server can't find unknown.google.com: NXDOMAIN

09:25:51.408471 IP 10.0.2.15.41664 > 8.8.8.8.53: 3540+ A? unknown.google.com. (36)
09:25:51.433273 IP 8.8.8.8.53 > 10.0.2.15.41664: 3540 NXDomain 0/1/0 (86)

Using dig with libc

 dig +search unknown.google.com                                                                              

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> +search unknown.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53078
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;unknown.google.com.            IN      A

;; AUTHORITY SECTION:
google.com.             59      IN      SOA     ns1.google.com. dns-admin.google.com. 349260167 900 900 1800 60

;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 29 09:26:58 UTC 2020
;; MSG SIZE  rcvd: 97

;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 29 09:26:58 UTC 2020
;; MSG SIZE  rcvd: 97

09:26:58.647085 IP 10.0.2.15.58173 > 8.8.8.8.53: 53078+ [1au] A? unknown.google.com. (59)
09:26:58.687010 IP 8.8.8.8.53 > 10.0.2.15.58173: 53078 NXDomain 0/1/1 (97)

Conclusion

 ndots:n
                     Sets a threshold for the number of dots which must
                     appear in a name given to res_query(3) (see
                     resolver(3)) before an initial absolute query will
                     be made.  The default for n is 1, meaning that if
                     there are any dots in a name, the name will be
                     tried first as an absolute name before any search
                     list elements are appended to it.  The value for
                     this option is silently capped to 15.

Source https://man7.org/linux/man-pages/man5/resolv.conf.5.html

I would say miekg/dns and the standard go net lib behave the same but differs of usual dns tools host, nslookup and dig.

I think we can close this issue based on the ndots documentation and the behavior on the go library and miekg/dns.

@rewiko rewiko closed this as completed Dec 29, 2020
@tmthrgd
Copy link
Collaborator
tmthrgd commented Dec 29, 2020

@rewiko Thank you for that investigation. I agree that it seems like we’re doing the right thing here. I suspect dig and nslookup differ as they’re more utility tools.

@miekg
Copy link
Owner
miekg commented Dec 29, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tmthrgd @miekg @rewiko