DNS Resolver (unbound) / Can't change config


  • LAYER 8 Global Moderator

    Not sure where this /test dir is coming from.. I look on my /var/unbound dir and I don't see any test dir..

    I can change my unbound conf without any issues.

    Are you running 2.3.3 or 2.4 of pfsense??




  • I am currently using 2.3.2-RELEASE-p1


  • LAYER 8 Global Moderator

    So from the code it looks like that sub dir is created but then removed after the test

    
    function test_unbound_config($unboundcfg, &$output) {
    	global $g;
    	$cfgsubdir = "/test";
    	unbound_generate_config($unboundcfg, $cfgsubdir);
    	unbound_remote_control_setup($cfgsubdir);
    	do_as_unbound_user("unbound-anchor", $cfgsubdir);
    	$cfgdir = "{$g['unbound_chroot_path']}{$cfgsubdir}";
    	$rv = 0;
    	exec("/usr/local/sbin/unbound-checkconf {$cfgdir}/unbound.conf 2>&1", $output, $rv);
    	rmdir_recursive($cfgdir);
    	return $rv;
    }
    
    

    rmdir_recursive($cfgdir);

    So something is failing here?  Just not sure what..



  • I'm also having this problem. Setup pfSense from scratch on 2.3.3_p1.

    The below does indeed work once off, so I need to run it every time I change the configuration.

    mkdir /var/unbound/test/
    cp -ax /var/unbound/*.{key,pem} /var/unbound/test/
    

    Is there a bug logged for it already?



  • For me the problem is gone away and I did nothing (neither reboot).
    After updating to 2.3.3-p1 everything is still working.

    But now is happening again on another site with a fresh new installation of a 2.3.3-p1  ???



  • Ok, now I have the problem again.
    Sometimes happens and usually a reboot fixes it.



  • Just want to chime in here. Starting to see this on my pfsense running 2.3.3-RELEASE-p1 (amd64)
    Configuration created from scratch so no "old crap" should be there. The workaround with mkdir and cp works.
    Reboot doesn't solve this.



  • So to Recap:

    • Reboots - DO NOT WORK

    • mkdir Test and cp config - Works once per saved change

    • move to forwarder, wipe unbound directory and return to resolver - ? ? ? ? ?

      Anymore suggestions

      This is the message I get when making any changes

      The following input errors were detected:
      The generated config file cannot be parsed by unbound. Please correct the following errors:
      /var/unbound/test/root.key: No such file or directory
      [1494245590] unbound-checkconf[4967:0] fatal error: auto-trust-anchor-file: "/var/unbound/test/root.key" does not exist in chrootdir /var/unbound
      

      I am running:

      2.3.4-RELEASE (amd64) 
      built on Wed May 03 15:13:29 CDT 2017 
      FreeBSD 10.3-RELEASE-p19 
      
      The system is on the latest version.
      

      HELP!!!



  • Let me add to my previous, DNS is resolving all local addresses and appears to be working correctly.
    But even if I attempt to make changes directly to the dhcp.conf, hostentries.conf or dhcpleases_entries.conf the changes to not persist after a process restart.

    So this unbound config validator issue I more spread than I thought and more annoying than willing to deal with.



  • I'm facing this problem too, although not been able to clearly determine when and what triggers this.
    Depending on DNS configuration (but what?), I get this same error message.
    As far as I remember, occurred with all 2.3.x version (currently running 2.3.4)

    I'm also facing problem with, if I'm not wrong, DNS stopping from time to time when DHCP registration is activated.

    Weird  :(



  • Created redmine ticket:

    https://redmine.pfsense.org/issues/7600

    Running this command lets me do it before each save:

    echo 'mkdir /var/unbound/test; /usr/local/sbin/unbound-control-setup -d /var/unbound/test' | /usr/bin/su -m unbound
    

  • Rebel Alliance Developer Netgate

    This is not a general problem that happens out of the box or with anything I have readily available. Something specific to your setups is causing this, but it's not clear yet what that is.

    There must be some missing detail to reliably replicate it. Please compare other system settings and setup details, like what platform/architecture is in use (e.g. NanoBSD or full), if you have /var and /tmp in RAM disks, and anything else about the setup that might be different or unusual, especially any packages you have installed.



  • I remember few days ago after clean install of 2.3.4, and right after I restored 2.3.2 config, unbound was down and did not wanted to start up until I deleted the line added by pfblocker…```
    server:include: /var/unbound/pfb_dnsbl.conf

    
    Today I found unbound dead… and I blame wan lose connection that also triggered unbound death.
    https://forum.pfsense.org/index.php?topic=131242.msg723850#msg723850


  • I have also just faced this problem on my 2.3.5-RELEASE-p1 (i386) nanobsd (2g). Interesting is, that adding Host Overrides does not trigger the problem, although it changes and saves DNS Resolver configuration.



  • Just ran into this on 2.3.4-RELEASE (amd64)

    Haven't had a chance to try any of the suggestions earlier in the thread, but this is a relatively new box that hasn't been around long enough to have legacy configs. Has always been on a 2.3.x release.

    A confirmed solution would be really helpful.



  • @Veldkornet:


    The below does indeed work once off, so I need to run it every time I change the configuration.

    mkdir /var/unbound/test/
    cp -ax /var/unbound/*.{key,pem} /var/unbound/test/
    

    Is there a bug logged for it already?

    works for me.



  • This just happened to me, although my error was "/var/unbound/test/root.key" does not exist. I tried creating the test directory and copying the root.key there, but there was no change. I still couldn't save the settings for DNS Resolver.

    However, I seemed to fix it by running the command: unbound-control-setup

    I'd be interested to hear if this helped anyone else.



  • This issue is known, as the thread implies.
    But 2.3.5 is old and fading out : 32 hardware is hard to find these days - some devices are kept artificially alive, mostly in museums.
    Consider the issue as closed.



  • I am running 64 bit, 2.4.4-RELEASE-p1



  • In that case, the issue is totally new - not related to what happened as described 2 years ago - with old pfSense versions.

    Maybe some left-overs from an ancient install ?
    Did you install 2.4.4-P1 from scratch, or did you upgrade from an older version ?