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

Jump to bottom

net: support for RFC 4592 #28947

Open
fengdingbo opened this issue Nov 26, 2018 · 13 comments
Open

net: support for RFC 4592 #28947

fengdingbo opened this issue Nov 26, 2018 · 13 comments
Labels
FeatureRequest
Milestone
Unplanned

Comments

@fengdingbo
Copy link

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

$ go version
go version go1.10.3 darwin/amd64

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/qiufeng/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/qiufeng/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pr/1blgkr1j60bbscwnp21g4bqr0000gn/T/go-build995562236=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

package main

import (
	"net"
	"context"
	"log"
)
func main() {

	host:="*.qzone.qq.com"
	log.Println(net.LookupHost(host))

	r := net.Resolver{
		PreferGo:true,
		StrictErrors:true,
		Dial: DNSDialer,
	}
	ctx := context.Background()

	ipaddr, err := r.LookupHost(ctx, host)
	if err != nil {
		log.Println(err)

	}
	log.Println(ipaddr)
}


func DNSDialer(ctx context.Context, network, address string) (net.Conn, error) {
	d := net.Dialer{}
	return d.DialContext(ctx, "udp", "8.8.8.8:53")
}

What did you expect to see?

$ go run test2.go
2018/11/26 10:47:27 [180.163.21.59] 
2018/11/26 10:47:27 [180.163.21.59]

What did you see instead?

$ go run test2.go
2018/11/26 10:47:27 [180.163.21.59] 
2018/11/26 10:47:27 lookup *.qzone.qq.com: no such host
2018/11/26 10:47:27 []
@fengdingbo fengdingbo changed the title net:parser extensive domain name exists bug? net:DNS parser extensive domain name exists bug? Nov 26, 2018
@agnivade
Copy link
Contributor

Please try with 1.11.2. There has been quite a few changes to the dns stack. This is what I get with 1.11.2

2018/11/26 09:27:20 [] lookup *.qzone.qq.com: no such host
2018/11/26 09:27:20 lookup *.qzone.qq.com: no such host
2018/11/26 09:27:20 []

/cc @iangudger @mikioh

@agnivade agnivade added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Nov 26, 2018
@mikioh mikioh changed the title net:DNS parser extensive domain name exists bug? net: DNS parser extensive domain name exists bug? Nov 26, 2018
@mikioh
Copy link
Contributor

mikioh commented Nov 26, 2018

Please take a look at https://tools.ietf.org/html/rfc4592, and https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-14#section-8, then please make sure your opinion on * for API surface.

DNS implementations vary, and its features are huge and tightly coupled with operational perspectives (and circumstances.) We cannot define the correct (or neutral) behavior without such contextual information.

@mikioh mikioh removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Nov 26, 2018
@mikioh
Copy link
Contributor

mikioh commented Nov 26, 2018

Removing WaitingForInfo label because it's understandable that users might want to use * for some DNS operations, though it's unclear whether we should use it (and how to use it).

@fengdingbo
Copy link
Author 

$ dig @8.8.8.8 *.qzone.qq.com

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 *.qzone.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36807
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;*.qzone.qq.com.			IN	A

;; ANSWER SECTION:
*.qzone.qq.com.		599	IN	A	180.163.21.59

;; Query time: 105 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Nov 26 13:25:16 2018
;; MSG SIZE  rcvd: 48

So I think it should be parsed normally.

@mikioh
Copy link
Contributor

mikioh commented Nov 26, 2018 •
edited

@fengdingbo,

So I think it should be parsed normally.

Well, this doesn't emit anything useful because it only describes that "a DNS tree traversal implementaion called dig just treats a least significant asterisk as the start label of wildcard RRs as defined in RFC 4592", but the issue title says "extensive domain name", sounds like something different.

Please change the issue title if your request is just support for RFC 4592.

@fengdingbo
Copy link
Author

@mikioh Yes
I need it support for RFC 4592, thanks.

@fengdingbo fengdingbo changed the title net: DNS parser extensive domain name exists bug? net: support for RFC 4592 Nov 26, 2018
@agnivade agnivade added this to the Unplanned milestone Nov 26, 2018
@gopherbot
Copy link

Change https://golang.org/cl/152878 mentions this issue: net: dns name support RFC4592

@mikioh
Copy link
Contributor

mikioh commented Dec 6, 2018

Please don't send any CL unless you have a good compromise for the label handling conflict; unicast DNS vs. multicast DNS, LDH vs. Net-Unicode vs. IDN/Punycode, classical Latin-based language specific handling vs. neutral handling, etc.

I personally want to see, a) separation between wire-format encoding/decoding and label encoding/decoding, b) modular label validation and flexible API.

@mengzhuo
Copy link
Contributor

mengzhuo commented Dec 7, 2018

@mikioh Thanks for the heads up, but I think dnsclient.go should treat asterisk as valid char.
I can change CL title if you want.

@mikioh
Copy link
Contributor

mikioh commented Dec 7, 2018 •
edited

Please have a time for digging this issue tracker. You may see a ton of issues related to DNS stub resolver and DNS label handling. The most interesting thing is that each issue is reasonable and valid in some circumstance but not reasonable and invalid in another circumstance. This is because DNS is a pretty tolerant protocol and it requires various operational perspectives for operation. Without considering the operational perspectives, the implementation could be arrogant easily.

Your request is reasonable but assuming the built-in stub resolver should work only for LDH w/ a few extensions such as RFC 4592 even on an environment operating non-LDH labels might not be a good idea.

@mengzhuo
Copy link
Contributor

mengzhuo commented Dec 7, 2018

I see. It's not just about Go but other DNS stub resolver implements which sounds like a dead end to me.

@dinesh707
Copy link

I'm facing the same issue of Resolver failing on isDomainName() function when it has the wildcard char. Given the fact that different DNSs have implemented things differently, does it make sense to allow isDomainName() function to be a variable of Resolver and allow callers to override the isDomainName() if they wish to? If this is a reasonable change I can make a CL. Thank you.

@mcgradycchen
Copy link

mcgradycchen commented Mar 13, 2024 •
edited

Hi @mikioh

I have the same issue.
Caller can override the isDomainName function may be a good option.
Or resolver provide a flag that is to skip check isDomainName(), generally caller will validate the domain format before call LookupTXT function.

Thanks

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

No branches or pull requests
7 participants
@mikioh @mengzhuo @agnivade @fengdingbo @mcgradycchen @dinesh707 @gopherbot