Currently dnssec-trigger writes trusted validating nameservers to /etc/resolv.conf just as any other tool would. The only distinguishing feature is that it sets the immutable bit afterwards, but that's not a sufficient way to express that the name servers are to be trusted.
Created attachment 958529 [details] patch to use a symbolic link The least dnssec-trigger can do is to use a symlink pointing to its own directory instead an actual file. This has numerous advantages and has been also proposed by resolved developers who can make use of the symlinks to distinguish certain configurations. I've been happily using this patch for a while now.
s/to its own directory/to a file in its own directory/
(In reply to Pavel Šimerda (pavlix) from comment #0) > Currently dnssec-trigger writes trusted validating nameservers to > /etc/resolv.conf just as any other tool would. The only distinguishing > feature is that it sets the immutable bit afterwards, but that's not a > sufficient way to express that the name servers are to be trusted. The purpose of the immutable bit is not to express that the name servers are to be trusted. It is a mechanism to prevent other (potentially malicious) software from changing the content of resolv.conf!
Created attachment 958547 [details] updated patch The new patch fixes issues with missing files and also creates an additional symlink /etc/resolv-secure.conf. The new symlink clearly expresses that the included name servers are to be trusted for dnssec validation. Any application or library can use it to confirm that the AD flag is to be trusted, while it would clear out the AD flag otherwise.
(In reply to Tomas Hozza from comment #3) > > that's not a > > sufficient way to express that the name servers are to be trusted. > > The purpose of the immutable bit is not to express that the name servers are > to be trusted. That's exactly why I wrote it that way.
Additional security note. The way it works, i.e. that /etc/resolv.conf and /etc/resolv-secure.conf are just symlinks to the same data have one great advantage that the target file, as well as /etc/resolv-secure.conf symlink, could be covered by a selinux policy that would only allow dnssec-trigger (and the unconfined administrator of course) to change them. The /etc/resolv.conf would still need somewhat more open policy so that for example NetworkManager can write it when dnssec-trigger is turned off or not installed. The good thing is, that even priviliged apps that look up the target of the /etc/resolv.conf symlink, wouldn't be able to write to the target. The bad thing is that those apps would have to be fixed so that they don't attempt to do that.
(In reply to Pavel Šimerda (pavlix) from comment #6) > apps would have to be fixed so that they don't attempt to do that. Or at least to attempt to remove the symlink first.
Fixed in rawhide, moving to F21.
dnssec-trigger-0.12-18.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnssec-trigger-0.12-18.fc21
Package dnssec-trigger-0.12-18.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnssec-trigger-0.12-18.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1279/dnssec-trigger-0.12-18.fc21 then log in and leave karma (feedback).
dnssec-trigger-0.12-19.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/FEDORA-2015-3864/dnssec-trigger-0.12-19.fc22
dnssec-trigger-0.12-19.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2015-3843/dnssec-trigger-0.12-19.fc21
dnssec-trigger-0.12-19.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
dnssec-trigger-0.12-20.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.