; Transfer failed. on dig axfr with bind9

[Mark Andrews]

> =2D----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> [clip...]
> >=20
> > >=20
> > > I need AXFR but when I do a `dig home.loc AXFR` i get:
> >=20
> > It is a good idea to always execute an axfr with dig as follows:
> >=20
> > dig foo.com axfr @<ip of ns>
> >=20
> >=20
> > One reason the transfer would fail is if the name server has not loaded=20
> > the zone.  What do the logs say when you reload your name server?  Are=20
> > there any erros regarding this zone?
> I saw nothing
> here is the full log from server restart:
> 
> Oct 18 22:49:57 zion named[25481]: starting BIND 9.2.4rc5 -u bind
> Oct 18 22:49:57 zion named[25481]: using 1 CPU
> Oct 18 22:49:57 zion named[25481]: loading configuration from '/etc/bind/na=
> med.conf'
> Oct 18 22:49:57 zion named[25481]: listening on IPv6 interfaces, port 53
> Oct 18 22:49:57 zion named[25481]: binding TCP socket: address in use
> Oct 18 22:49:57 zion named[25481]: listening on IPv4 interface lo, 127.0.0.=
> 1#53
	
	I hate broken IP stacks.  Turn off IPv6 or upgrade to BIND
	9.3.0 or get a OS without a broken IP stack.  I suspect
	that the IPv6 wildcard socket is preventing the explicit
	IPv4 sockets from binding.

	Also you shouldn't be using a RC after a release goes final.

> Oct 18 22:49:57 zion named[25481]: binding TCP socket: address in use
> Oct 18 22:49:57 zion named[25481]: listening on IPv4 interface eth0, 192.16=
> 8.0.254#53
> Oct 18 22:49:57 zion named[25481]: binding TCP socket: address in use
> Oct 18 22:49:57 zion named[25481]: listening on IPv4 interface ath0, 192.16=
> 8.1.254#53
> Oct 18 22:49:57 zion named[25481]: binding TCP socket: address in use
> Oct 18 22:49:57 zion named[25481]: listening on IPv4 interface ppp0, 84.129=
> =2E79.148#53
> Oct 18 22:49:57 zion named[25481]: binding TCP socket: address in use
> 
> I dont unterstand that because there is no other named running on that poin=
> t in time.
> 
> Oct 18 22:49:57 zion named[25481]: command channel listening on 127.0.0.1#9=
> 53
> Oct 18 22:49:57 zion named[25481]: zone 0.0.127.in-addr.arpa/IN: loaded ser=
> ial 2004101801
> Oct 18 22:49:57 zion named[25481]: zone 0.168.192.in-addr.arpa/IN: loaded s=
> erial 2004101801
> Oct 18 22:49:57 zion named[25481]: zone 1.168.192.in-addr.arpa/IN: loaded s=
> erial 2004101801
> Oct 18 22:49:57 zion named[25481]: zone 1.0.0.0.2.c.1.8.0.c.5.0.1.0.0.2.ip6=
> =2Earpa/IN: loaded serial 2004101801
> Oct 18 22:49:57 zion named[25481]: zone home.loc/IN: loaded serial 20041018=
> 01
> Oct 18 22:49:57 zion named[25481]: zone ipv6.home.loc/IN: loaded serial 200=
> 4101801
> Oct 18 22:49:57 zion named[25481]: zone localhost/IN: loaded serial 2004101=
> 801
> Oct 18 22:49:57 zion named[25481]: zone 2nd-angel.de/IN: loaded serial 2004=
> 101801
> Oct 18 22:49:57 zion named[25481]: running
> >=20
> > Also, because you are using views, the IP address of the dig(ing) system=
> =20
> > is used to determine which view will be searched when looking for the=20
> > zone.  Therefore, if your dig system is in the external view and the=20
> > external view does not have the zone you are looking for, your transfer=20
> > will also fail.
> >=20
> i did
> `dig home.loc axfr @192.168.0.254`
> from 192.168.0.1 (should be "internal" view)
> > hth,
> >=20
> > Dave...
> >=20
> [clip...]
> 
> p.s. I removed all that notify and also-notify statements because they poin=
> ted to the same server and I think that is useless.=20
> 1. is this correct=20
> 2. does this change anything? (it does not solve the problem)
> =2D----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQFBdC28/9rd+8ucfGsRAho7AJwJ+xOA79RalUUESA4GyJMPHv1R3wCfcd6J
> ORtwdFvJWkMHoSq/33s/62A=3D
> =3D5dhw
> =2D----END PGP SIGNATURE-----
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org