; Transfer failed. on dig axfr with bind9

[Clemens Bergmann]

hi,
I have a problem getting AXFR work with bind9.
because of the fact that i have 8 zone file i don't attach everyting here. I putted my config file on a webserver so you can view it.
The URI is http://angel.homelinux.org/bind/

I need AXFR but when I do a `dig home.loc AXFR` i get:

; <<>> DiG 9.2.4rc5 <<>> home.loc AXFR
;; global options: printcmd
; Transfer failed.

same from the server directly and from a pc in 192.168.0.1/24;
i also tried to do with "@192.168.0.254" respectively "@127.0.0.1" but that does not chage anything.

obviously something is send back from the NS because when i start ethereal on the pc i do the request i get a package back but with "[Unreassembled Packet]" (I don't know what that means).
Here is the tcpdump -w output for that package so you can open it up in ethereal an have a look (package 8):
http://angel.homelinux.org/dns

In hope of quick response
Clemens

p.s.
sorry for my bad english i am not a native english speaker (german)

- --
Besuchen sie uns doch im Internet:
http://www.schuhklassert.de
Visit us in the Internet:
http://www.schuhklasssert.de

pgp key:
0xCB9C7C6B

[p***@icke-reklam.ipsec.nu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
I have a problem getting AXFR work with bind9.
because of the fact that i have 8 zone file i don't attach everyting he=

re. I putted my config file on a webserver so you can view it.

The URI is http://angel.homelinux.org/bind/
; <<>> DiG 9.2.4rc5 <<>> home.loc AXFR
;; global options: printcmd
; Transfer failed.
same from the server directly and from a pc in 192.168.0.1/24;

that does not chage anything.

obviously something is send back from the NS because when i start ether=

eal on the pc i do the request i get a package back but with "[Unreassemb=
led Packet]" (I don't know what that means).

Here is the tcpdump -w output for that package so you can open it up in=
http://angel.homelinux.org/dns
In hope of quick response
Clemens
p.s.
sorry for my bad english i am not a native english speaker (german)

I cannot see the problem, but i see some other problems :

1/
your external view misses hint zone=20

2/ you use forwarders. In a few special cases is this needed but in most =
(all?)
cases it will only complicate things and get worse performance. Get rid o=
f them !

3/
slave for "2nd-angel.de" is 212.227.123.31 ( according to delegation)
You allow 212.227.123.29 Is this intentional ?

4/
in spite of your good idea to have config+files avaliable "on demand" i g=
et :
You don't have permission to access /bind/zones/2nd-angel.de.zone on this=
server.
(this might not mean that there is a fault in the file only that i cannot=
verify it)


(and your english is fully understandable, this is a technical discussion=
group
not an english grammar contest !)







--=20
Peter H=E5kanson =20
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out=
,
remove "icke-reklam" if you feel for mailing me. Thanx.

[Clemens Bergmann]

hi,
first of all thanks for the fast reply.

<snip>

Post by p***@icke-reklam.ipsec.nu
1/
your external view misses hint zone=20

k fixed

Post by p***@icke-reklam.ipsec.nu
2/ you use forwarders. In a few special cases is this needed but in most =
(all?)
cases it will only complicate things and get worse performance. Get rid o=
f them !

deleted

Post by p***@icke-reklam.ipsec.nu
3/
slave for "2nd-angel.de" is 212.227.123.31 ( according to delegation)
You allow 212.227.123.29 Is this intentional ?

yes, this is the slave on my providers side for which i need AXFR.

Post by p***@icke-reklam.ipsec.nu
4/
in spite of your good idea to have config+files avaliable "on demand" i g=
You don't have permission to access /bind/zones/2nd-angel.de.zone on this=
server.
(this might not mean that there is a fault in the file only that i cannot=
verify it)

sorry about that I forgot to change permissions to 644 on the server. Should work now.
in the config dir the perms are as follows:

- -rw-r--r-- 1 bind bind 95 2004-10-17 20:09 dnskeys.conf
- -rw-r--r-- 1 bind bind 2,3K 2004-10-18 21:40 named.conf
- -rw-r--r-- 1 root bind 2,5K 2004-10-18 11:09 root.hint
drwxr-xr-x 2 bind bind 4,0K 2004-10-18 21:01 zones/

./zones:
- -rw------- 1 bind bind 590 2004-10-18 10:56 1.0.0.0.2.c.1.8.0.c.5.0.1.0.0.2.ip6.arpa
- -rw------- 1 bind bind 415 2004-10-18 10:57 127.0.0.zone
- -rw------- 1 bind bind 527 2004-10-18 19:07 192.168.0.zone
- -rw------- 1 bind bind 313 2004-10-18 10:57 192.168.1.zone
- -rw------- 1 bind bind 456 2004-10-18 10:58 2nd-angel.de.zone
- -rw------- 1 bind bind 1,5K 2004-10-18 21:01 home.loc.zone
- -rw------- 1 bind bind 603 2004-10-18 16:56 ipv6.home.loc.zone
- -rw------- 1 bind bind 165 2004-10-18 10:58 localhost.zone

Post by p***@icke-reklam.ipsec.nu
(and your english is fully understandable, this is a technical discussion=
group
not an english grammar contest !)

thanks

That were some usefull tips but they did not fix my problem. You don't have any other suggestions?

Clemens

- --
Besuchen sie uns doch im Internet:
http://www.schuhklassert.de
Visit us in the Internet:
http://www.schuhklasssert.de

pgp key:
0xCB9C7C6B

[p***@icke-reklam.ipsec.nu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
first of all thanks for the fast reply.
<snip>

Post by p***@icke-reklam.ipsec.nu
1/
your external view misses hint zone=20

k fixed

Post by p***@icke-reklam.ipsec.nu
2/ you use forwarders. In a few special cases is this needed but in most =
(all?)
cases it will only complicate things and get worse performance. Get rid o=
f them !

deleted

Post by p***@icke-reklam.ipsec.nu
3/
slave for "2nd-angel.de" is 212.227.123.31 ( according to delegation)
You allow 212.227.123.29 Is this intentional ?

yes, this is the slave on my providers side for which i need AXFR.

Post by p***@icke-reklam.ipsec.nu
4/
in spite of your good idea to have config+files avaliable "on demand" i g=
You don't have permission to access /bind/zones/2nd-angel.de.zone on this=
server.
(this might not mean that there is a fault in the file only that i cannot=
verify it)

sorry about that I forgot to change permissions to 644 on the server. Should work now.
- -rw-r--r-- 1 bind bind 95 2004-10-17 20:09 dnskeys.conf
- -rw-r--r-- 1 bind bind 2,3K 2004-10-18 21:40 named.conf
- -rw-r--r-- 1 root bind 2,5K 2004-10-18 11:09 root.hint
drwxr-xr-x 2 bind bind 4,0K 2004-10-18 21:01 zones/
- -rw------- 1 bind bind 590 2004-10-18 10:56 1.0.0.0.2.c.1.8.0.c.5.0.1.0.0.2.ip6.arpa
- -rw------- 1 bind bind 415 2004-10-18 10:57 127.0.0.zone
- -rw------- 1 bind bind 527 2004-10-18 19:07 192.168.0.zone
- -rw------- 1 bind bind 313 2004-10-18 10:57 192.168.1.zone
- -rw------- 1 bind bind 456 2004-10-18 10:58 2nd-angel.de.zone
- -rw------- 1 bind bind 1,5K 2004-10-18 21:01 home.loc.zone
- -rw------- 1 bind bind 603 2004-10-18 16:56 ipv6.home.loc.zone
- -rw------- 1 bind bind 165 2004-10-18 10:58 localhost.zone

Post by p***@icke-reklam.ipsec.nu
(and your english is fully understandable, this is a technical discussion=
group
not an english grammar contest !)

thanks
That were some usefull tips but they did not fix my problem. You don't have any other suggestions?
Clemens

Well, lift the restriction of "allow-transfer" and tell us the ip
of master then we could test. As for now the ISP slave seems to
work, i see no reason it should not work for you.

- --
http://www.schuhklassert.de
http://www.schuhklasssert.de
0xCB9C7C6B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBdB+D/9rd+8ucfGsRAm7wAKClwckLTSKaOst/UPpdlPYCCn9RdACg7ZS/
w7cbkAeoZxeeNwMOiVj43kA=
=4gnv
-----END PGP SIGNATURE-----

[David Botham]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[clip...]
It is a good idea to always execute an axfr with dig as follows:

dig foo.com axfr @<ip of ns>


One reason the transfer would fail is if the name server has not loaded
the zone. What do the logs say when you reload your name server? Are
there any erros regarding this zone?

Also, because you are using views, the IP address of the dig(ing) system
is used to determine which view will be searched when looking for the
zone. Therefore, if your dig system is in the external view and the
external view does not have the zone you are looking for, your transfer
will also fail.

hth,

Dave...

[clip...]

[Clemens Bergmann]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[clip...]

=20

=20

=20
=20
=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
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-----

[p***@icke-reklam.ipsec.nu]

Post by Clemens Bergmann
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[clip...]

=20

=20

=20
=20
=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
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
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.

The *IS* another nameserver running. Trust me :-)

Identify it, kill it, edit the startupscripts to start the
correct nameserver. The repeat the above tests.

[David Botham]

Post by Clemens Bergmann
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[clip...]

Post by David Botham
=20

=20

=20
=20
=20
=20
One reason the transfer would fail is if the name server has not

loaded=20

Post by Clemens Bergmann

Post by David Botham
the zone. What do the logs say when you reload your name server?

Are=20

Post by Clemens Bergmann

Post by David Botham
there any erros regarding this zone?

I saw nothing
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=

Post by Clemens Bergmann
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.=

Post by Clemens Bergmann
1#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 eth0,

192.16=

Post by Clemens Bergmann
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=

Post by Clemens Bergmann
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=

Post by Clemens Bergmann
=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=

Post by Clemens Bergmann
t in time.

Well, there is your problem. Some other instance of something (most
likely a name server) is running on this box and the intance you are
attempting to run is not able open its listeners.

If you are on linux use this to find out who the culpret is:

netstat -anp

hth,


Dave...

PS: Always look in the logs first... They are the main place your server
talks to you... :)

Post by Clemens Bergmann
Oct 18 22:49:57 zion named[25481]: command channel listening on

127.0.0.1#9=

Post by Clemens Bergmann
53
Oct 18 22:49:57 zion named[25481]: zone 0.0.127.in-addr.arpa/IN: loaded

ser=

Post by Clemens Bergmann
ial 2004101801

loaded s=

Post by Clemens Bergmann
erial 2004101801

loaded s=

Post by Clemens Bergmann
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=

Post by Clemens Bergmann
=2Earpa/IN: loaded serial 2004101801
Oct 18 22:49:57 zion named[25481]: zone home.loc/IN: loaded serial

20041018=

Post by Clemens Bergmann
01
Oct 18 22:49:57 zion named[25481]: zone ipv6.home.loc/IN: loaded serial

200=

Post by Clemens Bergmann
4101801
Oct 18 22:49:57 zion named[25481]: zone localhost/IN: loaded serial

2004101=

Post by Clemens Bergmann
801
Oct 18 22:49:57 zion named[25481]: zone 2nd-angel.de/IN: loaded serial

2004=

Post by Clemens Bergmann
101801
Oct 18 22:49:57 zion named[25481]: running

Post by David Botham
=20
Also, because you are using views, the IP address of the dig(ing)

system=

Post by Clemens Bergmann
=20

Post by David Botham
is used to determine which view will be searched when looking for

the=20

Post by Clemens Bergmann

Post by David Botham
zone. Therefore, if your dig system is in the external view and

the=20

Post by Clemens Bergmann

Post by David Botham
external view does not have the zone you are looking for, your

transfer=20

Post by Clemens Bergmann

Post by David Botham
will also fail.
=20

i did
from 192.168.0.1 (should be "internal" view)

Post by David Botham
hth,
=20
Dave...
=20

[clip...]
p.s. I removed all that notify and also-notify statements because they

poin=

Post by Clemens Bergmann
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-----

[Clemens Bergmann]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[clip]

Well, there is your problem. Some other instance of something (most=20
likely a name server) is running on this box and the intance you are=20
attempting to run is not able open its listeners.=20
=20
=20
netstat -anp
=20
hth,
=20
=20
Dave...
=20
PS: Always look in the logs first... They are the main place your serve=

r=20

talks to you... :)

hi,
thanks for the tip but when I do `/etc/init.d/bind9 stop`
`netstat -anp | grep :53` gives no output and all dns reqests fail (timeout=
) but if i do `/etc/init.d/bind9 start` in that state there are these "addr=
ess in use" warnings.
I can not understand that thats why I said: 'I dont unterstand that because=
there is no other named running on that point in time.'
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBdDW1/9rd+8ucfGsRAmadAKDEENdK0ODpzDX0/x99zTx3jl5ZlgCeIT0B
sgR/ig7QtckVQC2VyNIIaGE=3D
=3DscvW
=2D----END PGP SIGNATURE-----

[Clemens Bergmann]

hi,
I found the source of the problem
when I deactivate 'listen-on-v6 { any; };' it works just fine.
with listen-on-v6 { any; };:
# netstat -anp | grep :53
tcp6 0 0 :::53 :::* LISTEN 26216/named
udp 0 0 84.129.79.148:53 0.0.0.0:* 26216/named
udp 0 0 192.168.1.254:53 0.0.0.0:* 26216/named
udp 0 0 192.168.0.254:53 0.0.0.0:* 26216/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 26216/named
udp6 0 0 :::53 :::* 26216/named
without listen-on-v6 { any; }; :
# netstat -anp | grep :53
tcp 0 0 84.129.79.148:53 0.0.0.0:* LISTEN 26248/named
tcp 0 0 192.168.1.254:53 0.0.0.0:* LISTEN 26248/named
tcp 0 0 192.168.0.254:53 0.0.0.0:* LISTEN 26248/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 26248/named
udp 0 0 84.129.79.148:53 0.0.0.0:* 26248/named
udp 0 0 192.168.1.254:53 0.0.0.0:* 26248/named
udp 0 0 192.168.0.254:53 0.0.0.0:* 26248/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 26248/named

But this way the server is not accessable via IPV6.
is there a work arround or do i have to decide which one i prefer:
axfr or ipv6

Clemens

[Mark Andrews]

Post by Clemens Bergmann
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[clip...]

=20

=20

=20
=20
=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
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.

Post by Clemens Bergmann
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
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: [phone] INTERNET: ***@isc.org