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.

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

net: LookupNS() cannot be used to discover root name servers #45715

Open
markdingo opened this issue Apr 23, 2021 · 7 comments
Open

net: LookupNS() cannot be used to discover root name servers #45715

markdingo opened this issue Apr 23, 2021 · 7 comments

Comments

@markdingo
Copy link

@markdingo markdingo commented Apr 23, 2021

What version of Go are you using (go version)?

go version go1.16.3 freebsd/arm64
go version go1.16.3 darwin/arm64
go version go1.16.3 freebsd/amd64
go version go1.11.6 linux/amd64

Does this issue reproduce with the latest release?

Yes, any recent release and on multiple platforms.

What did you do?

package main

import (
        "fmt"
        "net"
)

const hardCodedRiskyName = "root-servers.net."

func main() {
        for _, n := range []string{"", ".", hardCodedRiskyName} {
                results, err := net.LookupNS(n)
                if err != nil {
                        fmt.Printf("Failed using '%s' with error %s\n", n, err.Error())
                } else {
                        fmt.Printf("Works using '%s', giving %d\n", n, len(results))
                }
        }
}

What did you expect to see?

$ go run gr.go
Works using '', giving 13
Works using '.', giving 13
Works using 'root-servers.net.', giving 13

I would expect at least one of the empty string or '.' to return the list of root name servers, much as is returned by the command dig . ns. I think I'd prefer '.' but both should result in a zero-length qname NS query sent to the local resolver.

What did you see instead?

$ go run gr.go
Failed using '' with error lookup : no such host
Failed using '.' with error lookup .: no such host
Works using 'root-servers.net.', giving 13

Which means the only way to get the root name servers is to use a hard-coded name, which while probably safe for the foreseeable future, is not as future-proof as the moral equivalent of dig . ns.

The root cause (ahem) appears to be that src/net/dnsclient.go:isDomainName() disallows the singular "." and the empty string as valid domain names for any type of query, including NS.

Alternatives

I'm happy to use an alternative mechanism within the net package, but a fairly decent look at the source code suggests that there are no lower-level functions which bypass isDomainName().

@markdingo
Copy link
Author

@markdingo markdingo commented Apr 23, 2021

Ah. I see this issue has been prosecuted before in #12421 and #1167 and ultimately frozen due to age.

On further reflection, it's not clear that isDomainName() is adding any value to the lookup process.

First off, the test is at the wrong level as dnsclient_unix.go:Resolver.lookup() is not type-aware and thus can have no clue as to which types have what label constraints.

Second off, RFC1034 is quite explicit about allowing any characters as labels in future possible query types ("The rationale for this choice is that we may someday need to add full binary domain names for new services") and only recommends restricting labels as a transitionary guideline ("the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs").

Even if one were to view this prudence as a "MUST" in modern RFC parlance - shouldn't that be constrained on the database entry side of the process, not the database query side?

Third, LookupNS() allows lookups for "com.", "net." and "org." but not ".". It's inconsistent that the function allows access to some NS RRs in the global DNS but not others.

Finally, as others have noted, there is also the presumption of this code running on the public internet when in fact it should work perfectly well in a closed system; mDNS being the most obvious example. It is quite embarrassing having to inform my colleague, Charles André de Gaulle, that they have to change their name because it doesn't fit with the world view of what an office speaker-phone can be called.

I suggest that isDomainName() be recast as canBeEncodedAsAQName() and only reject the qName if it cannot be encoded into the protocol. In short, let the local resolver decide whether the qName exists in its database and otherwise avoid getting involved in deciding what constitutes a valid database key for a remote, general-purpose database.

@cherrymui cherrymui added this to the Backlog milestone Apr 26, 2021
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Apr 26, 2021

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 26, 2021

@iangudger
Copy link
Contributor

@iangudger iangudger commented Apr 29, 2021

Is there a reason not to allow "." for all lookup types?

@markdingo
Copy link
Author

@markdingo markdingo commented Apr 29, 2021

Is there a reason not to allow "." for all lookup types?

While that would solve my immediate problem, I think the bigger question is whether isDomainName() is the right test to make on entry to lookup(). The claim is that isDomainName() tests for a "presentation-format domain name" but it really doesn't. As, e.g. it doesn't deal with escape sequences as defined in RFC1035 "Quoting conventions allow arbitrary characters to be stored in domain names.".

@iangudger
Copy link
Contributor

@iangudger iangudger commented May 2, 2021

I tried to fix that, but it got stuck in review: golang.org/cl/99623

@markdingo
Copy link
Author

@markdingo markdingo commented May 2, 2021

Ok, that's quite a change, but if it does the job and also solves a few other issues, maybe that's the best approach. How do we push this code review forward?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants