After reboot, the DNS resolver must be restarted before it will advertise the ipv6 address of the resolver
-
@Derelict said in After reboot, the DNS resolver must be restarted before it will advertise the ipv6 address of the resolver:
There is nothing I can think of in DNS resolver that has anything to do with configuring the router advertisements for IPv6.
If it were me, I would get it into the broken state and packet capture for the router advertisements on the inside interfaces (which is where the clients will get their DNS servers using SLAAC). and see what they contain.
Diagnostics > Packet Capture
Interface: LAN (or whatever the inside interface is)
Address Family: IPv6 only
Host address: ff02::1
Count: 100000 or somethingLet it run for a while and stop it.
Wireshark will dissect that for you and you can look for the Recursive DNS Server options in the Router Advertisements.
I used to run completely unmanaged and never had any issues, nor am I aware of any issues elsewhere.
Or post the pcap file here.
Not sure how to post the pcap files here. Upload file gives error message.
![0_1564336503033_packetcapture - prior reboot.cap](Uploading 100%)
![0_1564336555916_packetcapture - after reboot.cap](Uploading 100%)
-
No idea. Maybe try without a bunch of spaces in the filenames.
-
@Derelict Had to rename .cap to .pcap
-
Don't know what to tell you. .cap is a valid extension.
-
/me can not upload .cap too .....
https://forum.netgate.com/topic/138124/posting-to-a-forum-issue -
@Derelict It is pretty easy to reproduce. You just have to create an environment where the unbound does not get automatically restarted. Then you notice the ipv6 DNS problems after rebooting. Restarting the unbound service manually fixes it.
My configuration:
DHCPv6 Server is Disabled. RA is Unmanaged.
Unchecked Resolver, DHCP Registration.
-
It did not used to be allowed. The .cap extension was added recently.
-
OK. Guess that's the case then. I'd open a bug report at https://redmine.pfsense.org/ detailing the steps to reproduce, the expected behavior, and the observed behavior.
-
@Derelict I created Bug #9654
-
Cool. That is the channel to get the developers (I am not one) to look at it.
-
Hi
Just wanted to add also saw this issue during an upgrade from 2.4.4_3 to 2.4.5, I had previously unchecked "Register DHCP leases in the DNS Resolver" due to loads of restarts on the DNS Resolver service. On upgrading to 2.4.5 (I think unrelated to the upgrade, it was just because of the restart) I found an issue with my VoIP phone over IPv6 failing to register. Various trouble shooting later I ended up testing from a Windows PC using NSLOOKUP which picked up the DNS server on the IPv6 address but it was timing out and returning no results.
A Goggle brought me here, so as per OP I restarted the DNS Resolver and NSLOOKUP started returning addresses, and low and behold the VoIP phone registered back up. So definitely a bug somewhere.
Regards
Phil