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

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Phil,

On 04/09/2013 07:38 PM, Phil Pennock wrote:
> 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.

Is this VPN related?  There is something wrong when VPNs are used?  I
think it gets confused about nameservers, or VPN and dnssec-trigger
software conflict about updating nameserver settings.

>> 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.  :)

Ok.

>> 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.

Yes.  The tray icon menu is also something for admins, because it can
click on dialogs 'yes dnssec really fails here'.

Your colleague could use the commandline for something like:
dnssec-trigger-control status

> 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" \ 
> /etc/dnssec-trigger/dnssec_trigger_control.key sudo chmod +a "pdp 
> allow read" \ /etc/unbound/unbound_control.key 
> /etc/unbound/unbound_control.pem \ /etc/unbound/unbound_server.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).

That could be a good idea.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRZRJLAAoJEJ9vHC1+BF+NOHsP/RaO2DBF2QOKTmC/2DPcxEB8
AjLn0BPsC77RIeS+PeRu7mqajjKa/ReW+xUwc/AX6m1FQwXDZgrhTD1b7GvItB4U
qGl14hk6oufaVSuF7KdUVPah33eNojEugMt4HO8etabyAU1hEo9eGBXZYFHvzb2n
opZG27x5fk+VFQHpVHnBNXdfe5ZsaMUAPTzR+o8dJU4+df9UBw/rVWtOhdV0p2DZ
+uewKyUJutuHVUp23LLtI9jwwpt6A4JoL/xbNH8zlpq/7J3NB1p5EIsIyj5FnugY
YCCaIBbRQnfMxLmBvmn4vR0e6p/KXygYbyJWx898TUheB5+KOFbTr1dpWVM+MUSc
KaSL9shT1ztjrz67gqK/we6gS9f6j6IQerHlmGk3YvBW1Nb4v5L2dtbd4J/3nD8l
QMKOtO4TUtaldyolRVeBMzW0jovK/HOLs9eFkFnb4RteBe/zKAVN1R+i/qIBP6au
+nfS2NFprbl1BzER/DQQShQTwdn2G2xmnE+Bis9WhOjmiIbDliDEe/b6ofmwpvSB
Va4o3zLnO5ezSeDBGjnuYfKJACigRZl6EmTKdg3MR9YjzIP4l+8prbT65K3+mLJj
vJlxu173lVGwVS4fPaDkWJ7qiu65VLKtXoCWt/X+6NKrNs2tOeQd1MIQLNjuUthL
FIcKvyo0+pUbDzdoxFeS
=YVtI
-----END PGP SIGNATURE-----