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



  • I think there is a potential bug in the startup process between the DNS Resolver and Ipv6.

    I am running dual stack. On the ipv4 side I am using DHCP with static leases only, on the ipv6 side of things, I am not using DHCPv6 server, only router advertisements set as unmanaged.

    After I reboot pfSense, I have noticed that until I do a restart of the DNS resolver, that the ipv6 address is not provided to the clients as a DNS server. The client shows the router ipv4 address only on their list of DNS servers. And if I do a nslookup of the router by name it only returns the ipv4 address.

    As soon as I restart the DNS resolver, then the clients see both the ipv4 address and ipv6 address of the router in their list of DNS servers and a nslookup of the router now returns both ipv4 and ipv6 addresses.

    Note, that if you have the DNS Resolver option "Register DHCP leases in the DNS Resolver" checked, you will probably not notice, since that causes the Resolver to restart frequently.


  • LAYER 8 Netgate

    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.



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



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



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

    ![0_1564336503033_packetcapture - prior reboot.cap](Uploading 100%)

    ![0_1564336555916_packetcapture - after reboot.cap](Uploading 100%)


  • LAYER 8 Netgate

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




  • LAYER 8 Netgate

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

    packetcapture.cap





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


  • LAYER 8 Netgate

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


  • LAYER 8 Netgate

    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


  • LAYER 8 Netgate

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


Log in to reply