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:
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.
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 :2020#53( 2001:8b0: :2020)
;; 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.