What to report for refresh: failure trying master ... operation canceled bug?
Howdy, We’ve noticed the error message refresh: failure trying master ...: operation canceled” in our logs debugged from some slaves not updating DS records in some zones. Looking into this error over at: https://deepthought.isc.org/article/AA-01213/0/What-causes-refresh:-failure-trying-master-...:-operation-canceled-error-messages.html So far we have updated the RHEL6 kernel on the slaves which did nothing. We have disabled the netfilter module which does seem to resolve the issue in our limited testing, but our sysadmins would like to continue use of this module for other reasons. My question: What information would be most useful in our incoming bug report? — Raymond Walker Software Systems Engineer StSp ITS Northern Arizona University ___ 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
RE: bad zone not loaded
Many thanks for your help. I will focus now on my provisionning system. Date: Wed, 4 Feb 2015 08:42:40 -0500 From: a...@clegg.com To: bind-users@lists.isc.org Subject: Re: bad zone not loaded -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2/3/15 8:43 AM, hugo hugoo wrote: Sometime my provisionning system provision a bad record ina zone. Example A record with 1.2.3.4.5 value (just an example). The point of a provisioning system is to keep this type of problem from happening. The correct answer? FIX YOUR PROVISIONING SYSTEM. AlanC -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU0iHQAAoJEOW2o5eiJADb3+0H/0bQoL6DGHqL7K6pdiwFnjOt 33pMu/FsR8iM1NZ+dH7diGrR6Ds5RK0BK8rZJl+xEgQ2t990yN6BrTxQ/IMv8xZt KEHFLf3ug4HK5IsLRN+rS2IdGxih4YH/CAtFgwgHNQcbZhcLodLTG9PNGqRWCn4S N8jL3dY8v05PUehZt0UQPTxD8ozjK9XxmCX5IBJHKY6hfbQNl64gwK8XjykCStJo EwMUI8V9DVE76ycgj5k8ucqPUMNU34xylI3mFHBa7lNIB/N0MkUmJcL3pIzdL1fN QkHP4wN/d4/crw1sZQeyBwEzHQWM4ytEAGxBN4gOfa/stjS6E3FKxuggazEn1Pc= =5BpS -END PGP SIGNATURE- ___ 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 ___ 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
Re: 'error (chase DS servers)' for static-stub zones
Graham Clinch g.cli...@lancaster.ac.uk wrote: What does 'lame-servers: error (chase DS servers) resolving [...]' really mean, and is it really an error? It seems to be: pause the current resolution whilst I start another round to fetch a (DS) record from the parent zone, but once that completes, everything works out. In particular, I see this for the first resolution within a static-stub zone. I am not getting this error in my logs. I have a number of static-stub zones; the interesting ones wrt DS chasing are cam.ac.uk (signed) and private.cam.ac.uk (unsigned). My setup led to this change which appeared in 9.9.5: 3689. [bug] Fixed a bug causing an insecure delegation from one static-stub zone to another to fail with a broken trust chain. [RT #35081] I suppose that the usual process of resolution would involve iterating down and so any DS record(s) would come in from the parent whilst discovering the delegation NS records, but with static-stub there's no need to know the delegation NS records. Sadly BIND does not make use of DS records in referrals and re-fetches them explicitly. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southeast Fitzroy: Northerly or northeasterly 6 to gale 8. Rough. Showers. Good. ___ 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
'error (chase DS servers)' for static-stub zones
Hi Folks, What does 'lame-servers: error (chase DS servers) resolving [...]' really mean, and is it really an error? It seems to be: pause the current resolution whilst I start another round to fetch a (DS) record from the parent zone, but once that completes, everything works out. In particular, I see this for the first resolution within a static-stub zone. I suppose that the usual process of resolution would involve iterating down and so any DS record(s) would come in from the parent whilst discovering the delegation NS records, but with static-stub there's no need to know the delegation NS records. In short, is it expected behaviour to see a 'chase DS servers' error occasionally (once every DS-record TTL?) for static-stubbed zones? Graham ___ 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
Re: 'error (chase DS servers)' for static-stub zones
Graham Clinch g.cli...@lancaster.ac.uk wrote: Are these static-stub zones configured with 'server-names'? Ours are 'server-addresses' Mine use server-addresses too. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Cromarty, Forth: Northwesterly 4 or 5, occasionally 6 in east at first, decreasing 3 or 4 later. Slight or moderate. Showers then occasional rain. Moderate or good. ___ 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
Re: bad zone not loaded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2/3/15 8:43 AM, hugo hugoo wrote: Sometime my provisionning system provision a bad record ina zone. Example A record with 1.2.3.4.5 value (just an example). The point of a provisioning system is to keep this type of problem from happening. The correct answer? FIX YOUR PROVISIONING SYSTEM. AlanC -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU0iHQAAoJEOW2o5eiJADb3+0H/0bQoL6DGHqL7K6pdiwFnjOt 33pMu/FsR8iM1NZ+dH7diGrR6Ds5RK0BK8rZJl+xEgQ2t990yN6BrTxQ/IMv8xZt KEHFLf3ug4HK5IsLRN+rS2IdGxih4YH/CAtFgwgHNQcbZhcLodLTG9PNGqRWCn4S N8jL3dY8v05PUehZt0UQPTxD8ozjK9XxmCX5IBJHKY6hfbQNl64gwK8XjykCStJo EwMUI8V9DVE76ycgj5k8ucqPUMNU34xylI3mFHBa7lNIB/N0MkUmJcL3pIzdL1fN QkHP4wN/d4/crw1sZQeyBwEzHQWM4ytEAGxBN4gOfa/stjS6E3FKxuggazEn1Pc= =5BpS -END PGP SIGNATURE- ___ 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
Re: 'error (chase DS servers)' for static-stub zones
On 04/02/2015 13:04, Tony Finch wrote: Graham Clinch g.cli...@lancaster.ac.uk wrote: What does 'lame-servers: error (chase DS servers) resolving [...]' really mean, and is it really an error? [snip] In particular, I see this for the first resolution within a static-stub zone. I am not getting this error in my logs. I have a number of static-stub zones; the interesting ones wrt DS chasing are cam.ac.uk (signed) and private.cam.ac.uk (unsigned). Are these static-stub zones configured with 'server-names'? Ours are 'server-addresses', and I imagine that the additional resolution caused by server-names might improve the chance of finding the DS record already cached. Graham ___ 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
