Unable to completely transfer root zone

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Warren Kumari
On Mon, Feb 10, 2020 at 12:53 PM von Dein, Thomas
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Alberto Colosi
In reply to this post by von Dein, Thomas
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 <[hidden email]> on behalf of von Dein, Thomas <[hidden email]>
Sent: Monday, February 10, 2020 6:53 PM
To: [hidden email] <[hidden email]>
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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

AW: Unable to completely transfer root zone

von Dein, Thomas
In reply to this post by Warren Kumari
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Stephane Bortzmeyer
In reply to this post by Warren Kumari
On Mon, Feb 10, 2020 at 02:32:55PM -0500,
 Warren Kumari <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Tony Finch
In reply to this post by Warren Kumari
Warren Kumari <[hidden email]> wrote:
> von Dein, Thomas <[hidden email]> 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.finch  <[hidden email]>  http://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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Warren Kumari
In reply to this post by Stephane Bortzmeyer
On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer <[hidden email]> wrote:

>
> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
>  Warren Kumari <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

AW: Unable to completely transfer root zone

von Dein, Thomas
In reply to this post by Tony Finch
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' <[hidden email]>; Warren Kumari <[hidden email]>
Cc: [hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Ed Daniel
In reply to this post by Warren Kumari
On 11/02/2020 15:28, Warren Kumari wrote:

> On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer <[hidden email]> wrote:
>>
>> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
>>  Warren Kumari <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Matus UHLAR - fantomas
In reply to this post by von Dein, Thomas
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, [hidden email] ; 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Tony Finch
Matus UHLAR - fantomas <[hidden email]> 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.finch  <[hidden email]>  http://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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Matus UHLAR - fantomas
>Matus UHLAR - fantomas <[hidden email]> 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, [hidden email] ; 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Warren Kumari
In reply to this post by Ed Daniel


On Fri, Feb 14, 2020 at 10:49 PM Ed Daniel <[hidden email]> wrote:
On 11/02/2020 15:28, Warren Kumari wrote:
> On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer <[hidden email]> wrote:
>>
>> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
>>  Warren Kumari <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 11/02/2020 15:28, Warren Kumari wrote:
>     > On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer
>     <[hidden email] <mailto:[hidden email]>> wrote:
>     >>
>     >> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
>     >>  Warren Kumari <[hidden email] <mailto:[hidden email]>> wrote
>     >>  a message of 70 lines which said:
>     >>
>     >>> Also, can you try:
>     >>> dig +tcp . axfr @192.0.32.132 <http://192.0.32.132>
>     >>> dig +tcp . axfr @192.0.47.132 <http://192.0.47.132>
>     >>> dig +tcp . axfr @b.root-servers.net <http://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
>     [hidden email] <mailto:[hidden email]>
>     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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Unable to completely transfer root zone

Warren Kumari
On Sun, Feb 16, 2020 at 6:48 AM Ed Daniel <[hidden email]> 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 <[hidden email]
> > <mailto:[hidden email]>> wrote:
> >
> >     On 11/02/2020 15:28, Warren Kumari wrote:
> >     > On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer
> >     <[hidden email] <mailto:[hidden email]>> wrote:
> >     >>
> >     >> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
> >     >>  Warren Kumari <[hidden email] <mailto:[hidden email]>> wrote
> >     >>  a message of 70 lines which said:
> >     >>
> >     >>> Also, can you try:
> >     >>> dig +tcp . axfr @192.0.32.132 <http://192.0.32.132>
> >     >>> dig +tcp . axfr @192.0.47.132 <http://192.0.47.132>
> >     >>> dig +tcp . axfr @b.root-servers.net <http://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
> >     [hidden email] <mailto:[hidden email]>
> >     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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

AW: Unable to completely transfer root zone

von Dein, Thomas
In reply to this post by Tony Finch
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 <[hidden email]> Im Auftrag von Tony Finch
Gesendet: Freitag, 14. Februar 2020 13:47
An: [hidden email]
Betreff: Re: Unable to completely transfer root zone

Matus UHLAR - fantomas <[hidden email]> 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.finch  <[hidden email]>  http://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
[hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users