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: support for RFC 4592 #28947

Open
fengdingbo opened this Issue Nov 26, 2018 · 11 comments

Comments

Projects
None yet
5 participants
@fengdingbo

fengdingbo commented Nov 26, 2018

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 from net:parser extensive domain name exists bug? to net:DNS parser extensive domain name exists bug? Nov 26, 2018

@agnivade

This comment has been minimized.

Member

agnivade commented Nov 26, 2018

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

@mikioh mikioh changed the title from net:DNS parser extensive domain name exists bug? to net: DNS parser extensive domain name exists bug? Nov 26, 2018

@mikioh

This comment has been minimized.

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 label Nov 26, 2018

@mikioh

This comment has been minimized.

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

This comment has been minimized.

fengdingbo commented Nov 26, 2018

$ 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

This comment has been minimized.

Contributor

mikioh commented Nov 26, 2018

@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

This comment has been minimized.

fengdingbo commented Nov 26, 2018

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

@fengdingbo fengdingbo changed the title from net: DNS parser extensive domain name exists bug? to net: support for RFC 4592 Nov 26, 2018

@agnivade agnivade added this to the Unplanned milestone Nov 26, 2018

@gopherbot

This comment has been minimized.

gopherbot commented Dec 6, 2018

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

@mikioh

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

mikioh commented Dec 7, 2018

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

This comment has been minimized.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment