Description of problem: Oct 15 10:47:27 vimes unbound-checkconf[4330]: /etc/unbound/unbound.conf:742: error: syntax error Oct 15 10:47:27 vimes unbound-checkconf[4330]: read /etc/unbound/unbound.conf failed: 1 errors in configuration file Version-Release number of selected component (if applicable): unbound-1.6.6-2.fc26 How reproducible: Every time Steps to Reproduce: 1. upgrade to 1.6.6-2.fc26 from updates-testing 2. reboot 3. No name resolution, config syntax error above in the journal Actual results: unbound fails to start Expected results: unbound 1.6.3-1.fc26 starts normally Additional info: I'm also running glibc-2.25-12.fc26 form updates-testing. The changelog shows some DNS stub resolver fixes, build issue?
I cannot reproduce this. It likely means this is related to something in your old config file that no longer works? Please show me the actual parse errors from running unbound-checkconf
That's all unbound-checkconf is telling me: Oct 16 19:14:48 vimes unbound-checkconf[16003]: /etc/unbound/unbound.conf:742: error: syntax error Oct 16 19:14:48 vimes unbound-checkconf[16003]: read /etc/unbound/unbound.conf failed: 1 errors in configuration file O Same from command line: [d@vimes ~]$ unbound-checkconf /etc/unbound/unbound.conf:742: error: syntax error read /etc/unbound/unbound.conf failed: 1 errors in configuration file Attaching my /etc/unbound/unbound.conf here - IIRC I haven't modified it from the default.
Created attachment 1339509 [details] /etc/unbound/unbound.conf
I should add, I'm using unbound with NetworkManager set to dns=unbound in its configuration.
It's complaining about the ipsec-mod line, suggesting that support has not been compiled in or loaded. But the ipsecmod is loaded in the modules line. And all fedora versions 1.6.4+ have had ipsec-mod enabled. The only thing I can think of is that your unbound is not 1.6.4+ and somehow you are starting/running an older version. Your file is fine: paul@thinkpad:~/fedora/unbound (f26)$ unbound-checkconf /tmp/unbound.conf unbound-checkconf: no errors in /tmp/unbound.conf paul@thinkpad:~/fedora/unbound (f26)$ sudo unbound -c /tmp/unbound.conf paul@thinkpad:~/fedora/unbound (f26)$ pidof unbound 12212
Created attachment 1340502 [details] unbound versions before/after upgrade Hm, the previous release in F26 stable seems to be 1.6.3 - which does *not* fail even though it doesn't seem to have ipsec-mod enabled. the 1.6.6 version installed from updates-testing does have ipsec-mod, and is failing. Does ipsec-mod depend on a library that's not in the unbound package dependencies?
OK, I think I found the problem. I had forgotten about this included config file located at /etc/unbound/local.d/lan.conf: domain-insecure: "lan" forward-zone: name: "lan" forward-addr: 192.168.1.1 My probably not-so-well-configured OpenWRT home router uses .lan as the domain for all local machines, and IIRC this was my attempt to make DNS work for this laptop when on the house network. After I renamed that file to lan.conf.disabled to take it out of the include pattern, 1.6.6 is now working. I'm not sure why this would manifest as a syntax error in line 742 of the main config file though. Also, the syntax error is very misleading. Anyway, I'll rename this bug but I'll leave it open as fixing the syntax error reporting seems worthwhile.
I was just bit by the same issue. Moving my configuration file from local.d to conf.d resolved the issue.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The problem manifests itself when a file in /etc/unbound/local.d/ opens a new block ("forward-zone:" in the case above) In the earlier unbound versions the "include: /etc/unbound/local.d/*.conf" line in the default /etc/unbound/unbound.conf was the last non-commented line in the "server:" block. In 1.6.6+ /etc/unbound/unbound.conf some more non-commented settings ("ipsecmod-enabled: no" for instance) related to the "server:" block were added after the "include: /etc/unbound/local.d/*.conf" statement. If included file opens a new section - then the lines below the include statement will fall into that section, in this case, causing the resulting config to look like this: server: . . . val-log-level: 1 # include of /etc/unbound/local.d/lan.conf starts here domain-insecure: "lan" forward-zone: name: "lan" forward-addr: 192.168.1.1 # include of /etc/unbound/local.d/lan.conf ends here ipsecmod-enabled: no There is no "ipsecmod-enabled" setting in "forward-zone" block, hence the error message related to this line in the main config. This and similar problems may be prevented by moving the include statement at the end of the "server:" block. This is also an issue on the recently released EL 7.5 which uses unbound 1.6.6 as well.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.