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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"