DNS servers issue



  • 2.2-BETA (i386)
    built on Sat Nov 29 02:37:09 CST 2014

    Just started seeing an issue that appears to have started on the Sat. build, perhaps related to the recent changes.

    Issue:  Using DNS Forwarder (dnsmask).

    1. At first boot the only DNS servers shown on the Dashboard is the IPv6 server.

    1. Toggle DNS Forwarder OFF/ON - now the configured IPv4 servers show up (which is what I expect to see).

    1. Reboot pfSense and it is back to only the IPv6 server.

    2. Toggle DNS Forwarded OFF/ON - now the configured IPv4 servers show up.

    This is reproducible at every reboot.



  • Split this into its own thread since it has nothing to do with where it was posted.

    What type of WAN(s)?



  • That's a SLACC interface on a test system.  Always showed the IPv4 DNS servers configured in the General settings before the Sat. build.  Not a "true" WAN, but it is an odd behavior that was not there previously.



  • SLAAC in FreeBSD calls resolvconf for putting RDNSS in resolv.conf. It's always behaved that way, maybe next hop wasn't setting RDNSS (which could have been hit and miss up until the past week or so if you're running Unbound).

    Create a file /etc/resolvconf.conf containing only the following line:

    resolv_conf_passthrough=YES 
    

    Then reboot, that leave your v4 DNS there? Should work, though it'll omit RDNSS v6 DNS IPs, that's preferable to what it does without that.



  • No change in behavior.

    I created the file as noted.

    /etc/resolvconf.conf 
    resolv_conf_passthrough=YES 
    

    Rebooted

    v4 DNS does not show.

    /etc/resolv.conf 
    nameserver 2601:a:2500:4c0:225:90ff:fef1:c230
    search localdomain 
    

    Disabled / Enabled DNS Forwarder  (unbound was never enabled)

    EDIT: Or just hit Save on the DNS Forwarder page.

    Now the v4 DNS configured in the General Setup is there.

    /etc/resolv.conf
    nameserver 127.0.0.1
    search localdomain
    nameserver 192.168.1.52
    nameserver 8.8.8.8
    

    I upgraded to the Wed Dec 03 13:29:19 build and no change.


    This isn't an operational problem for me.  But, a behavior I wanted to point out.