I turned on IPv6 and now my Orbi is telling DHCP clients that the DNS servers are 192.168.1.1 (which is good) and fe80::[...], which is not. As discussed in the thread above, this is not useful.
The result of this is that depending on what server the application uses, addresses may or may not resolve.
Does anyone have a solution for this? I'd file a ticket with support but I'm past my 90 days window, which frankly if I knew this was a thing before buying the Orbi would have been a deal breaker.
I turned on IPv6 and now my Orbi is telling DHCP clients that the DNS servers are 192.168.1.1 (which is good) and fe80::[...], which is not. As discussed in the thread above, this is not useful.
The result of this is that depending on what server the application uses, addresses may or may not resolve.
Does anyone have a solution for this?
As this affects only devices with IPv6, one workaround would be to define IPv6 DNS servers on those few devices.
(This seems like a great opportunity to learn more about IPv6, so.....)
How would a person test that the link local IPv6 address will not resolve DNS? The IPv4 DNS is a "local" IP address (the Orbi LAN IP).
Perhaps the Orbi accepts DNS queries on its link local interface and uses its external IPv6 address to pass queries?
My first thought is to disable IPv4 on my network interface, which would probably eliminate contact with any device or service that supports only IPv4. So, I have shelved that idea for now.
My second thought was to use the ping -6 command. When I do that, many URL's respond. I tried (one.one.one.one, google.com, ibm.com, att.com) and they all worked. I tried some other URL's and got "Could not find host", which is what I would expect if those domains do not support IPv6.
So now I'm back wondering how to test the concept that giving devices the link local IPv6 address is wrong if it works for many domains and I am not (100%) certain that the failing domains actually support IPv6.
There is another experiment, which I will attempt this evening.
Capture LAN/WAN traffic.
Make IPv6 calls for domains that are not likely to be in the DNS cache.
Analyze LAN/WAN with Wireshark.
For every IPv6 DNS lookup that is addressed to the Link Local Orbi interface, look for corresponding IPv6 lookups from the Orbi IPv6 WAN interface and responses from the designated DNS servers.
It probably doesn't matter if the domains support IPv6 or not, as long as the DNS requests are made.
Does anyone know the telnet command to clear the local DNS cache on Orbi?
Thanks for the example. (Now I get to learn about the Linux dig command - and see if there is an equivalent in Windows).
We seem to have a different understanding of the meaning of "nameserver". I take it as "send DNS queries to these servers" and they will respond to you." They are not the ultimate resolvers for DNS.
netgear.com does not appear to have an IPv6 address, so attempts to resolve it will fail, whereas
While I haul out a Linux box and load up dig, maybe you could do the same test with domains such as ibm.com and google.com that are known to have IPv6 addresses.
That's not how dig works. Unless you tell it otherwise, it looks up the IPv4 (A record) for the name.
Note how when I used the v4 address of the router, or a v6 external server, it worked, but the v6 address the router gave timed out.
To demonstrate this, here's dig looking up the v6 (AAAA record) for my ISP on both the v6 address the router is giving and the real public v6 address of the ISP's DNS server.
$ dig @2001:8b0::2020 www.aa.net.uk AAAA
;; ANSWER SECTION:
www.aa.net.uk. 367 IN AAAA 2001:8b0:0:62::14
www.aa.net.uk. 367 IN AAAA 2001:8b0:0:62::13
;; Query time: 136 msec
;; SERVER: 2001:8b0::2020#53(2001:8b0::2020)
$ dig @fe80::2a80:88ff:feeb:3cf8 www.aa.net.uk AAAA
;; connection timed out; no servers could be reached
Aha. So the trick is that you need to specially handle v6 link-local addresses. The address may be fe80::2a80:88ff:feeb:3cf8 but when it is used it needs to be qualified with the interface name:
$ dig @fe80::2a80:88ff:feeb:3cf8%en0 www.aa.net.uk
;; ANSWER SECTION:
www.aa.net.uk. 1287 IN A 90.155.62.14
www.aa.net.uk. 1287 IN A 90.155.62.13
And this qualification doesn't make it into /etc/resolv.conf so that's fun to deal with!
I am still thrashing about. Turns out dig for Windows is a lot easier for me to work with than (anything) on Linux. (That business with DNS going through the loopback address and all.)
Here's what a dig query on ibm.com looks like from my Orbi liink-local address:
c:\Bind>dig @fe80::a204:60ff:fe1c:239%19 ibm.com ANY
; <<>> DiG 9.16.16 <<>> @fe80::a204:60ff:fe1c:239%19 ibm.com ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39065
;; flags: qr rd ra; QUERY: 1, ANSWER: 31, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ibm.com. IN ANY
;; ANSWER SECTION:
ibm.com. 3599 IN MX 5 mx0b-001b2d01.pphosted.com.
ibm.com. 3599 IN MX 5 mx0a-001b2d01.pphosted.com.
ibm.com. 19 IN A 96.17.216.124
ibm.com. 21599 IN SOA asia3.akam.net. dnsadm.us.ibm.com. 1564134900 43200 7200 604800 3600
ibm.com. 19 IN AAAA 2600:1406:3400:6a1::3831
ibm.com. 19 IN AAAA 2600:1406:3400:69d::3831
ibm.com. 599 IN TXT "amazonses:79ShwQazteb+WkCt8e297sAC2mwZVRditsrzaoxiHjU="
ibm.com. 599 IN TXT "00D3h000004YkeYEAS"
ibm.com. 599 IN TXT "00d50000000c9mweay"
ibm.com. 599 IN TXT "yandex-verification: 5f458b477256c50c"
ibm.com. 599 IN TXT "00d00000000hedieay"
ibm.com. 599 IN TXT "40a21f5affe343c6b37e0a5af80dcd93"
ibm.com. 599 IN TXT "Dynatrace-site-verification=76b6b299-fe43-4f31-889b-a8a467193478__8q74sg9dg5udjppn95utrb8bct"
ibm.com. 599 IN TXT "v=spf1 ip4:148.163.158.5 ip4:148.163.156.1 ip4:67.231.145.127 ip4:67.231.153.87 ip4:168.245.101.145 mx a:zgateway.zuora.com include:_spf.google.com ~all"
ibm.com. 599 IN TXT "atlassian-domain-verification=WAjTH82C5Zx475WLKAA2nrdlsoA/kN0ej9igrLrED4h15KMHPOm+A5H3GndKAxDC"
ibm.com. 599 IN TXT "google-site-verification=Jck8mLbYYfCnrmi_nRy4MG2fbUN3UGhC29KdspGLd9Y"
ibm.com. 599 IN TXT "adobe-idp-site-verification=5f8adca7-512f-44e1-a5b2-b62c5e3763f2"
ibm.com. 599 IN TXT "apple-domain-verification=M3o953J0rN1B0P2a"
ibm.com. 599 IN TXT "00df40000004784eaa"
ibm.com. 599 IN TXT "google-site-verification=tzdngH5fWH-k8uQoDVovOFJQZTwaGtDOP6S2cQlOvCs"
ibm.com. 599 IN TXT "_github-challenge-ibm.ibm.com=2613e984bc"
ibm.com. 599 IN TXT "facebook-domain-verification=kyuxs3tdqtyh9rbqa3szkq3k9i2bbs"
ibm.com. 599 IN TXT "MS=ms61389031"
ibm.com. 21599 IN NS usw2.akam.net.
ibm.com. 21599 IN NS asia3.akam.net.
ibm.com. 21599 IN NS eur2.akam.net.
ibm.com. 21599 IN NS usc3.akam.net.
ibm.com. 21599 IN NS ns1-206.akam.net.
ibm.com. 21599 IN NS eur5.akam.net.
ibm.com. 21599 IN NS ns1-99.akam.net.
ibm.com. 21599 IN NS usc2.akam.net.
;; Query time: 134 msec
;; SERVER: fe80::a204:60ff:fe1c:239%19#53(fe80::a204:60ff:fe1c:239%19)
;; WHEN: Sun May 30 15:21:59 Pacific Daylight Time 2021
;; MSG SIZE rcvd: 1497
I am still of the opinion that Orbi giving out its IPv4 and IPv6 link local addresses as DNS servers "works".
I am also of the opinion that IPv6 is incredibly complicated and confusing and that a tremendous portion of the internet isnot IPv6 friendly.
