After reboot, the DNS resolver must be restarted before it will advertise the ipv6 address of the resolver

[Derelict]

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 something

Let 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.

[IsaacFL]

@Derelict after reboot, the router dns doesn’t know its own AAAA. If I do a DNS lookup of pfSense.mydomain.com it returns only the A record for the router itself.

If I restart the resolver , then DNS lookup returns both A and AAAA records.

I think most people don’t notice because they have it set so that DHCP is constantly restarting the resolver.

[IsaacFL]

@Derelict I did a reboot today, and here are some of my observations:

Going to diagnostics -> DNS Lookup only returns the A record for the router hostname.

Ipv6 is working, I can ping out, etc. DNS lookup of google.com returns both A and AAAA records.

Looking at the /var/unbound/host_entries.conf
The local-data: lines for the ipv6 for router are missing.

Looking at /var/etc/radvd.conf is missing a lot of information:

Prior to reboot (working state) for LAN interface (xxxx to mask address infor):

# Automatically Generated, do not edit
# Generated for DHCPv6 Server lan
interface igb1 {
	AdvSendAdvert on;
	MinRtrAdvInterval 5;
	MaxRtrAdvInterval 20;
	AdvLinkMTU 1500;
	AdvDefaultPreference medium;
	prefix 2605:e000:xxxx:xx10::/64 {
		DeprecatePrefix on;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
		AdvValidLifetime 86400;
		AdvPreferredLifetime 14400;
	};
	route ::/0 {
		AdvRoutePreference medium;
		RemoveRoute on;
	};
	RDNSS 2605:e000:xxxx:xx10:xxxx:xxxx:xxxx:1b95 { };
	DNSSL psp.iznmort.com  { };
};

Same file after reboot:

# Automatically Generated, do not edit
# Generated config for dhcp6 delegation from wan on lan
interface igb1 {
	AdvSendAdvert on;
	MinRtrAdvInterval 5;
	MaxRtrAdvInterval 10;
	AdvLinkMTU 1500;
	AdvOtherConfigFlag on;
	prefix ::/64 {
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr on;
	};
	DNSSL psp.iznmort.com { };
};

Notice that even the comments at the top are different, which makes me think a script to update it didn't get fired off.

A packet capture like you suggested prior to reboot shows the DNS server being presented. A packet capture after does not have DNS server being presented.

A simple restart of the unbound service fixes all of this, but it stays that way until unbound is restarted.

I don't know that it is a resolver unbound issue, probably more likely something in the script that gets kicked off that fixes it.

[IsaacFL]

@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 something

Let 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.



[Derelict]

No idea. Maybe try without a bunch of spaces in the filenames.

[IsaacFL]

@Derelict Had to rename .cap to .pcap

packetcapture-prior-reboot.pcap

packetcapture-after-reboot.pcap

[Derelict]

Don't know what to tell you. .cap is a valid extension.

packetcapture.cap

[Pippin]

/me can not upload .cap too .....
https://forum.netgate.com/topic/138124/posting-to-a-forum-issue

[IsaacFL]

@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.

[Derelict]

It did not used to be allowed. The .cap extension was added recently.

[Derelict]

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.

[IsaacFL]

@Derelict I created Bug #9654

[Derelict]

Cool. That is the channel to get the developers (I am not one) to look at it.

[A Former User]

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