-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: LookupSRV and search domains when name is empty #9391
Comments
You are using the function in a strange way but I can't think of a good reason why it shouldn't work. |
We just need to add a special case for name=="" to src/net/lookup_*.go |
Have a change in review for this 😄 |
RFC 2782 clearly states that "Clients ask for a specific service/protocol for a specific domain (the word domain is used here in the strict RFC 1034 sense), and get back the names of any available servers." In mDNS, we use a new label "local." and in DNS-SD something more complicated. But those are requirements for protocols, not for built-in stub resolver implementation, API surfaces. I wonder If we extend LookupSRV to be able to accept an empty string as a local domain or a wild card, what about other lookup APIs such as LookMX, LookupHost? Moreover, what if we extend both LookupSRV and LookupTXT to DNS-SD? At this moment I have no concrete opinion on this issue, but fixing this issue with #8540 seems reasonable. |
Hey @mikioh - thanks so much for the feedback (I also saw your comment on Gerrit). I wouldn't mind making these updates and solving #8540. Would love to discuss some more details about the change you are suggesting (implementing DNS-SD) - maybe we move to an implementation discussion over on that issue? |
CL https://golang.org/cl/3569 mentions this issue. |
Using Go 1.4 on Linux x86_64 (Ubuntu).
I called the lookupSRV function in the "net" package, with
lookupSRV("service", "tcp", "")
(empty name).I expected this to lookup using my search domains ("_service._tcp.my.search.domain"), but it potentially seems to have queried it with an extra "." ("_service._tcp..my.search.domain").
Is this intended? Or am I just using the function in a strange way? The workaround I'm using right now is to call
lookupSRV("", "", "_service._tcp")
instead.The text was updated successfully, but these errors were encountered: