bind 9.4.1-p1

Mark Andrews Mark_Andrews at isc.org
Fri Oct 26 00:32:39 UTC 2007


> There was a transfer-source option in the config that was causing the
> problem. I don't quite understand why it was causing a problem. Unless i
> misunderstand the tranfer-source option, which is quite possible since i'm
> still somewhat new to bind, it should have work. From my reading i got the
> impression transfer-source was for bind 9 and query-source was used in bind
> 8. So i also don't understand why it was in our bind 8.4.4 named.conf.
> As far as how i found it, Mr. Darcy mentioned "vanilla-configured" bind
> working fine. so i started looking specifically at what would make our conf
> different from everyone else then i started looking at those options.

	It's also listed in the migration guide that ships with
	BIND 9.  This should have beeb a strong indication to check
	to see if you need to adjust anything if you use query-source.

1.4. Notify messages and Refresh queries

The source address and port for these is now controlled by
"notify-source" and "transfer-source", respectively, rather that
query-source as in BIND 8.

> Once again, thanks everyone for you time and assistance.
> 
> Mark

	In BIND 8 the query source was used to set the source address
	and UDP port for refresh (SOA) queries.

	In BIND 9 the transfer source is used to set the source
	address and UDP port for refresh (SOA) queries.  This query
	is the start of the transfer process.  Not only does this
	provide consistancy it also provides more flexability.

> On 10/25/07, Gregory Hicks <ghicks at cadence.com> wrote:
> >
> >
> > > Date: Thu, 25 Oct 2007 13:42:43 -0500
> > > From: "mark evans" <evansmb74 at gmail.com>
> > > To: bind-users at isc.org
> > > Subject: Re: bind 9.4.1-p1
> > >
> > > This has been resolved.  Thanks for your time and assistance.
> >
> > Mark:
> >
> > For those of us with inquiring minds...  HOW did you solve it?  And
> > what was the cause?
> >
> > Could you publish the reoslution back to the list so that others with
> > the same problem can find a starting point to resolve their issue?
> >
> > Thanks!
> >
> > Regards,
> > Gregory Hicks
> >
> > >
> > >
> > > Mark
> > >
> > >
> > > On 10/24/07, mark evans <evansmb74 at gmail.com> wrote:
> > > >
> > > >  Yes I did read through the migration documentation.  There wasn't
> > > > anything in it that appears to be related to what I am dealing
> > with.  I know
> > > > they are expiring because after I restart the server I will check the
> > logs
> > > > to see if there are any issues.  It is then I see a message about one
> > or
> > > > more zones have expired.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I set logging and for notify, update, security, update-security,
> > xfer-in,
> > > > and xfer-out.  I'm not seeing anything odd in there log. The following
> > is
> > > > just a very brief excerpt of the log on the master.:
> > > >
> > > >
> > > >
> > > > 24-Oct-2007 10:00:07.760 notify: info: zone bayouwireless.com/IN:
> > sending
> > > > notifies (serial 2004030203)
> > > > 24-Oct-2007 10:30:08.356 notify: info: zone bayouwireless.com/IN:
> > sending
> > > > notifies (serial 2004030203)
> > > > 24-Oct-2007 11:00:09.486 notify: info: zone bayouwireless.com/IN:
> > sending
> > > > notifies (serial 2004030203)
> > > > 24-Oct-2007 11:30:09.418 notify: info: zone bayouwireless.com/IN:
> > sending
> > > > notifies (serial 2004030203)
> > > > 24-Oct-2007 11:49: 51.548 xfer-out: info: client
> > 209.209.192.20#52003:transfer of '
> > > > bayouwireless.com/IN': AXFR started
> > > > 24-Oct-2007 11:49:51.548 xfer-out: info: client
> > 209.209.192.20#52003:transfer of '
> > > > bayouwireless.com/IN': AXFR ended
> > > > 24-Oct-2007 12:00:09.225 notify: info: zone bayouwireless.com/IN:
> > sending
> > > > notifies (serial 2004030203)
> > > > 24-Oct-2007 12:30:09.987 notify: info: zone bayouwireless.com/IN:
> > sending
> > > > notifies (serial 2004030203)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > now the slave:
> > > >
> > > > 24-Oct-2007 10:00:13.763 notify: info: client
> > 209.209.192.10#2080:received
> > notify for zone 'bayouwireless.com
> > > > '
> > > > 24-Oct-2007 10:30:14.347 notify: info: client
> > 209.209.192.10#2014:received
> > notify for zone '
> > > > bayouwireless.com'
> > > > 24-Oct-2007 11:00:15.480 notify: info: client
> > 209.209.192.10#1433:received
> > notify for zone '
> > > > bayouwireless.com'
> > > > 24-Oct-2007 11:30:15.405 notify: info: client
> > 209.209.192.10#4082:received
> > notify for zone 'bayouwireless.com
> > > > '
> > > > 24-Oct-2007 11:50:17.956 notify: info: zone bayouwireless.com/IN:
> > sending
> > > > notifies (serial 2004030203)
> > > > 24-Oct-2007 12:00:15.183 notify: info: client
> > 209.209.192.10#2249:received
> > notify for zone '
> > > > bayouwireless.com'
> > > > 24-Oct-2007 12:30:15.981 notify: info: client
> > 209.209.192.10#1487:received
> > notify for zone 'bayouwireless.com
> > > > '
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The only thing I noticed looking though the full logs is that I never
> > see
> > > > a zone transfer actually occur without me forcing it.  So the transfer
> > you
> > > > see in the master was forced. The interesting thing is I can force the
> > > > transfer to the slave with "dig @masterserver domain axfr". if I check
> > the
> > > > zone file afterwards no changes are reflected (the same modification
> > date
> > > > and everything as before).
> > > >
> > > >
> > > >
> > > > I can get past this by forcing a zone transfer and directing the
> > output to
> > > > a file with
> > > >
> > > > "dig @masterserver domain axfr > zonefile". The zone begins working
> > fine.
> > > > It is almost like a permission problem on the slave server.  I have
> > check
> > > > the permissions and everything looks fine.
> > > >
> > > >
> > > >
> > > > Thank you for you time and assistance
> > > >
> > > >
> > > >
> > > > Mark
> > > >
> > > >
> > > >
> > > >  On 10/22/07, Mark Andrews <Mark_Andrews at isc.org> wrote:
> > > > >
> > > > >
> > > > >        You did read the migration documentation?
> > > > >
> > > > > > i upgraded our name servers from 8.4.4 to 9.4.1.  The master seems
> > to
> > > > > run
> > > > > > fine on 9.4.1.  When i run the slave 9.4.1, it seems the zones
> > aren't
> > > > > being
> > > > > > trasfered properly.  Then after a while the zones begin to expire,
> > and
> > > > > > odvious with out the zone transfer, problems start to arise.
> > > > >
> > > > >        How do you know they are expiring?
> > > > >
> > > > > > When the master is run at 9.4.1 and slave at 8.4.4 everything
> > seems to
> > > > > work
> > > > > > fine.
> > > > > > While poking around the slave i notice a set files like this:
> > > > > > db-RJ2qRqDS
> > > > > > db-SzOb6MvH
> > > > > > db-T0qBsCoV
> > > > > > db-Uu5fZE7v
> > > > > > db-WVHIEYuZ
> > > > > > db-Wwt6a4qU
> > > > > > db-YTjS9eK5
> > > > > > db-gdO2n3LH
> > > > > > db-kBvivlyx
> > > > > > db-nUkGm2hW
> > > > > > db-qH68dJ8J
> > > > > >
> > > > > > the contents of one of the files is listed below:
> > > > > >
> > > > > > ;; BIND version named 8.4.4 Thu Jun 16 15:21:48 CDT 2005
> > > > > > ; BIND version root at pop2.bayou.com
> > > > > :/usr/ports/dns/bind84/work/src/bin/named
> > > > > > ; zone 'crusecypress.com'   first transfer
> > > > > > ; from [209.209.192.10].53:53 (local [209.209.192.20 ].51898)
> > using
> > > > > AXFR at
> > > > > > Mon Oct 22 13:10:21 2007
> > > > > > ; NOT TSIG verified
> > > > > > $ORIGIN com.
> > > > > > crusecypress    7200    IN      SOA     ns1.bayou.com.
> > > > > root.ns1.bayou.com. (
> > > > > >                 2002061921 3600 900 3600000 600 )
> > > > > >         7200    IN      NS      ns1.bayou.com.
> > > > > >         7200    IN      NS       ns2.bayou.com.
> > > > > >         7200    IN      A       209.209.192.58
> > > > > >         7200    IN      MX      5 pop.bayou.com.
> > > > > > $ORIGIN crusecypress.com.
> > > > > > ftp     7200    IN      A       209.209.192.10
> > > > > > mail    7200    IN      CNAME   pop.bayou.com.
> > > > > > smtp    7200    IN      CNAME   smtp.bayou.com.
> > > > > > www     7200    IN      A       209.209.192.58 Thu Jun 16 15:21:48
> > CDT
> > > > > 2005
> > > > > > ; BIND version
> > root at pop2.bayou.com:/usr/ports/dns/bind84/work/src/bin/named
> > > > >
> > > > > > ; zone 'crusecypress.com'   first transfer
> > > > > > ; from [209.209.192.10].53:53 (local [209.209.192.20 ].51898)
> > using
> > > > > AXFR at
> > > > > > Mon Oct 22 13:10:21 2007
> > > > > > ; NOT TSIG verified
> > > > > > $ORIGIN com.
> > > > > > crusecypress    7200    IN      SOA     ns1.bayou.com.
> > > > > root.ns1.bayou.com. (
> > > > > >                 2002061921 3600 900 3600000 600 )
> > > > > >         7200    IN      NS      ns1.bayou.com.
> > > > > >         7200    IN      NS       ns2.bayou.com.
> > > > > >         7200    IN      A       209.209.192.58
> > > > > >         7200    IN      MX      5 pop.bayou.com.
> > > > > > $ORIGIN crusecypress.com.
> > > > > > ftp     7200    IN      A       209.209.192.10
> > > > > > mail    7200    IN      CNAME   pop.bayou.com.
> > > > > > smtp    7200    IN      CNAME   smtp.bayou.com.
> > > > > > www     7200    IN      A       209.209.192.58
> > > > > >
> > > > > >
> > > > > > The time and dates on the files seem to coincide when 9.4.1 was
> > > > > running on
> > > > > > both master and slave. do you guys know what these file are and
> > why it
> > > > > would
> > > > > > be creating the files with these names?  Thus far i have been
> > unable
> > > > > to find
> > > > > > any info about them on google. One thing that jumps out as a
> > issue. is
> > > > > the
> > > > > > file at the top references "BIND version named 8.4.4."  This is a
> > shot
> > > > > in
> > > > > > the dark, but Is it possible the bind 9.4.1 on the master is using
> > a
> > > > > > transfer method for 8.4.4?
> > > > >
> > > > >        No.  It's just BIND 9.4.4 not liking the BIND 8.4.4 master
> > files
> > > > >        for some reason (see the logs) and moving them out of the way
> > > > >        so it can transfer in a new copy of the zone.
> > > > >
> > > > > > Thanks
> > > > > > Mark
> > > > > --
> > > > > Mark Andrews, ISC
> > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > > PHONE: +61 2 9871 4742                 INTERNET:
> > Mark_Andrews at isc.org
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> > -------------------------------------------------------------------
> > Gregory Hicks                        | Principal Systems Engineer
> > Cadence Design Systems               | Direct:   408.576.3609
> > 555 River Oaks Pkwy M/S 6B1
> > San Jose, CA 95134
> >
> > I am perfectly capable of learning from my mistakes.  I will surely
> > learn a great deal today.
> >
> > "A democracy is a sheep and two wolves deciding on what to have for
> > lunch.  Freedom is a well armed sheep contesting the results of the
> > decision."
> >
> > "The best we can hope for concerning the people at large is that they
> > be properly armed." --Alexander Hamilton
> >
> >
> >
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list