RE: DNSSEC Error Log - named[4132]: managed-keys-zone/“externals”: Unable to fetch DNSKEY set '.': timed out

LeBlanc, Daniel James daniel.leblanc at bellaliant.ca
Tue Aug 6 11:43:32 UTC 2019


Hi Tony.

Thanks for your detailed response.

We do have ACLs in place for the internals and externals views, which partly explains the differences in behaviour.

Our authoritative servers are not sending notifies anywhere, and we use only IPs within the config file (Ansible managed) so I wouldn’t expect that any NS records are being resolved.

We have also deployed a separate set of recursive servers for inbound queries from customer networks, but still retained a small recursive capability on our authoritative servers for our own internal servers (much lower risk).  It would be possible to direct all of our internal servers to the recursive servers and disable recursion entirely on our authoritative servers, but we are not quite there yet.

If the named configuration does not support disabling the trust anchor maintenance for one view, perhaps I could open up recursion on our "externals" view for only the authoritative server itself.  This would allow the trust anchor maintenance to complete its lookups.

I am still open to any other suggestions from members of this list.

Thanks!

Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada

-----Original Message-----
From: Tony Finch [mailto:dot at dotat.at] 
Sent: August-05-19 11:21 AM
To: LeBlanc, Daniel James
Cc: ML BIND Users (bind-users at lists.isc.org); Lavigne-Giroux, Simon
Subject: [EXT]Re: DNSSEC Error Log - named[4132]: managed-keys-zone/“externals”: Unable to fetch DNSKEY set '.': timed out

LeBlanc, Daniel James <daniel.leblanc at bellaliant.ca> wrote:
>
> This is occurring only on my authoritative servers and only for the view
> that I do not have recursion enabled for (the “externals” view; the
> “internals” view has recursion enabled and it is working).

It's curious that trust anchor maintenance works for one view but not the
other. Do you have query-source settings and packet filters that would
affect one view but not the other?

Authoritative servers do perform outgoing queries to resolve NS records
for sending notifies, and that is why your "externals" view is trying to
do things that you might think are just for recursive service. In most
cases you should make sure all BIND servers can do root priming and trust
anchor maintenance.

A tangential question of my own... I have deliberately kept our recursive
and authoritative servers separate. Partly this is to stop attack traffic
aimed at our auth servers from affecting recursive service. And partly to
stop myself from getting too clever with views (it is a wicked
temptation). The downside is having more kinds of servers to maintain. On
the gripping hand I'm thinking of separating auth service from xfer
service. The xfer IP addresses get wired into lots of other people's
configurations, whereas I would like more agility in how our auth service
is provisioned. I'm wonder how others balance these tradeoffs?

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Viking, North Utsire, South Utsire: Southeasterly, becoming cyclonic 2 to 4,
occasionally 5 in Viking. Smooth or slight. Rain or thundery showers. Good
occasionally poor.
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints


More information about the bind-users mailing list