bind NOTIFY protocol

[Barry Margolin]

In article <91tnei$1dv at pub3.rc.vix.com>, Jim Reid  <jim at rfc1035.com> wrote:
>NOTIFY messages are sent to the addresses of zone's NS records. A name
>server can be configured to send them to other addresses too: see the
>also-notify clause in BIND[89]. Keeping track of previous zone xfers
>is not wise: how can the server tell the difference between a slave
>server's axfr request and some random user just making an axfr with
>dig or nslookup? Think of the fun - denial of service attacks - if the
>server had to keep track of the source address of every axfr request
>it got. RFC1996 will tell you more than you probably want to know
>about the NOTIFY protocol.

BIND already keeps track of the addresses of every client or server that it
interacts with if you enable host-statistics (we've enabled this on all our
servers and haven't found it to be a big problem).  Throwing in the
addresses of AXFR clients is not likely to kill it.  And unless he made use
of a DDOS attack mechanism, a random user couldn't make axfr requests from
lots of different hosts.

We have lots of customers for whom we run primary DNS and they have stealth
secondary servers on their LANs.  We don't know which customers are doing
this, so we don't have their servers' addresses in our also-notify lists.
For this, it would be nice if named automatically sent NOTIFY messages to
those servers because they transferred from it before.  But I don't think
this is a high priority feature.  One of these days we'll probably update
our DNS configuration management software to allow us to configure
per-customer also-notify and allow-transfer settings and turn on query
logging to find out who needs it.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.