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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

LeBlanc, Daniel James

Hello All.

 

I am receiving the following log entry a couple of times per hour on my ISC BIND 9.14.0 VMs:

 

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

 

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).  I determined this as follows:

 

~]$ sudo /var/named/sbin/rndc secroots -

secure roots as of 02-Aug-2019 10:24:22.455:

 

Start view “internals”

   Secure roots:

 

./RSASHA256/20326 ; managed

 

   Negative trust anchors:

 

 

Start view “externals”

   Secure roots:

 

./RSASHA256/20326 ; initializing managed

./RSASHA256/19036 ; initializing managed

 

   Negative trust anchors:

 

 

I have the following statements defined in options:

 

bindkeys-file "keys/bind.keys";

dnssec-enable yes;
dnssec-validation auto;
dnssec-accept-expired no;
dnssec-lookaside no;

 

Is there a way that I can disable the managed-key lookups for the “externals” view while leaving it in place for the “internals” view?  I tried moving the bindkeys-file to the internals view only but named wouldn’t start.

 

Thanks!

 

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

 


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Tony Finch
LeBlanc, Daniel James <[hidden email]> 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  <[hidden email]>  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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

LeBlanc, Daniel James
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:[hidden email]]
Sent: August-05-19 11:21 AM
To: LeBlanc, Daniel James
Cc: ML BIND Users ([hidden email]); 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 <[hidden email]> 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  <[hidden email]>  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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Tony Finch
LeBlanc, Daniel James <[hidden email]> wrote:
>
> 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.

You need to have `notify no` or `notify explicit` in the authoritative
view, and you might also need to set `dnssec-validation no` in the global
options and move `dnssec-validation auto` into the recursive view.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Mull of Kintyre to Ardnamurchan Point: Variable becoming northwest, 3 or 4.
Slight, occasionally smooth in shelter. Showers, thundery at first. Good
occasionally poor at first.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users