Periodic SERVFAIL for TLD .BY

Sat Apr 2 18:30:49 UTC 2022

I have read every post and am very grateful to everyone who took part in
the discussion.

It's good when the server is configured correctly, but here you have to use
crutches for the whole .BY zone. This has never happened in my 20 years of
experience.

сб, 2 апр. 2022 г. в 21:06, Ondřej Surý <ondrej at isc.org>:

> Read the thread, this has been already answered on the list.
>
> Ondřej
> --
> Ondřej Surý — ISC (He/Him)
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> On 2. 4. 2022, at 19:48, Dzmitry Shykuts <dshykuts at gmail.com> wrote:
>
> 
> I have some questions about this situation.
>
> What causes this "address fetching loop"?
> Maybe it's a bug/future in the BIND software?
> Misconfigured .BY zone and its servers?
> Problem with root servers or TLD?
> Why does my server have this problem, but other servers don't?
>
>
> пт, 1 апр. 2022 г. в 23:41, Mark Andrews <marka at isc.org>:
>
>> Add a static-stub zone for .by which has the addresses of the nameservers
>> for .by configured. This will break the stupid address fetching loop.
>>
>> The real fix is for .by to use nameservers that are directly in .by or
>> ones thot don’t require a loop to get there addresses.
>>
>> --
>> Mark Andrews
>>
>> On 2 Apr 2022, at 07:10, Dzmitry Shykuts <dshykuts at gmail.com> wrote:
>>
>> 
>> Can anyone suggest something? Can someone tell me which server timeout? I
>> would be very happy for any help!
>>
>> вт, 29 мар. 2022 г. в 17:02, Dzmitry Shykuts <dshykuts at gmail.com>:
>>
>>> Hello! Can anybody help me with periodic and critical for me SERVFAIL?
>>> Cannot determine the source of the problem.
>>>
>>> I have Debian 11.3 and BIND9 9.16.27 on it. There was no such problem
>>> earlier.
>>>
>>> I do request:
>>>
>>>  <<>> DiG 9.16.27-Debian <<>> 103.by +trace
>>> ;; global options: +cmd
>>> . 518377 IN NS e.root-servers.net.
>>> . 518377 IN NS a.root-servers.net.
>>> . 518377 IN NS h.root-servers.net.
>>> . 518377 IN NS k.root-servers.net.
>>> . 518377 IN NS b.root-servers.net.
>>> . 518377 IN NS i.root-servers.net.
>>> . 518377 IN NS j.root-servers.net.
>>> . 518377 IN NS d.root-servers.net.
>>> . 518377 IN NS c.root-servers.net.
>>> . 518377 IN NS m.root-servers.net.
>>> . 518377 IN NS f.root-servers.net.
>>> . 518377 IN NS g.root-servers.net.
>>> . 518377 IN NS l.root-servers.net.
>>> . 518377 IN RRSIG NS 8 0 518400 20220411050000 20220329040000 9799 .
>>> keszTJZg3TCzY3s4UyinKYe7VwZGGf/8kHoWzJ2Ab3n4ctBt8gtleqC0
>>> UZqIIjc9Ez9srWGGeNn2gRUtB65QvL99oX5gD5VI6h1SY81OC0HcBx2c
>>> 80SZJ0s9qpNmkDDcp4EUNlgoheDkBAtB3MsIRIVA6T746gBthcVKLHxC
>>> rpOy7ELdgDtHwtq8jL5QIFae6QlIGuO95nflzk31VoL/yhCxvpzIXEfq
>>> QJlJQf21YJtAtYnY7vJJwuDVT20y/cj5W7PNxSkNLMoukqUXOeH/w2yB
>>> 0yNkwbKLBZUkyrE5tQmlq5AnScofbT7ffOYB9o9ug39DgCTcqSeNZDYX 0Gekmg==
>>> ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 3 ms
>>>
>>> by. 172800 IN NS dns5.tld.becloudby.com.
>>> by. 172800 IN NS dns2.tld.becloudby.com.
>>> by. 172800 IN NS dns3.tld.becloudby.com.
>>> by. 172800 IN NS dns4.tld.becloudby.com.
>>> by. 172800 IN NS dns1.tld.becloudby.com.
>>> by. 86400 IN DS 495 13 2
>>> 2D14284F8E47B53F839BD8068D438680B4B6C7A645769C9D89B47DF0 C5359B7B
>>> by. 86400 IN RRSIG DS 8 1 86400 20220411050000 20220329040000 9799 .
>>> IAk+oEOmuQVbb8RyxB9ML/GOwnLIaQdi0XMD8Y7san2AIx2lXeEZp3AV
>>> fNgYQfTnVrGyi3ylXNkVmQXnqDdrPK8iJu6mKvmaI40sQwv8xDyx5Fnz
>>> VaNHcY4+J3fQwSp+TrFxQuAlW3g3CFaUVNLk20V/TQUycVA75c+3TrW4
>>> IQJ1aua0lDsG1JS7BigHryUH9Vy8nSyuikYOIiML0BTTTqFQN7yk4AiE
>>> 3gbYMuCsMHQKfAIXpswc/i1eGEW7yi5USnQqza4P2YEDrUhSUps5N2u5
>>> /UwdS1BsmW17WZRbfDudeL4y471jwKhYgCCycGI1whtToDA452nvDJL2 it6mlg==
>>> couldn't get address for 'dns5.tld.becloudby.com': failure
>>> couldn't get address for 'dns2.tld.becloudby.com': failure
>>> couldn't get address for 'dns3.tld.becloudby.com': failure
>>> couldn't get address for 'dns4.tld.becloudby.com': failure
>>> couldn't get address for 'dns1.tld.becloudby.com': failure
>>> dig: couldn't get address for 'dns5.tld.becloudby.com': no more
>>>
>>> Request SERVFAILed. When I do "rndc flush" several times, the problem
>>> has gone for a while. After some time I get SERVFAIL again. Now I'm
>>> forwarding the zone to Google DNS and there is no such problem.
>>>
>>> There is a some debug log from BIND of the problem:
>>>
>>> --
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>> from this list
>>
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220402/bbc1c44d/attachment.htm>