Bind 9 to Bind 4 zone transfer problem

Mark.Andrews at nominum.com Mark.Andrews at nominum.com
Sat May 5 00:28:03 UTC 2001


	OPCODE 4 is NOTIFY, ignore the messages or better still
	upgrade.

	BIND 9's transfer format defaults to "many-anwers".  All
	BIND 4 versions that do not support "many-anwers" and some
	that do have serious security flaws and should be upgraded.
	If you can't upgrade the server in question use a server
	clause on the master to change the transfer format for this
	one server to "transfer-format one-answer;".

	Note IXFR response are OPCODE 1 (QUERY) and a only sent in
	response to a IXFR query.

	Mark

> 
> Off the top of my head, it sounds like bind9 is trying to send only the chang
> ed
> information by way of an IXFR (incremental) which didn't exist back in the
> dinosaur age that bind4 came from... In your bind9 config file, you can defin
> e
> an external nameserver and say that it needs to use only AXFR. Or, you could
> turn off incremental zone xfers for all zones until you can eliminate the old
> server (which is going to be ignoring your NOTIFY messages and therefore keep
> ing
> older out-of-sync data until its cache expires).
> 
> Nigel Lyons wrote:
> 
> > We have a Bind 9.1 Primary server running on Red Hat Linux and 3 secondary
> > servers. 2 of the secondaries are Bind 9.1 on Solaris 8 and the 3rd
> > secondary is Bind 4.9.4 (p1) running on Solaris also. Updates are running
> > fine between the primary and the 2 Bind 9 secondaries but there is a proble
> m
> > with the Bind 4 secondary.
> >
> > The BIND 4 secondary is loading sones OK from another Bind 4 Primary and
> > updating these OK. There is an entry named.boot on the BIND 4 secondary for
> > a few domains listing the Bind 9 primary as the master.
> >
> > If the zone file does not exist on the Bind 4 secondary a restart of the DN
> S
> > on the secondary causes a successful load of the zone file from the Bind 9
> > primary to the Bind 4 secondary.
> >
> > If the zone file does not exist on the Bind 4 secondary a restart of the DN
> S
> > on the primary causes a successful load of the zone file from the Bind 9
> > primary to the Bind 4 secondary.
> >
> > However if the zone file exists on the Bind 4 secondary and the serial is
> > incremented on the primary, the zone file on the secondary is not updated
> > either by a restart of the DNS on the Bind 9 primary or the Bind 4
> > secondary. In both cases we get the message on the secondary:
> >
> > "OPCODE 4 not implemented"
> >
> > Can anyone help?
> >
> > Regards,
> >
> > Nigel Lyons
> >
> > Nigel Lyons
> > nevada tele.com
> > DDI: +44 (0) 28 9095 9511
> > Fax: +44 (0) 28 9095 9401
> > Mobile: +44 (0) 7767 393143
> > eMail:nigel.lyons at nevadatele.com
> > Web: www.nevadatele.com
> >
> > nevada tele.com ltd
> > 1 Cromac Avenue, Belfast, BT7 2JA
> >
> > Tel             +44 (0 )28 9072 0400
> > Fax             +44 (0) 28 9072 0401
> > Web             www.nevadatele.com
> > Sales           0808 140 1400
> > Customer Care   0808 140 1500
> >
> > ******************************************************************
> > This email and any attachments may be confidential and
> > the subject of legal professional privilege.  Any disclosure,
> > use, storage or copying of this email without the consent
> > of the sender is strictly prohibited.
> >
> > Please notify the sender immediately if you are not the
> > intended Recipient and then delete the email from your
> > inbox and do not disclose the contents to another
> > person, use, copy or store the information in any medium.
> > ******************************************************************
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com


More information about the bind-users mailing list