Comment 5 for bug 1584042
Revision history for this message
| Robie Basak (racb) wrote Re: IPV6 resolving fails via udp (not tcp) from other server | #5 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Thank you for taking the time to report this bug and helping to make Ubuntu better.
I'm sorry, I don't understand your report.
You've reported the bug against bind9, so are you saying that the problem is with bind9 serving as a forwarder? But in that case, I don't understand why you're instructing me to change resolv.conf in your reproduction steps, since bind doesn't use that.
You're also instructing me to use dig @XXX for a failure case, which also doesn't use resolv.conf but uses the nameserver specified directly.
I have just tested and confirmed that dig works correctly with IPv6 on Xenial against one of my ISPs IPv6 resolvers. I tried changing resolv.conf temporarily to point to an IPv6 nameserver only, and it still works:
$ dig www.google.com @2001:8b0::2020
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.google.com @2001:8b0::2020
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57112
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 202 IN A 216.58.198.100
;; Query time: 20 msec
;; SERVER: 2001:8b0:
;; WHEN: Wed May 25 14:59:56 BST 2016
;; MSG SIZE rcvd: 59
Are you sure you don't have a simple firewall issue?
Since I cannot understand your report, I regret that this will not make any progress without further information.
Please could you provide a simple set of steps to reproduce that uses a single minimal set of DNS tooling, rather than all the tools? For example, if it is a problem with resolv.conf and nss, then your instructions should involve changing resolv.conf and using "getent hosts" or similar only. Using "dig @..." makes no sense since this bypasses resolv.conf and nss. Concurrent commentary using tcpdump said are appreciated and useful; my point is that the failure should be able reproduce using minimal tooling.
Once done, please change the bug status back to New.