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: allow lookup of _ names #1167

Closed
gopherbot opened this issue Oct 6, 2010 · 9 comments
Closed

net: allow lookup of _ names #1167

gopherbot opened this issue Oct 6, 2010 · 9 comments

Comments

@gopherbot
Copy link

by bortzmeyer:

What steps will reproduce the problem?

[This is actually a problem in a comment.]


Which operating system are you using?

Debian "squeeze"

Which revision are you using?  (hg identify)

0dc6198e4ff3 tip

Please provide any additional information below.

The source code says:

func isDomainName(s string) bool {
    // Requirements on DNS name:
    //  * must not be empty.
    //  * must be alphanumeric plus - and .
    //  * each of the dot-separated elements must begin
    //    and end with a letter or digit.
    //    RFC 1035 required the element to begin with a letter,
    //    but RFC 3696 says this has been relaxed to allow digits too.
    //    still, there must be a letter somewhere in the entire name.

But this is quite misleading:

1) RFC 1035 never *required* names to be "alphanumeric plus - and ." RFC 1035,
section 2.3.1 "Preferred name syntax" just says it is the *preferred* syntax. 

2) RFC 2181 made very clear in section 11 "Name syntax" that domain names can
be anything (for instance, the _ is quite common, I do not even mention IDN)

3) The relaxation you mention (allowing a leading digit) was in RFC 1123, section 2.1
"Host Names and Numbers" and is about *HOST* names, not *DOMAIN* names. Host
names have much stricter rules.
@rsc
Copy link
Contributor

rsc commented Oct 6, 2010

Comment 1:

http://golang.org/cl/2290044

Owner changed to r...@golang.org.

Status changed to Started.

@rsc
Copy link
Contributor

rsc commented Oct 6, 2010

Comment 2:

This issue was closed by revision a0a7768.

Status changed to Fixed.

@gopherbot
Copy link
Author

Comment 3 by bortzmeyer:

This is not "comment pedantry", it is an error in the code logic.
Currently, isDomainName returns false for a domain name like
_jabber._tcp.gmail.com whih does exist. I pointed the comments which
were misleading but there is a deeper issue in the code. Now that the
comments are gone, it is difficult to know what isDomainNameis
supposed to do but it is certainly not faithful to its name.

@rsc
Copy link
Contributor

rsc commented Oct 6, 2010

Comment 4:

If there is a problem in the code, it would have
helped not to start the bug report with
"This is actually a problem in a comment."
What do you suggest changing?

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Oct 6, 2010

Comment 5:

Is this sufficient?
http://golang.org/cl/2353043

@rsc
Copy link
Contributor

rsc commented Oct 6, 2010

Comment 6:

Issue #1168 has been merged into this issue.

@gopherbot
Copy link
Author

Comment 7 by bortzmeyer:

The patch solves the problem of _ names (by far the most common) but isDomainName is
still not compliant with the standard since it rejects legitimate domain names (although
they are not frequent in the wild), for instance domain names with UTF-8 chars, with %
or &, etc

@rsc
Copy link
Contributor

rsc commented Oct 6, 2010

Comment 8:

The standard does say that clients can impose whatever 
restrictions they choose.  It only requires servers to
allow arbitrary syntax.
I'd like to avoid sending crazy requests on to DNS
and incurring the associated delays, failure modes, and so on.
I don't want to pass on UTF-8 because what if it's Latin-1
or what if it's supposed to be Punycode?  I don't think % and &
are going to arise in practice because they would be invalid
in a URL or email host name.

@rsc
Copy link
Contributor

rsc commented Oct 7, 2010

Comment 9:

This issue was closed by revision 2408a4b.

Status changed to Fixed.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants