Mne na obycejnem /etc/resolv.conf vyhovuje to, ze to neni zadna sluzba. Tedy to nemuze "spadnout". Jinak moc dalsich vyhod nema, zejmena proto, ze ma natvrdo limit 3 nameserveru, coz je v dnesni dobe dost malo - obycejny dualstack s dvema rekuzrory = 4 IP ...
Ta cache u toho systemd-resolved (a podobne dnsmasq etc) je sice fajn, ale zase je to otrava, kdyz clovek z centralnich rekurzoru vymaze nejakou fqdn, aby doslo k zmene ip vzhldem k ttl a ted by to mel mazat jeste na cele farme serveru...
Stub resolver v glibc funguje tak, ze sa spyta prveho resolvera v /etc/resolv.conf, a ked dostane timeout, preskoci na druhy, ak aj ten je dole, preskoci na treti a potom naspat na prvy. Je pritom uplne fuk, ci su ipv4 alebo 6.
Aka je sanca, ze vsetky tri resolvery budu dole? Cim by to zachranil stvrty?
Spatne pochopeno. Meli jsme tu treba takovou situaci...
Jsou 4 resolvery, kazdy ma ipv4/ipv6, celkem tedy 8. V /etc/resolv.conf s omezenim na 3 adresy je teda napr.:
ipv6 resolver1
ipv6 resolver2
ipv4 resolver3
No a sikovny docker nemel nahozenou ipv6 sit, takze fungoval jen proti ipv4 resolver3. Redundance byla najednou fuc. A protoze resolver3 byl za firewalem, ktery zahazoval nahodne pakety, zlobilo to...
Nebo si ted vezmu nove fortigate. Je mozne uvest 2x ipv4 a 2x ipv6 do globalniho dns. Ja bych ale chtel treba 4x ipv6 ...
17. 6. 2025, 13:01 editováno autorem komentáře