The keyword is used to add a search line in /etc/resolv.conf and all apparently is well; unfortunately, the first time an edit is made with the gui the keyword is lost, possibly because there is no corresponding input box.
Couple of questions:
how do I verify that the gui is indeed purging the keyword? I mean, I saw the effects on the config file but I'd like to see the code responsible for that and I'm a bit lost with respect to Luci
is there a proper way to add this option in a way that survives a gui edit? I cannot use the two "ext" files because the keyword has no effect on the generated unbound.conf, rather on another file
@EricLuehrsen should I file a bug for this? I had a look now and there doesn't seem to be an open issue already.
EDIT: for the moment, I'll edit /usr/lib/unbound/unbound.sh (config_get UB_TXT_DOMAIN "$cfg" domain lan) and change the default to my domain but this is not optimal.
EDIT n.2: I'm talking about 19.07.3, with unbound-daemon-heavy - 1.10.1-1
Ofc it is purged by LuCI script. LuCI GUI (/etc/config/unbound) supports only those entries which can be made by GUI also.
For entries not supported by LuCI are the files /etc/unbound/unbound_ext.conf and ../unbound_ext.conf. They will be passed by LuCI to a final config file placed in /tmp/lib/unbound including data filled up by LuCI like local domain "lan". This is the location where you can see if its purged (its a chroot).
In this both files (ext, srv) you can make your additional enties. BUT they have to have the unbound syntax and NOT the LuCI syntax "option blah blah".
Other way is to activate the button "Manual Conf" within LuCI and make ALL the stuff within /etc/unbound/unbound.conf by yourself.
e. g.:
domain-insecure: lan # drop dnssec
private-domain: lan # allow private adresses within lan
local-zone: lan transparent # option transparent for what to do with matching traffic
Replace "lan" with your desired domain name and put it into srv file.
No use, I've tried: the generated config is identical in both cases, that is with and without a "option domain" keyword because the keyword doesn't affect unbound. Also, the Readme recommends adding this option for the serial mode so it's kind of odd that it is then lost. EDIT: yes, I've also tried "domain" without option, which crashlooped unbound
I'm not fond of throwing the baby away with the bathwater
The way I see it, this is a shared responsibility between the unbound init script and Luci: one relies on this keyword being present to update resolv.conf and the other one strips it. Way out? Adding support in Luci or changing the behaviour with respect to "gui-less" keywords or perhaps yet something else.
This lines above are done automatically by LuCI (just an expample). The keyword is "option" here and the syntax in all. This syntax is wrong for srv and ext file! You have to do it like above. If i put the three lines above into srv file it is included within chroot directory srv file. unbound.conf is pointing to srv and ext file. The readme is for openwrt unbound and not for regular unbound. It is not clear about syntax in ext and srv file.
Hybrid Manual/UCI
You like the UCI. Yet, you need to add some difficult to standardize options, or just are not ready to make a UCI request yet. The files /etc/unbound/unbound_srv.conf and /etc/unbound/unbound_ext.conf will be copied to Unbounds chroot directory and included during auto generation.
The file unbound_srv.conf will be added into the server: clause. The file unbound_ext.conf will be added to the end of all configuration. It is for extended forward-zone:, stub-zone:, auth-zone:, and view: clauses. You can also disable unbound-control in the UCI which only allows "localhost" connections unencrypted, and then add an encrypted remote control: clause.
After restart /etc/init.d/unbound the resolve should work. And there has to be no entry in resolv.conf. Cause unbound is doing it! There has to be only ::1 and 127.0.0.1. Which redirects to unbound#53.
Actually I cannot test it because my local resolver is dnsmasq. Don't want to reconfigure right now. But the files getting updated correctly. So it should work.
I have tried both "option domain mydomain" and "domain mydomain": the generated files are the same and the resolv.conf still points to the default, wrong, domain. Forget about the chroot config, that's really NOT the issue here.
Uhm, could you expand your thoughts a little bit?
As far as I am concerned, unbound is running just fine: the issue here is the local resolver expanding a shortname to the wrong fqdn because a config keyword is lost.
option domain 'blah' is a supported UCI entry and is there in GUI (LuCI) as supported. If it is being deleted by LuCI that is wrong and an error. I don't use the GUI (just edit the /etc/config/unbound config), but if you are sure than a bug report here
Hmm ... I don't have an entry for this in my GUI. But the quotes 'blah' make me think that there is the error if its not working and getting deleted? oO
I'm probably wrong with this statement. It's a long time ago I started using unbound in connection with OpenWrt. In the past I had issues like that and came to the conclusion to not mix settings which are not included in LuCI GUI. For me this was valid since LEDE. Maybe things changed since.
And if I look into the definition:
option domain 'lan'
Unbound local-zone: . This is used to suffix all
host records, and maintain a local zone. When dnsmasq is dhcp_link
however, then this option is ignored (dnsmasq does it all).
The option is ignored if dnsmasq is involved. So for me the behavior looks like correct if dnsmasq is linked into unbound (maybe there is the error). And as I'm using dnsmasq I don't have a field in GUI to change the domain. But I think my knowledge is outdated. So I stop posting here to avoid chaos.
