Unbound/NSD rc startup order

[Matt Smith]

On Dec 11 10:51, Matt Smith wrote:
>Hi,
>
>I have run Unbound and NSD for a long time and everything was working 
>fine until the recent 1.5.x update for Unbound. Now if I reboot my 
>server I get DNSSEC validation errors for my own local domain until I 
>restart Unbound once again. I believe this is possibly related to the 
>rc startup order.
>
>My setup is that I have my local domain as an authoritative DNSSEC 
>signed zone in NSD and then I use a stub-zone in Unbound which points 
>to the NSD instance.  I also hard-wire the DNSSEC key for this domain 
>into Unbound using a trust-anchor-file declaration.
>
>When I rebooted my server last night this domain was failing 
>validation with this error:
>
>info: validation failure <host.example.com. A IN>: no DNSKEY rrset for 
>trust anchor example.com. while building chain of trust
>
>If I restart unbound again then it works fine. The default rcorder is 
>to start Unbound first followed by Unbound. I'm wondering if since 
>1.5.x Unbound now attempts to read some data from the stub-zone which 
>fails because NSD isn't running but then when I restart it it works 
>successfully?
>
>As a test I added nsd as a REQUIRE in the unbound rc.d script, 
>rebooted again, and saw that it successfully worked as it did before I 
>upgraded.  It could just be an unrelated coincidence, but if it isn't 
>I'm thinking the default rc order should maybe be changed for these 
>ports?

Somebody has let me know that I made an obvious mistake in the above. I 
meant that the default rcorder is to run Unbound first followed by NSD.  
So to clarify I think in the default situation Unbound starts first, 
contacts NSD and gets no answer because it hasn't been started yet and 
then fails in some way.  Whereas if NSD is running first then Unbound is 
happy.

-- 
Matt