notifies & bind

Kevin Darcy kcd at daimlerchrysler.com
Thu Apr 5 20:16:22 UTC 2001


NOTIFY just triggers slaves to check the SOA of a zone. At that point,
it's not following the NOTIFY protocol any more, it's following the
regular zone-transfer protocol.

In any case, if a slave server is being bombarded with NOTIFYs, this
could delay *either* the AXFRs themselves *or* the writing of the
AXFR data to the file, or *both*. When a machine is overloaded, any
number of things could get delayed.

Or, am I misunderstanding the question? Remember that inbound zone
transfers are handled by a separate process (at least this is true in
all BIND through BIND 8), so it seems *more* likely that the AXFR itself
would be delayed (because named might be too busy to fork the process),
than for there to be a delay in named-xfer writing the AXFR data to
disk. But why speculate when you can just determine this by watching the
actual behavior?


- Kevin

José M. Fandiño wrote:

> Dear friends,
>
> I'm having a silly trouble with my ISP and it's related
> to the bind behavior in the event of _massive_notifies_
> and how it manage this.
>
> It's supposed that after the notify protocol have
> completed the initial SOA check (and it's a busy server
> with +10.000 zones), ...
>
> the transfer is delayed *and* the file is wrote
> to the db file when it's received??
>
> or
>
> a transfer is do and the file is delayed in bind himself
> until the disk transfer succeed?¿have this any sense? :-?
>
> thanks,
>
> Please excuseme if my english is not correct at all.
> --
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GCS d- s+: a- C+++ UL++++$ P+ L+++ E--- W++ N+ o K- w---
> O+ M+ V- PS PE+ Y PGP+>+++ t+ 5 X+++ R- tv@ b+++ DI-- D+++
> G e- h++ !r !z
> ------END GEEK CODE BLOCK------





More information about the bind-users mailing list