Yesterday, I noticed issues with ipv6 dns using dig and nslookup (windows 10). The problem went away but seems to be back. I updated to the latest snapshot, but it made no difference. I also tried adding an ACL, but that also made no difference. I've never added an ACL before.
Current snapshot here - no issues.
I reinstalled pfsense 2.4 beta from scratch using the latest snapshot. Still having problems.
After flushing dns on the windows and linux clients, dig -6 doesn't return any results.
I have not changed any unbound settings, other than to register leases and static entries. I tried clearing them but it made no difference, even after restarting unbound.
How many threads you going to start on this issue?
See the other thread where looks like -6 is a windows issue with dig.
I started one thread in DHCP and DNS and since the problem is only on my 2.4 beta system, I started another in here, in case anyone else using 2.4 beta has noticed it.
GetAdaptersAddresses based on a little Googling.
GetNetworkParams only returns the IPv4 addresses.
depending upon the calling arguments.
populate the default server list.
dig -6 @f.root-servers.net soa .
Thanks for the reply. I didn't have an opportunity to respond further to the other post today, but will try later.
I don't know at this stage. Basically when time becomes available to rewrite that section of code.
But it doesn't seem to be a big bug - and its only windows related. Works fine on freebsd and linux.. And you can just use @ipv6ip to make query via ipv6.
their -6@ipv6fqdn works fine if you direct it towards a root server. But doesn't seem to work if using record that responds via AAAA. But works with roots.
I was away for a week and during that time, the systems were idle. When I returned on Monday evening, I updated pfsense and after that, I noticed the problem was gone. (I did not check for it before I updated.) It stayed that way (i.e., nslookup was working) until the most recent update I applied earlier this evening, when the problem returned. I have not made any configuration changes with pfsense or the clients during this time.
The first query from before the update shows nslookup working. The second query from after the update shows nslookup not working.
I tried this on two different windows 10 clients. They both behave exactly the same. When they are connected to my pfsense 2.3.4 system, nslookup works. When they are connected to my pfsense 2.4 beta system, nslookup does not work.
It's possible to ping 4/6 the the clients from pfsense and from other clients. It's possible to ping 4/6 pfsense from both clients. It's possible to ping 4/6 and traceroute 4/6 google.com from the clients. I tried flushing the dns on the clients. dns lookup google.com from pfsense works. The only apparent issue is nslookup.
All unbound settings are defaults. Previously, I tried enabling an ACL, but that made no difference. DNS servers are not being overridden by dhcp or dhcpv6 or in general settings. Allow DNS server override is unchecked.
I made zero changes to pfsense other than updating. Is it possible that this problem is related to the unbound changes?
If anyone has any suggestions to determine what's causing the problem, let me know.
I've noticed through the last couple of snapshot updates that after the reboot, it's not working (nslookup and dig @ipv6). If I restart unbound, it works afterwards. I looked in the log and there aren't any messages that indicate any problems.
The lower three messages are from the reboot after the update. The upper three messages are from restarting unbound.
Jul 9 10:06:31	unbound	49140:0	info: start of service (unbound 1.6.3).
Jul 9 10:02:37	unbound	19726:0	info: start of service (unbound 1.6.3).
Going to need some actual info to work with. What log level do you have set in unbound? If that is all your seeing my guess would be 0, change it to 1 or 2 are you seeing errors now? Up it so can see some more info. Check to see that your listening on ipv6.. See attached.
But still able to query it via its actual global IPv6 address.. With the info you have provided there is zero chance of anyone helping you..
The snapshot is Sun Jul 09 02:22:35 CDT 2017. At the moment, it's still working properly. nslookup returns a result and dig will return the a and aaaa records using either ipv4 or ipv6. My linux box is also working properly. All unbound settings are default. The log level is 1 so apparently, that's the default. I bumped it up to 2. It generates a lot more messages. Nothing that appears to be erroneous.
I updated to the latest snapshot and found that the problem returned after the reboot. With unbound logging at 2, there are a lot of messages including some errors (error sending query to auth server <ipv6 address="">port 53).
Here are the contents of the log in reverse chronological order (newest first). If you scroll down to the bottom, you will see the errors.
Jul 10 13:02:49	unbound	18407:1	info: NSEC3s for the referral proved no DS.
Jul 10 13:02:49	unbound	18407:0	info: NSEC3s for the referral proved no DS.
Jul 10 13:02:48	unbound	18407:0	info: NSEC3s for the referral proved no DS.
Jul 10 13:02:36	unbound	18407:0	info: NSEC3s for the referral proved no DS.
Jul 10 13:02:35	unbound	18407:0	info: start of service (unbound 1.6.3).
I restarted unbound and nslookup and dig are working.
Here are the log messages from the restart. There are no errors.
Jul 10 13:11:01	unbound	85831:1	info: NSEC3s for the referral proved no DS.
Jul 10 13:11:01	unbound	85831:0	info: NSEC3s for the referral proved no DS.
Jul 10 13:10:52	unbound	85831:0	info: NSEC3s for the referral proved no DS.
Another test. I rebooted, found nslookup not working, restarted unbound and nslookup was working. So it seems to be related to rebooting, not necessarily the snapshot.
Its possible your ipv6 is not coming up as fast as your ipv4? Your dhcp with tracking on your interfaces? Or maybe your ipv6 is changing on reboot?
It's definitely repeatable that the problem occurs after reboot and persists until unbound is restarted.
I cleared the logs and rebooted. unbound and dhcp6c appear to be starting up concurrently. Maybe this is the problem.
Jul 11 09:51:14	unbound	16498:0	info: start of service (unbound 1.6.3).
I should have added that my isp requires dhcpv6 solicit before RA.
I updated to the latest snapshot from today and after the reboot, the nslookup / dig problem was back. After restarting unbound, nslookup and dig worked properly. It seems to be a solid problem that restarting unbound is required after a reboot. This time, there were no errors in the log. Since most users do not require the do not wait for RA flag, possibly that's why this is occurring on my system. Are there any tests I should do or log info that I should post? Is this a bug?