AW: Unable to completely transfer root zone

[von Dein, Thomas]

Hello,

I finally changed the config to type hint. However, now I still have the 
problem of keeping it up to date, right? Would a monthly cronjob suffice?


Tom

-Ursprüngliche Nachricht-
Von: bind-users  Im Auftrag von Tony Finch
Gesendet: Freitag, 14. Februar 2020 13:47
An: bind-users@lists.isc.org
Betreff: Re: Unable to completely transfer root zone

Matus UHLAR - fantomas  wrote:
>
> unfortunately this happens when you decide to mirror root zone and it fails.
>
> you should use more primary servers when possible and change root zone 
> type from secondary to hint if it fails.

In this particular case, adding more primaries would not have helped because 
the firewall that caused the breakage would have broken every primary.

I have a little monitoring cron job to avoid this kind of problem.
(You'll need to adjust the paths for your setup.)

#!/usr/bin/perl

use warnings;
use strict;

my $type = '';
for (qx(named-checkconf -px)) {
$type = $1 if m{^\s*type\s+(\w+);$};
next unless $type eq "slave"
and m{^\s*file\s+"\.\./zone/(.*)";$};
my $zone = $1;
my $file = "/home/named/zone/$1";
next if -f $file and 1 > -M $file;
print "stale zone $zone\n";
}

> Note that rarely someone needs to have local copy of the root zone.

Yes.

> If you use cisco routers, ask network admins to disable any DNS "fixup"
> functionality, because that usually causes problems.

In my experience all Cisco PIX/ASA fuxup options are horribly broken and should 
be turned off.

Tony.
--
f.anthony.n.finchhttp://dotat.at/
Shannon: South or southwest 6 to gale 8, increasing severe gale 9 or storm 10 
for a time. Very rough at first in east, otherwise high or very high. Rain or 
showers. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Warren Kumari]

On Sun, Feb 16, 2020 at 6:48 AM Ed Daniel  wrote:
>
> Thank you for replying and sharing, Warren. I apologise for my
> misunderstanding of the intent of your words.

Nah, no worries - tone gets lost in email, and my response definitely
could have been read as really sarcastic.

I'd also like to thank you for calling me on it - if that had been my
intended tone it would have been inappropriate, and not alright for
this list.

w

>
> On 16/02/2020 03:08, Warren Kumari wrote:
> >
> >
> > On Fri, Feb 14, 2020 at 10:49 PM Ed Daniel  > > wrote:
> >
> > On 11/02/2020 15:28, Warren Kumari wrote:
> > > On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer
> > mailto:bortzme...@nic.fr>> wrote:
> > >>
> > >> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
> > >>  Warren Kumari mailto:war...@kumari.net>> wrote
> > >>  a message of 70 lines which said:
> > >>
> > >>> Also, can you try:
> > >>> dig +tcp . axfr @192.0.32.132 
> > >>> dig +tcp . axfr @192.0.47.132 
> > >>> dig +tcp . axfr @b.root-servers.net 
> > >>>
> > >>> (no, I'm not really sure why trying with the first 2 IPs instead of
> > >>> hostname
> > >>
> > >> Because you know that IPv6 and IPv4 may exhibit different issues.
> > >
> > > Hey, yeah, that's it! Thank you for explaining my thought processes to
> > > me -- for an encore, can you explain why I keep losing my keys? :-)
> > >
> >
> > I hope you guys are friends otherwise... -1
> >
> >
> >
> > Oh, yes - Stephane and I are definitely friends. There was no sarcasm
> > behind the comments - he was perfectly correct about my reasoning, and I
> > hadn't thought through why I was suggesting that.
> >
> > I hope no one (esp Stephane) took my comment as anything other than
> > self-deprecating - tone gets lost in mail.
> >
> > W
> >
> >
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org 
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
> > --
> > I don't think the execution is relevant when it was obviously a bad idea
> > in the first place.
> > This is like putting rabid weasels in your pants, and later expressing
> > regret at having chosen those particular rabid weasels and that pair of
> > pants.
> >---maf
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Ed Daniel]

Thank you for replying and sharing, Warren. I apologise for my
misunderstanding of the intent of your words.

On 16/02/2020 03:08, Warren Kumari wrote:
> 
> 
> On Fri, Feb 14, 2020 at 10:49 PM Ed Daniel  > wrote:
> 
> On 11/02/2020 15:28, Warren Kumari wrote:
> > On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer
> mailto:bortzme...@nic.fr>> wrote:
> >>
> >> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
> >>  Warren Kumari mailto:war...@kumari.net>> wrote
> >>  a message of 70 lines which said:
> >>
> >>> Also, can you try:
> >>> dig +tcp . axfr @192.0.32.132 
> >>> dig +tcp . axfr @192.0.47.132 
> >>> dig +tcp . axfr @b.root-servers.net 
> >>>
> >>> (no, I'm not really sure why trying with the first 2 IPs instead of
> >>> hostname
> >>
> >> Because you know that IPv6 and IPv4 may exhibit different issues.
> >
> > Hey, yeah, that's it! Thank you for explaining my thought processes to
> > me -- for an encore, can you explain why I keep losing my keys? :-)
> >
> 
> I hope you guys are friends otherwise... -1
> 
> 
> 
> Oh, yes - Stephane and I are definitely friends. There was no sarcasm
> behind the comments - he was perfectly correct about my reasoning, and I
> hadn't thought through why I was suggesting that.
> 
> I hope no one (esp Stephane) took my comment as anything other than
> self-deprecating - tone gets lost in mail.
> 
> W
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org 
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Warren Kumari]

On Fri, Feb 14, 2020 at 10:49 PM Ed Daniel  wrote:

> On 11/02/2020 15:28, Warren Kumari wrote:
> > On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer 
> wrote:
> >>
> >> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
> >>  Warren Kumari  wrote
> >>  a message of 70 lines which said:
> >>
> >>> Also, can you try:
> >>> dig +tcp . axfr @192.0.32.132
> >>> dig +tcp . axfr @192.0.47.132
> >>> dig +tcp . axfr @b.root-servers.net
> >>>
> >>> (no, I'm not really sure why trying with the first 2 IPs instead of
> >>> hostname
> >>
> >> Because you know that IPv6 and IPv4 may exhibit different issues.
> >
> > Hey, yeah, that's it! Thank you for explaining my thought processes to
> > me -- for an encore, can you explain why I keep losing my keys? :-)
> >
>
> I hope you guys are friends otherwise... -1



Oh, yes - Stephane and I are definitely friends. There was no sarcasm
behind the comments - he was perfectly correct about my reasoning, and I
hadn't thought through why I was suggesting that.

I hope no one (esp Stephane) took my comment as anything other than
self-deprecating - tone gets lost in mail.

W

>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Matus UHLAR - fantomas]

Matus UHLAR - fantomas  wrote:

If you use cisco routers, ask network admins to disable any DNS "fixup"
functionality, because that usually causes problems.


On 14.02.20 12:47, Tony Finch wrote:

In my experience all Cisco PIX/ASA fuxup options are horribly broken and
should be turned off.


I agree but FW admins won't like generalisation like that.
Currently we can say that DNS fixup caused the DNS to fail and should be
turned off.

--
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.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Tony Finch]

Matus UHLAR - fantomas  wrote:
>
> unfortunately this happens when you decide to mirror root zone and it fails.
>
> you should use more primary servers when possible and change root zone
> type from secondary to hint if it fails.

In this particular case, adding more primaries would not have helped
because the firewall that caused the breakage would have broken every
primary.

I have a little monitoring cron job to avoid this kind of problem.
(You'll need to adjust the paths for your setup.)

#!/usr/bin/perl

use warnings;
use strict;

my $type = '';
for (qx(named-checkconf -px)) {
$type = $1 if m{^\s*type\s+(\w+);$};
next unless $type eq "slave"
and m{^\s*file\s+"\.\./zone/(.*)";$};
my $zone = $1;
my $file = "/home/named/zone/$1";
next if -f $file and 1 > -M $file;
print "stale zone $zone\n";
}

> Note that rarely someone needs to have local copy of the root zone.

Yes.

> If you use cisco routers, ask network admins to disable any DNS "fixup"
> functionality, because that usually causes problems.

In my experience all Cisco PIX/ASA fuxup options are horribly broken and
should be turned off.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon: South or southwest 6 to gale 8, increasing severe gale 9 or storm 10
for a time. Very rough at first in east, otherwise high or very high. Rain or
showers. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Matus UHLAR - fantomas]

On 14.02.20 09:32, von Dein, Thomas wrote:

As reported we were unable to transfer the root zone for 1 week, then the
expire time was over and we had an outage.  


unfortunately this happens when you decide to mirror root zone and it fails.

you should use more primary servers when possible and change root zone type 
from secondary
to hint if it fails.

Note that rarely someone needs to have local copy of the root zone.


Now we've seen in the logs
many many log entries as the following on slave nameservers during that
week when our local copy were still valid but the transfer was failing:

09-Jan-2020 16:24:23.361 edns-disabled: success resolving
'some-random-hostname.some-domain.de/A' (in '.'?) after reducing the
advertised EDNS UDP packet size to 512 octets

Besides the EDNS problem: it says (in '.'?). What does this mean?


don't you have any problem with "intelligent" firewall on your side?
If you use cisco routers, ask network admins to disable any DNS "fixup"
functionality, because that usually causes problems.


The setup is like this:

Proxy dmz with local forwarding bind => internet bind => internet


why not client => bind => internet?
one bind is superflous there, isdn't it?


The error above occurred on the forwarding bind in the proxy dmz.


so the problem firewall is between "forwarding bind" and 
"internet bind"


--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Ed Daniel]

On 11/02/2020 15:28, Warren Kumari wrote:
> On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer  wrote:
>>
>> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
>>  Warren Kumari  wrote
>>  a message of 70 lines which said:
>>
>>> Also, can you try:
>>> dig +tcp . axfr @192.0.32.132
>>> dig +tcp . axfr @192.0.47.132
>>> dig +tcp . axfr @b.root-servers.net
>>>
>>> (no, I'm not really sure why trying with the first 2 IPs instead of
>>> hostname
>>
>> Because you know that IPv6 and IPv4 may exhibit different issues.
> 
> Hey, yeah, that's it! Thank you for explaining my thought processes to
> me -- for an encore, can you explain why I keep losing my keys? :-)
> 

I hope you guys are friends otherwise... -1

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

AW: Unable to completely transfer root zone

[von Dein, Thomas]

I've got one follow-up question:

As reported we were unable to transfer the root zone for 1 week, then the 
expire time was over and we had an outage. Now we've seen in the logs many many 
log entries as the following on slave nameservers during that week when our 
local copy were still valid but the transfer was failing:

09-Jan-2020 16:24:23.361 edns-disabled: success resolving 
'some-random-hostname.some-domain.de/A' (in '.'?) after reducing the advertised 
EDNS UDP packet size to 512 octets

Besides the EDNS problem: it says (in '.'?). What does this mean?

The setup is like this:

Proxy dmz with local forwarding bind => internet bind => internet

The error above occurred on the forwarding bind in the proxy dmz.



best regards,
Tom

-Ursprüngliche Nachricht-
Von: von Dein, Thomas 
Gesendet: Dienstag, 11. Februar 2020 14:45
An: 'Tony Finch' ; Warren Kumari 
Cc: bind-users@lists.isc.org
Betreff: AW: Unable to completely transfer root zone

Hi,

> So maybe try setting `request-ixfr no;` and see if that improves matters.

Nope, didn't change anything. Also, I was wrong when I stated that dig works, 
it does not. It transfers only a part of the zone as well.

However, in the meantime we found, that some component drops packets. I 
implemented my own "root nameserver" and lots of packets sent out from it are 
not arriving here.

So, not bind9's fault.

Thanks a lot for your help anyway people!



best,
Tom
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Warren Kumari]

On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer  wrote:
>
> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
>  Warren Kumari  wrote
>  a message of 70 lines which said:
>
> > Also, can you try:
> > dig +tcp . axfr @192.0.32.132
> > dig +tcp . axfr @192.0.47.132
> > dig +tcp . axfr @b.root-servers.net
> >
> > (no, I'm not really sure why trying with the first 2 IPs instead of
> > hostname
>
> Because you know that IPv6 and IPv4 may exhibit different issues.

Hey, yeah, that's it! Thank you for explaining my thought processes to
me -- for an encore, can you explain why I keep losing my keys? :-)

Thanks Stephane,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

AW: Unable to completely transfer root zone

[von Dein, Thomas]

Hi,

> So maybe try setting `request-ixfr no;` and see if that improves matters.

Nope, didn't change anything. Also, I was wrong when I stated that dig works, 
it does not. It transfers only a part of the zone as well.

However, in the meantime we found, that some component drops packets. I 
implemented my own "root nameserver" and lots of packets sent out from it are 
not arriving here.

So, not bind9's fault.

Thanks a lot for your help anyway people!



best,
Tom
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Tony Finch]

Warren Kumari  wrote:
> von Dein, Thomas  wrote:
> >
> > Does anyone have an idea, what's wrong here and how I could possibly fix 
> > this?
>
> This sounds very much like a path MTU issue -- it starts the transfer,
> gets part of the way and then a big packet doesn't make it through...

I wondered about that, but a pMTU problem usually turns up right at the
start of bulk data transmission, and on the receiver side I would expect
to get approximately nothing rather than approximately 180 KB.

There are different zone transfer implementations in `named` and `dig` so
it's conceivable that they do something different enough to provoke a RST.
But I can't think of anything plausible that might cause a RST... could it
be IXFR vs AXFR? the logs didn't mention the flavour of transfer. Ah, but
they did say:

transfer of './IN' from 192.0.47.132#53: resetting

which can happen when an IXFR fails and `named` tries to fall back to
AXFR. (The relative priorities of the log messages in this area could be
improved, because the LOG_DEBUG(3) "got %s, retrying with AXFR" is much
more informative than the LOG_INFO "resetting"...)

So maybe try setting `request-ixfr no;` and see if that improves matters.

(IXFR does not provide many advantages for the root zone because most of
the update traffic is bulk re-signing of the zone for which IXFR is very
inefficient.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire, South Utsire: Westerly veering northwesterly 6 to gale
8, occasionally severe gale 9 at first except in North Utsire. Very rough or
high. Wintry showers, thundery for a time. Moderate, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Stephane Bortzmeyer]

On Mon, Feb 10, 2020 at 02:32:55PM -0500,
 Warren Kumari  wrote 
 a message of 70 lines which said:

> Also, can you try:
> dig +tcp . axfr @192.0.32.132
> dig +tcp . axfr @192.0.47.132
> dig +tcp . axfr @b.root-servers.net
> 
> (no, I'm not really sure why trying with the first 2 IPs instead of
> hostname

Because you know that IPv6 and IPv4 may exhibit different issues.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

AW: Unable to completely transfer root zone

[von Dein, Thomas]

Hi Warren,

> This sounds very much like a path MTU issue -- it starts the transfer,
> gets part of the way and then a big packet doesn't make it through...
> Are you doing the test dig from the same machine? And if so, from the same IP?

Yes, I test from the same system using the same source address.

> Also, can you try:
> dig +tcp . axfr @192.0.32.132
> dig +tcp . axfr @192.0.47.132
> dig +tcp . axfr @b.root-servers.net

This works, I get the whole root zone that way, no problems whatsoever.

Also, the nameserver today stopped responding to any queries because of this, I 
had to install a master copy of the root zone manually to get it working again.

@alcol: the zone file is writable for the bind user, the setup hasn't changed 
for a couple of years more or less. The zone transfer worked until 2020/02/04 
as expected.



Tom


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[alcol alcol]

Hi usually it is a common problem. If u'r succesful via u'r root access, it 
mean is not a network or BIND related but FULL PATH and File Permission issue.

Daemons does not run with root privilege for priviledge escalation and 
specially bind and others are jailed.

Check if all paths are not relative (all places) and FILEs permission (not 
forgetting directory permission ( R X W )

as last some security program could intercept it as a malicious action and lock 
it.

Some checks on the way but is the common scenario when it is succesful via u'r 
root access and not via daemon



Alberto




From: bind-users  on behalf of von Dein, 
Thomas 
Sent: Monday, February 10, 2020 6:53 PM
To: bind-users@lists.isc.org 
Subject: Unable to completely transfer root zone

Hi everyone,

we are unable to complete root zone transfer from our nameservers. This is the 
error we're getting:

Feb 10 18:33:32 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
connected using 192.168.1.1#11281
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
resetting
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
connected using 192.168.1.1#46875
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
failed while receiving responses: connection reset
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
Transfer status: connection reset
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
Transfer completed: 11 messages, 3058 records, 179403 bytes, 0.410 secs (437568 
bytes/sec)

I can, however do it manually using "dig +tcp . axfr @lax.xfr.dns.icann.org".

The relevant part of the config is:

zone "." {
type slave;
file "zone/slave/root.slave";
masters {
192.0.32.132;   // lax.xfr.dns.icann.org.
192.0.47.132;   // iad.xfr.dns.icann.org.
};
notify no;
};

Does anyone have an idea, what's wrong here and how I could possibly fix this?


Thanks in advance,
Tom
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unable to completely transfer root zone

[Warren Kumari]

On Mon, Feb 10, 2020 at 12:53 PM von Dein, Thomas
 wrote:
>
> Hi everyone,
>
> we are unable to complete root zone transfer from our nameservers. This is 
> the error we're getting:
>
> Feb 10 18:33:32 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> connected using 192.168.1.1#11281
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> resetting
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> connected using 192.168.1.1#46875
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> failed while receiving responses: connection reset
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> Transfer status: connection reset
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> Transfer completed: 11 messages, 3058 records, 179403 bytes, 0.410 secs 
> (437568 bytes/sec)
>
> I can, however do it manually using "dig +tcp . axfr @lax.xfr.dns.icann.org".
>
> The relevant part of the config is:
>
> zone "." {
> type slave;
> file "zone/slave/root.slave";
> masters {
> 192.0.32.132;   // lax.xfr.dns.icann.org.
> 192.0.47.132;   // iad.xfr.dns.icann.org.
> };
> notify no;
> };
>
> Does anyone have an idea, what's wrong here and how I could possibly fix this?

This sounds very much like a path MTU issue -- it starts the transfer,
gets part of the way and then a big packet doesn't make it through...
Are you doing the test dig from the same machine? And if so, from the same IP?
Also, can you try:
dig +tcp . axfr @192.0.32.132
dig +tcp . axfr @192.0.47.132
dig +tcp . axfr @b.root-servers.net

(no, I'm not really sure why trying with the first 2 IPs instead of
hostname, but, hey, 'tis easy to test :-))

W


>
>
> Thanks in advance,
> Tom
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Unable to completely transfer root zone

[von Dein, Thomas]

Hi everyone,

we are unable to complete root zone transfer from our nameservers. This is the 
error we're getting:

Feb 10 18:33:32 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
connected using 192.168.1.1#11281
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
resetting
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
connected using 192.168.1.1#46875
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
failed while receiving responses: connection reset
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
Transfer status: connection reset
Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
Transfer completed: 11 messages, 3058 records, 179403 bytes, 0.410 secs (437568 
bytes/sec)

I can, however do it manually using "dig +tcp . axfr @lax.xfr.dns.icann.org".

The relevant part of the config is:

zone "." {
type slave;
file "zone/slave/root.slave";
masters {
192.0.32.132;   // lax.xfr.dns.icann.org.
192.0.47.132;   // iad.xfr.dns.icann.org.
};
notify no;
};

Does anyone have an idea, what's wrong here and how I could possibly fix this?


Thanks in advance,
Tom
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users