If dnsextd is installed on a different machine to bind (a valid configuration), then the dnsext daemon can't be started because the mDNSResponder ebuild doesn't create a 'named' user. The mDNSResponder ebuild should either create a 'named' user, or the daemon should be run as a different user ('nobody'?) With the user changed, starting the daemon results in: * Starting dnsextd ... /usr/sbin/dnsextd: invalid option -- 'z' Usage: dnsextd [-f <config file>] [-vhd] ... Use "dnsextd -h" for help * Failed to start dnsextd [ !! ] The init script starts dnsextd as: start-stop-daemon --start --quiet --user named --pid /var/run/dnsextd.pid --exec /usr/sbin/dnsextd -- -z "${DNSEXTD_ZONE}" -s "${DNSEXTD_NAMESERVER}" ${DNSEXTD_ARGS} ... so the init script needs to be updated as dnsextd no longer accepts the '-z' option. It appears that all dnsextd configuration is now contained within a conf file, available from http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-212.1/mDNSShared/dnsextd.conf (and included with the package source). This now uses a bind-like format - but I've so far been able to put together a configuration which both uses a shared key to authorise updates and which satisfies the dnsextd parser. It doesn't help that documentation and even output with verbose logging is minimal, and the the line-numbers which dnsextd reports being unable to parse are completely wrong... although it now occurs to me that it may be double-counting newlines. In any case, I was told that an errors occurred on line 121 of a ~67 line file :(
mDNSResponder has been removed.