>> I was going to respond with the same advice -- >> slave your internal zones -- but then I somehow convinced myself that "recurs >> ive-clients" was merely the quota of concurrent RD=1 queries that named would >> handle, thus slaving wouldn't help in a network-outage situation, since name >> d would still drop any new RD=1 query whenever the quota was full. > > For some reason people are afraid to slave internal zones. Back > when I was working for CSIRO I used to slave all the internal zones > for all of the sites the division had. Each site administered its > own zones but all sites slaved all of them. That way local and > inter site lookups always succeeded even when the external links > were down.
Something I just thought of: how did you manage your NS records in this situation? To get NOTIFY/IXFR to work properly, either you have to list every one of your recursive servers in your local NS records or you have to do an also-notify block on the master. Or you just skip the NOTIFY/IXFR altogether and set very low refresh values on your zones! How did you handle standing up/taking down servers quickly? Another question: Is it just the master and slave zone types that bypass the recursive-clients limit? Presumably forward and stub types still come up against the limit b/c BIND still has to track a backend connection somewhere. John _______________________________________________ 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
