Dotaz: BIND - timed out resolving (Rocky Linux 8)

[MMMMMMMMM]

Zdravím, neprovozujete někdo na Rocky 8 Bind s nadřazenými resolvery? Původně jsme měli Centos 7 a vše se zdálo OK, ale nyní jsme přešli na Rocky 8 a v logu sem tam vidím podivnosti:

    timed out resolving 'd24-a.sdn.cz/A/IN': ISP_NS1#53: 1 Time(s)
    timed out resolving 'd25-a.sdn.cz/A/IN': ISP_NS1#53: 1 Time(s)
    timed out resolving 'd25-a.sdn.cz/TYPE65/IN': ISP_NS1#53: 1 Time(s)
    timed out resolving 'd27-a.sdn.cz/A/IN': ISP_NS2#53: 1 Time(s)
    timed out resolving 'd2lxvusm4h22jx.cloudfront.net/A/IN': ISP_NS1#53: 1 Time(s)
    timed out resolving 'd35zo7yi6yy867.cloudfront.net/A/IN': ISP_NS1#53: 1 Time(s)
    timed out resolving 'd49-a.sdn.cz/TYPE65/IN': ISP_NS2#53: 1 Time(s)
    timed out resolving 'd50-a.sdn.cz/A/IN': ISP_NS1#53: 1 Time(s)
    timed out resolving 'd53-a.sdn.cz/A/IN': ISP_NS2#53: 1 Time(s)

Nedělá to stále, ale těch záznamů je docela dost. Dělá to i s veřejnými resolvery od CZ.NIC nebo Googlu (8.8.8.8, 8.8.4.4). Když vypnu v Bindu forward na nadřazené resolvery a Bind si překládá vše sám, v logu žádný timed out resolving není. Už mi pomalu dochází nápady. Kontroloval jsem třeba centrální firewall, ale ten to neblokuje. Ty adresy přeložit jdou, když se zrovna sám ptám. Velká záhada. Máte to někdy ve /var/log/messages taky? :)

Odpovědi

[MMMMMMMMM]

Jen doplním, že zjevně nejsem sám, kdo si toho všiml i na jiných systémech, např. Seeing lots of DNS issues on OpenWRT. U nás v Rocky 8 je Bind 9.11.36.

[X]

Deje se to zcela nahodne? Neslo by par takovych selhani odchytit? Jak moc je to DNS vytizene?

[MMMMMMMMM]

Řekl bych, že je to náhodné a bohužel v této chvíli ani nedokážu říci, zda ta hláška není nějak zavádějící, zda skutečně dojde k timeoutu nebo dojde k překladu s tím, že se v logu objeví tato hláška. Řekl bych, že primární DNS dělá tak 1000 až 1500 dotazů za minutu. Ale zkusím při chvilce odchytit nějaké pakety na sekundárním DNS, který není tak vytížený. Od uživatelů nemám reportováno, že by něco nefungovalo.

[MMMMMMMMM]

Tak zatím je to fakt divné. tcpdump (s výstupem do *.pcap, otevřeno ve Wiresharku):

https://ibb.co/J3XFm1Y

Nadřazený server ISP_NS1 neodpověděl. :-/ A to je zalogováno. Odpověď ale přišla z ISP_NS2, takže k překladu nakonec došlo. Firewall nic nezablokoval, odpověď se pak dostala ke klientovi.

[MMMMMMMMM]

Zítra zkusím stejný tcpdump spustit i na bráně/firewallu, pak je můžu porovnat.

[MMMMMMMMM]

Tak jsem to zkusil, našel jeden takový timeout, k tomu porovnal záznamy z tcpdumpu na bráně i na serveru a nenašel tam chybu. Dotaz byl odeslán, promptně zodpovězen a hned na server dorazila odpověď. Na serveru v logu se přesto objevil záznam o timeoutu. No, nechám to nyní tak, jak to je a nebudu používat nadřazené nameservery. Chtěl jsem ušetřit pár milisekund...

[alkoholik]

Rekl bych, ze milisekundy naopak usetris vlastnim resolverem.

[MMMMMMMMM]

My tu máme právě 2 resolvery pro lokální síť, co navíc využívaly resolvery ISP (ping 1-2ms), takže si myslím, že většina našich dotazů byla zodpovězena z jejich cache. Nyní při vlastním resolvování už se doptáváme do Internetu, takže se to trošku protáhne. Uživatel asi stejně nic nepozná.

[marek]

Dobry den.

Takoveto chovani by se mohlo vyskytnout, kdyz pretece tabulka spojeni firewallu.

Mozna se mezi 7 - 8 zmenilo pocitani limitu?

My proto na vsech produkcnich nameserverech connection tracking pro port 53 zakazujeme.

Ale zazili jsme dodavatele, ktery nam dodal reseni na zatezove testy s nejakym defaultnim nastavenim firewald a totalne to zkolabovalo uz okolo 20000q/s(jako ze uz to proste uz vubec neresolvovalo), kdyz se firewall vypnul, dokazali bez problemu odbavit 400000q/s

marek

[MMMMMMMMM]

Zdravím, díky za reakci. Myslím, že to asi nebude náš případ, kdy prakticky nevyužitý sekundární NS nemá skoro žádná spojení. :) Ale pro jistotu zkusím zítra port 53 vyhodit z CONNTRACKu. Btw pokud by došlo k vyčerpání spojení, bylo by to v logu, co si pamatuju. Kdysi dávno jsem provozoval časový server, kde jsem už spojení kvůli NTP vyčerpal a použil jsem nakonec NOTRACK pro další fungování při velké zátěži.