Periodic SERVFAIL for TLD .BY
Dzmitry Shykuts
dshykuts at gmail.com
Wed Mar 30 14:02:29 UTC 2022
"servfail-ttl 0" doesn't help.
вт, 29 мар. 2022 г. в 18:16, Ondřej Surý <ondrej at isc.org>:
> The .by domain is kind of bonkers…
>
> Step 1: get nameservers for 103.by:
>
> $ dig +noall +authority IN NS 103.by. @a.root-servers.net
> by. 172800 IN NS dns1.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 dns5.tld.becloudby.com.
>
> Step 2: get nameservers for becloudy.com:
>
> $ dig +noall +authority IN NS becloudby.com. @a.root-servers.net
> com. 172800 IN NS e.gtld-servers.net.
> com. 172800 IN NS b.gtld-servers.net.
> […]
>
> $ dig +noall +authority IN NS becloudby.com. @a.gtld-servers.net.
> becloudby.com. 172800 IN NS u1.hoster.by.
> becloudby.com. 172800 IN NS u2.hoster.by.
>
> Step 3: get nameservers for hoster.by
>
> $ dig +noall +authority IN NS hoster.by. @a.root-servers.net
> by. 172800 IN NS dns1.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 dns5.tld.becloudby.com.
>
> Step 4: get nameservers for becloudy.com:
>
> […]
>
> My guess is that it probably depends on the current state of the cache
> whether `named` is able to break out of the loop using the existing data
> or not.
>
> From the log, I can see that it’s hitting the SERVFAIL cache.
>
> You can disable the servfail caching with:
>
> ``servfail-ttl``
> This sets the number of seconds to cache a SERVFAIL response due to
> DNSSEC
> validation failure or other general server failure. If set to ``0``,
> SERVFAIL caching is disabled. The SERVFAIL cache is not consulted if
> a query has the CD (Checking Disabled) bit set; this allows a query
> that failed due to DNSSEC validation to be retried without waiting
> for the SERVFAIL TTL to expire.
>
> The maximum value is ``30`` seconds; any higher value is
> silently reduced. The default is ``1`` second.
>
> And see if that helps.
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ondrej at isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> > On 29. 3. 2022, at 16:02, Dzmitry Shykuts <dshykuts at gmail.com> wrote:
> >
> > 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:
> >
> > <named.txt>--
> > 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/20220330/80ae888f/attachment.htm>
More information about the bind-users
mailing list