Configurația mea:
/etc/ns-shared-resolv.conf este scris în mod regulat cu serverul de nume x.x.x.x, actualizat dintr-un script/etc/netns/ag2/resolv.conf este o legătură simbolică către cele de mai sus (împreună cu ag3, ag4).. pentru setările DNS centrale în netns rădăcinăo- Serviciu de lungă durată care rulează
ag2 netns (via ip netns exec ag2..., lansat de la a systemd serviciu)
Ce se întâmplă:
Totul funcționează bine... pentru un număr arbitrar de ore. După aceea, solicitările DNS eșuează. Folosind tcpdump Pot vedea cererile DNS mergând în „locul greșit” .. serverul DNS în root /etc/resolv.conf, NU cel netns.
În același timp, în timp ce asta nu funcționează, ip netns exec ag2 cat /etc/resolv.conf funcționează pentru a afișa setările corecte.
Dacă încep un nou ip netns exec ag2 bash shell, devine „corect” rezoluție.conf (legatură simbolică către /run/systemd/resolve/stub-resolv.conf, care este actualizat „în direct” cu conținutul lui ns-shared-resolv.conf)
Deci, după un timp, procesele de lungă durată primesc rădăcina rezoluție.conf?
Întrebări:
De ce se întâmplă acest lucru / cum pot diagnostica modul în care folosește serverul resolv.conf / DNS „greșit” după această perioadă de timp aleatorie?
Pot obține cumva DNS-ul implicit ubuntu systemd-resolv server care funcționează în netns-es, așa că nu trebuie să fac această nebunie?
Edit: ca această persoană! --> https://www.reddit.com/r/linuxquestions/comments/dnh8wq/comment/fo1tbty/?utm_source=share&utm_medium=web2x&context=3
