Date: Wed, 24 Nov 1999 21:26:13 -0500 (EST) From: Robert Gash <gashalot@gashalot.com> To: Mike Tancsa <mike@sentex.net> Cc: questions@freebsd.org Subject: Re: BIND 8.2.2pl5 NOTIFY problems Message-ID: <Pine.LNX.4.20.9911242108480.1932-100000@raq.tabernae.com> In-Reply-To: <383c8dc1.247400743@mail.sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually, after 3 more hours of digging through the BIND docs and deja.com I found the problem. For the benefit of future freebsd-questions list surfers I will briefly explain the problem, why it was a problem, and how I fixed it. Simple network topology: Internet | +----------------+ | +---------------+ | mailsvr1 (ns1) | +------------+ | websvr1 (ns2) | | main IP: .129 |-fxp0-| Cisco |-fxp0-| main IP: .130 | | alias IP: .133 | | Catalyst | | aliasIP: .134 | +----------------+ +------------+ +---------------+ I currently only have about 1800 domains in the nameservers, but I know this number will grow very rapidly, so I choose to allocate 2 extra IPs for ns1 and ns2 to the machines, that way if I ever needed a standalone nameserver(s) I could simply configure them with the ns1 and ns2 alias IPs and unalias them from the other machines. This would effectively move (painlessly and w/o InterNIC mods) all NS functions off of my mail and web servers with minimal downtime. However, this dual-IP configuration was the problem. The bind processes wanted to talk to each other using the main IPs (.129 and .130). To make the future movement process easier, all of my bind config files reference .133 and .134, so they don't need touching if I ever offload. The problem was, ns2 referenced .133 for all of the master { }; blocks for the slaved zone files, therefore when ns1 sent out the NOTIFY from .129 ns2 discarded it because it did not originate from the master. The fix for this problem was simple, but not immediately obvious: fix bind so that all inter-nameserver communication uses the .133 and .134 IP addresses. This task can be accomplished by the following configuration directives: ----- ns1 named.conf ----- options { /* .... the other config options were here .... */ transfer-source xxx.xx.xxx.133; query-source address xxx.xx.xxx.133 port *; /* .... some more options here .... */ }; -------------------------- And the same goes for ns2 (replacing 133 with 134). This forces the notify (query-source) and the transfers (transfer-source) to come from the .133 and .134 IP addresses. Now ns2 believes ns1 when ns1 sends notifys because they originate from the IP address configured in the zone master { } blocks on ns2. This also has the added benefit of making all other queries to other nameservers and such originate from the .133 and .134 IPs, so when you roll to external systems it appears that you have always been using them. -R On Thu, 25 Nov 1999, Mike Tancsa wrote: > On 24 Nov 1999 13:58:19 -0500, in sentex.lists.freebsd.questions you wrote: > > >I recently upgraded from bind 8.1.2 to bind 8.2.2pl5 (the FreeBSD port of > >bind 8.2.2pl5), and after the upgrade the NOTIFY's between ns1 and ns2 > >quit working properly (I have to manually issue an ndc reload ZONE to get > >the nameservers to sync). I have specified the "notify yes;" directive in > >the named.conf file and everything else appears to be working fine, does > >anyone know why my nameserver wouldn't be sending the notify's > >properly? > > Is there anything in the logging on either end ? > > In the options section, you may want > > named-xfer "/usr/local/libexec/named-xfer"; // _PATH_XFER > > > ---Mike > Mike Tancsa (mdtancsa@sentex.net) > Sentex Communications Corp, > Waterloo, Ontario, Canada > "Given enough time, 100 monkeys on 100 routers > could setup a national IP network." (KDW2) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.9911242108480.1932-100000>