[Dnssec-trigger] Resolution on resume from hibernate (MacOS 10.8)

Phil Pennock dnssec-trigger+phil at spodhuis.org
Tue Apr 9 17:38:35 UTC 2013

Hash: RIPEMD160

On 2013-04-09 at 15:22 +0200, W.C.A. Wijngaards wrote:
> http://nlnetlabs.nl/~wouter/dnssectrigger-0.12_20130409.dmg
> You can install it over your current 0.11.  It includes newer ldns and
> unbound versions as well as some OSX specific improvements in
> dnssec-trigger:
> - install on Mountain Lion
> - phil's search domain patch for OSX.
> - hibernation fix for OSX

A colleague installed, reported that DNS resolution was broken, same as
before when he tried 0.11, uninstalled, got DNS resolution back.

I'll take a look, if I can persuade him, when I'm in the same town as
him next week.

> If you have this, does that still need a kill of mDNSResponder?

Will let you know when I've been through a few hibernate/resume cycles
without issue.  :)

> If adventurous users feel like it, go on and try out this version, it
> should hopefully remove OSX irritations.

I was slightly disconcerted that
/etc/dnssec-trigger/dnssec_trigger_control.key is now installed 0644
since the "submit" command means an untrusted service account can now
subvert DNS for the more trusted accounts.

Of course, since my "trusted" account runs a web-browser, that's not a
clear point in favour of the distinction being meaningful.  On a server,
I think it is more meaningful.

For myself, my logbook shows I used:

sudo chmod +a "pdp allow read" \
sudo chmod +a "pdp allow read" \
	/etc/unbound/unbound_control.key /etc/unbound/unbound_control.pem \

I suspect that the right approach, on MacOS, is to use the "admin"
group, so `chmod +a "group:admin allow read" $files` should be the
safest invocation (handling when a user called admin exists too).

- -Phil


More information about the dnssec-trigger mailing list