When bind ist started during system startup in the default runlevel, it fails to seek normal operation, alle name lookups fail. Reproducible: Always Steps to Reproduce: 1.emerge net-dns/bind-9.12.2_p1 2.add to default runlevel Actual Results: Failure to resolve any name. Expected Results: Normal Operation. Excerpt from log when bind is started during boot: Aug 31 22:03:31 localhost named[2558]: all zones loaded Aug 31 22:03:31 localhost named[2558]: running Aug 31 22:03:37 localhost named[2558]: validating ./NS: got insecure response; parent indicates it should be secure Aug 31 22:03:37 localhost named[2558]: insecurity proof failed resolving './NS/IN': 199.7.91.13#53 Aug 31 22:03:38 localhost named[2558]: success resolving './DNSKEY' (in '.'?) after disabling EDNS Aug 31 22:03:38 localhost named[2558]: managed-keys-zone: No DNSKEY RRSIGs found for '.': success Aug 31 22:03:38 localhost named[2558]: validating ./NS: no valid signature found Aug 31 22:03:38 localhost named[2558]: no valid RRSIG resolving './NS/IN': 198.97.190.53#53 However once the system is up and bind gets restarted, or if not started during boot but right after I can log into the system, the logs show: Aug 31 22:04:01 localhost named[2880]: all zones loaded Aug 31 22:04:01 localhost named[2880]: running Aug 31 22:04:01 localhost named[2880]: managed-keys-zone: Key 19036 for zone . is now trusted (acceptance timer complete) Aug 31 22:04:01 localhost named[2880]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete) Aug 31 22:04:01 localhost named[2880]: resolver priming query complete And names are resolved as expected.
It is sad to read that you have problems with the software. The situation seems to be a bit more complicate and requires some analysis. We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3]. I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4]. Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product. [1] https://www.gentoo.org/get-involved/irc-channels/ [2] https://forums.gentoo.org/ [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html [4] https://www.gentoo.org/support/
(In reply to Jonas Stein from comment #1) > It is sad to read that you have problems with the software. The situation > seems to be a bit more complicate and requires some analysis. > We can not help you efficiently via bug tracker. The bug tracker aims rather > on specific problems in .ebuilds and less on individual systems. > > I have had very good experience on the gentoo IRC [1] with questions like > this. Of course there are also forums and mailing lists [2,3]. > I hope you understand, that I will close the bug here therefore and wish you > good luck on one of the mentioned channels [4]. > Please reopen the ticket in order to provide an indication for an specific > error in an ebuild or any gentoo related product. > > [1] https://www.gentoo.org/get-involved/irc-channels/ > [2] https://forums.gentoo.org/ > [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html > [4] https://www.gentoo.org/support/ So you are saying bugs in packages are not to be reported in the bugtracker? Extra info: when I start bind during boot and add a small delay in it's startup script everything works fine. There's obviously some problem with either a race or incomplete dep.
So, I managed to pin this down and fix it - indded it is a dep problem regarding openrc. The init script needs net and net is considered provided, as soon as all interfaces are configured. So bind starts up right away after the interfaces are configured which is perfectly fine, when bind is working as authoriative server solely. However when bind operates as recursor or resolver, it needs a working uplink at starttime, otherwise it will refuse operation, even when the uplink becomes ready. So whenever bind runs as resolver/recursor it needs net-online, the physical link must be up and working before it recieves the first request to the recursor. So, depending on setup net is an insufficient dependency for bind.
