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:d...@dotat.at] Sent: August-05-19 11:21 AM To: LeBlanc, Daniel James Cc: ML BIND Users (bind-users@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.lebl...@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 <d...@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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
