Vlákno názorů k článku Evoluce DNS v Linuxu aneb od resolv.conf k systemd-resolved od czechsys - Mne na obycejnem /etc/resolv.conf vyhovuje to, ze to...
-
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 resolver3No 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
