AXFR partially timed out
Beat Jucker
I have a very strange problem with AXFR. We are using a master and a
secondary DNS Server with an internal and an external view. Depending
on the source address the secondary server will get the internal or
external view for zone transfer.
Everything is working correct so far except only one specific zone file
won't get transferred. In the external view there are about 70 zones
defined. Every zone will get transferred except one and only one won't.
Therefor there can't be a problem with the firewall.
Then I scaled down the seconday DNS server to just about 2 zones and
again: this specific zone file won't get transfered even the master
said "AXFR started" and "AXFR ended" for this particular zone. On
the secondary server I'll get "giving up: timed out".
To test zone transfer by DIG I shut down the internal IP interface
so the AXFR request used the external IP interface for the zone transfer
and everything was ok (zone transfer succeeded).
I also checkd the zonefile against nonASCII chars. Everything looks
correct. I'm realy confused (by the way: we are still using BIND-0.9.5)
Do you have any idea ... ?
Best regards
-- Beat
Logfile of master DNS server:
--> Bsp-1: AXFR of 194.72.193 succeeded <--
20:42:18.301 client 62.2.231.99#40091: view external: query: 194.72.193.in-addr.arpa IN AXFR -
20:42:18.302 client 62.2.231.99#40091: view external: transfer of '194.72.193.in-addr.arpa/IN': AXFR started
20:42:18.303 client 62.2.231.99#40091: view external: transfer of '194.72.193.in-addr.arpa/IN': AXFR ended
--> Bsp-2: AXFR of glue.ch *NOT* succeeded ... ? <--
20:42:18.780 client 62.2.231.99#40092: view external: query: glue.ch IN AXFR -
20:42:18.780 client 62.2.231.99#40092: view external: transfer of 'glue.ch/IN': AXFR started
20:42:18.783 client 62.2.231.99#40092: view external: transfer of 'glue.ch/IN': AXFR ended
Logfile of secondary DNS server:
--> Bsp-1: AXFR of 194.72.193 succeeded <--
20:42:18.252 transfer of '194.72.193.in-addr.arpa/IN/external' from 193.72.194.251#53: connected using 62.2.231.99#40091
20:42:18.253 transfer of '194.72.193.in-addr.arpa/IN/external' from 193.72.194.251#53: sent request length prefix
20:42:18.253 transfer of '194.72.193.in-addr.arpa/IN/external' from 193.72.194.251#53: sent request data
20:42:18.342 transfer of '194.72.193.in-addr.arpa/IN/external' from 193.72.194.251#53: received 462 bytes
20:42:18.342 transfer of '194.72.193.in-addr.arpa/IN/external' from 193.72.194.251#53: got nonincremental response
20:42:18.348 zone 194.72.193.in-addr.arpa/IN/external: zone transfer finished: success
20:42:18.348 zone 194.72.193.in-addr.arpa/IN/external: transferred serial 2009112701
20:42:18.348 transfer of '194.72.193.in-addr.arpa/IN/external' from 193.72.194.251#53: Transfer completed: 1 messages, 16 records, 462 bytes, 0.095 secs (4863 bytes/sec)
--> Bsp-2: AXFR of glue.ch *NOT* succeeded ... ? <--
20:42:18.730 transfer of 'glue.ch/IN/external' from 193.72.194.251#53: connected using 62.2.231.99#40092
20:42:18.731 transfer of 'glue.ch/IN/external' from 193.72.194.251#53: sent request length prefix
20:42:18.731 transfer of 'glue.ch/IN/external' from 193.72.194.251#53: sent request data
21:42:18.696 transfer of 'glue.ch/IN/external' from 193.72.194.251#53: giving up: timed out
Dave Sparro
> Hello BIND users
>
> I have a very strange problem with AXFR. We are using a master and a
> secondary DNS Server with an internal and an external view. Depending
> on the source address the secondary server will get the internal or
> external view for zone transfer.
>
> Everything is working correct so far except only one specific zone file
> won't get transferred. In the external view there are about 70 zones
> defined. Every zone will get transferred except one and only one won't.
> Therefor there can't be a problem with the firewall.
>
> Then I scaled down the seconday DNS server to just about 2 zones and
> again: this specific zone file won't get transfered even the master
> said "AXFR started" and "AXFR ended" for this particular zone. On
> the secondary server I'll get "giving up: timed out".
>
> To test zone transfer by DIG I shut down the internal IP interface
> so the AXFR request used the external IP interface for the zone transfer
> and everything was ok (zone transfer succeeded).
>
> I also checkd the zonefile against nonASCII chars. Everything looks
> correct. I'm realy confused (by the way: we are still using BIND-0.9.5)
>
> Do you have any idea ... ?
>
Is the problem zone larger than the ones that are not a problem? If so
it may be a MTU problem, or even a firewall that does things differently
based on packet sizes.
--
Dave
Warren Kumari
Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.
On Oct 7, 2010, at 1:55 AM, Beat Jucker <be...@juckers.ch> wrote:
> Hello BIND users
>
> I have a very strange problem with AXFR. We are using a master and a
> secondary DNS Server with an internal and an external view. Depending
> on the source address the secondary server will get the internal or
> external view for zone transfer.
>
> Everything is working correct so far except only one specific zone file
> won't get transferred. In the external view there are about 70 zones
> defined. Every zone will get transferred except one and only one won't.
> Therefor there can't be a problem with the firewall.
>
> Then I scaled down the seconday DNS server to just about 2 zones and
> again: this specific zone file won't get transfered even the master
> said "AXFR started" and "AXFR ended" for this particular zone. On
> the secondary server I'll get "giving up: timed out".
>
> To test zone transfer by DIG I shut down the internal IP interface
> so the AXFR request used the external IP interface for the zone transfer
> and everything was ok (zone transfer succeeded).
>
> I also checkd the zonefile against nonASCII chars. Everything looks
> correct. I'm realy confused (by the way: we are still using BIND-0.9.5)
>
> Do you have any idea ... ?
Yes -- remove the firewall...
Your testing to rule out the firewall is far from comprehensive, and in almost all cases where there is a DNS problem and the words "firewall" or "load-balancer" are mentioned, they are the issue...
W
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Beat Jucker
> >secondary DNS Server with an internal and an external view. Depending
> >on the source address the secondary server will get the internal or
> >external view for zone transfer.
> >
> >Everything is working correct so far except only one specific zone file
> >won't get transferred. In the external view there are about 70 zones
> >defined. Every zone will get transferred except one and only one won't.
> >Therefor there can't be a problem with the firewall.
> >
> >Then I scaled down the seconday DNS server to just about 2 zones and
> >again: this specific zone file won't get transfered even the master
> >said "AXFR started" and "AXFR ended" for this particular zone. On
> >the secondary server I'll get "giving up: timed out".
> Is the problem zone larger than the ones that are not a problem? If so
> it may be a MTU problem, or even a firewall that does things differently
> based on packet sizes.
Indeed the trouble zone is about double the size of other zones.
Both DNS servers are Solaris boxes and comunicate by plain TCP (no VPN).
How can I check for MTU problem and how can I influence it?
When I ask for the zone by dig utility everything is ok but not
when the zone get requested by named ... head scraping ...
Thanks a lot
-- Beat
Matus UHLAR - fantomas
> > >secondary DNS Server with an internal and an external view. Depending
> > >on the source address the secondary server will get the internal or
> > >external view for zone transfer.
> > >
> > >Everything is working correct so far except only one specific zone file
> > >won't get transferred. In the external view there are about 70 zones
> > >defined. Every zone will get transferred except one and only one won't.
> > >Therefor there can't be a problem with the firewall.
> > >
> > >Then I scaled down the seconday DNS server to just about 2 zones and
> > >again: this specific zone file won't get transfered even the master
> > >said "AXFR started" and "AXFR ended" for this particular zone. On
> > >the secondary server I'll get "giving up: timed out".
>
> > Is the problem zone larger than the ones that are not a problem? If so
> > it may be a MTU problem, or even a firewall that does things differently
> > based on packet sizes.
On 11.10.10 23:11, Beat Jucker wrote:
> Indeed the trouble zone is about double the size of other zones.
> Both DNS servers are Solaris boxes and comunicate by plain TCP (no VPN).
> How can I check for MTU problem and how can I influence it?
>
> When I ask for the zone by dig utility everything is ok but not
> when the zone get requested by named ... head scraping ...
well, try in the following order:
dig +notcp
dig +tcp
dig +notcp +bufsize=1480
dig +notcp +bufsize=1500
dig +notcp +bufsize=4096
that may tell you something...
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Dave Sparro
>> Is the problem zone larger than the ones that are not a problem? If so
>> it may be a MTU problem, or even a firewall that does things differently
>> based on packet sizes.
>
> Both DNS servers are Solaris boxes and comunicate by plain TCP (no VPN).
> How can I check for MTU problem and how can I influence it?
>
man ifconfig
try setting the MTU to 1200 to see if the results are different.
--
Dave