At 07 Jul 2015 13:47:45 +0100, Cathy Almond <cat...@isc.org> wrote: >What can happen (and this is really really subtle) is that if there are >some source ports that named could randomly select, but where >intermediate firewalls or filters are just dropping, either the SOA >refresh queries, or the responses, then named can 'get stuck' on using >and re-using the same refresh source port. >...
Thank you, that was exactly the cause, and the fix. Some years ago I'd updated a host-based firewall running on my BIND slave server to block traffic to an additional inbound UDP port that falls into the range BIND may use for ephemeral ports. At that time I neglected to add that port to BIND's config (avoid-v4-udp-ports and avoid-v6-udp-ports). When BIND picked that src port for its UDP SOA queries, the incoming SOA replies were blocked by that firewall. For some reason BIND wasn't picking that port often (or wasn't getting stuck on that port for long enough for me to notice) until I recently made an apparently unrelated config change (expanding the use of request-ixfr) to my BIND slave server. Once I made that change, BIND got stuck on that port (for all the SOA queries all the zones it pulled from various unrelated masters) for hours at a time every 1-3 days (until picking another port), exposing my latent configuration problem. Irwin Tillman OIT Networking & Monitoring Systems, Princeton 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
