-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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 (lookup for wildcard dns) #28947
Comments
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
/cc @iangudger @mikioh |
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 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. |
Removing WaitingForInfo label because it's understandable that users might want to use |
$ 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. |
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. |
@mikioh Yes |
Change https://golang.org/cl/152878 mentions this issue: |
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. |
@mikioh Thanks for the heads up, but I think dnsclient.go should treat asterisk as valid char. |
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. |
I see. It's not just about Go but other DNS stub resolver implements which sounds like a dead end to me. |
I'm facing the same issue of |
Hi @mikioh I have the same issue. Thanks |
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: