Quota error message

[Kevin Darcy]

Justin Scott wrote:
> I am running BIND 9.4.2 on Windows Server 2003 and am having some
> trouble with domain transfers.  Everything will run fine for a while and
> eventually I start seeing errors like this:
>
> AXFR request denied: quota reached
>
> When those start showing up it will not perform any zone transfer
> operations (incoming or outgoing).  So my questions are:  1) What does
> this error mean internally, 2) Is there a config option I can use to
> increase this quota, and 3) Are there other steps I can take to minimize
> this issue.  Thanks in advance for any assistance.
>   
1) Your outbound-transfers quota has been reached
2) The "transfers-out" global option
3) If you have no capacity issues on the box, raising the quota should, 
in and of itself, do the trick. If you do have capacity issues, then 
your options are either a) get more resources (e.g. upgrade the server 
hardware, upgrade network hardware/bandwidth so that zone transfers 
don't take as long), b) free up more resources on the box by moving 
other apps or other functions (e.g. the recursive resolver function) 
from it and/or c) reduce the zone transfer volume. Other than the 
obvious ones (i.e. reduce the amount of data in the DNS database or 
reduce the number of changes that are made), there are various "tunable" 
ways to reduce zone transfer volume:

i) raise your REFRESH settings
ii) implement IXFR universally (if it isn't universal already in your 
environment),
iii) tune your NOTIFYs,
iv) moving even further up the food chain, batching your updates by zone 
so that less transfers are necessary (in order to properly implement 
this you'd have to also spread out the batches of updates over different 
time periods, e.g. changes to subdomain1.example.com are only committed 
at 10am, 2pm, 6pm, 10pm, and changes to subdomain2.example.com are only 
committed at 8am, noon, 4pm, 8pm.) This approach might not be practical 
for high-update-volume environments, or in cases where updates are made 
dynamically and relatively unpredictably, e.g. by a DHCP server, and/or
v) in conjunction with any or all of the measures above, splitting or 
merging your zones so as to minimize the amount of concurrent zone 
transfers (if you're using IXFR, combining zones may be a win because 
you're eliminating some of the per-transfer overhead at essentially no 
cost since you're only transferring the changes regardless of the size 
of the zone; conversely, if you're stuck with using AXFR, large zones 
take longer to transfer and so you may find that splitting off zones 
which change infrequently may reduce the overall residency time of your 
zone transfers, the downsides being more records overall, because of the 
zone splits (NS/SOA records), more per-transfer overhead, more 
configuration complexity and more NOTIFY and/or zone-refresh traffic).

Note that, with the exception of (ii), all of these measures are likely 
to increase the amount of time it takes for changes to propagate. That's 
always the tradeoff -- replication overhead versus time-to-propagate. 
But with your current situation of failed zone transfers, you're 
presumably already suffering from propagation delays; even in the worst 
case, these measures merely make the propagation delays somewhat 
*predictably* long.

If you care a lot about propagation delay, and don't really have a 
capacity problem, just occasional failures due to "spikes" in 
zone-transfer activity, and you're apprehensive about raising your 
transfers-out quota for fear of *creating* a capacity problem, you might 
want to consider just tuning your RETRY values so that the slaves 
recover quickly from failed zone-transfer attempts.

- Kevin