Ubuntu 24.04 – brak rozwiązywania nazw DNS przez systemd-resolved na 127.0.0.53/54

_jta_ napisał:

@ElektrodaBot - w Ubuntu 24.04 przestały działać nazwy DNS; system używa jakiegoś własnego serwera DNS "/usr/lib/systemd/systemd-resolved", który ma otwarte porty 53 (DNS) na adresach 127.0.0.53 i 127...

Bezpośrednia odpowiedź

Najczęstsze powody, dla których w Ubuntu 24.04 „nagle” przestaje działać DNS przy aktywnym systemd-resolved (stub 127.0.0.53, u Ciebie dodatkowo 127.0.0.54), to:
- uszkodzony lub nieprawidłowy symlink /etc/resolv.conf,
- brak poprawnych serwerów DNS przypisanych do interfejsów (po DHCP/VPN/netplan/NetworkManager),
- konflikt z innym lokalnym resolverem (dnsmasq, kontenery/LXD, Pi‑hole/AdGuard, libvirt),
- problemy z DNSSEC (często przez niesynchronizowany czas systemu),
- błędna konfiguracja samego resolved (np. włączone dodatkowe nasłuchiwanie na 127.0.0.54 przez DNSStubListenerExtra),
- firewall/iptables blokujący ruch wychodzący na 53/udp lub 53/tcp.

Szybka naprawa w wielu przypadkach:
1) odtworzenie /etc/resolv.conf → stub,
2) upewnienie się, że resolved działa i ma do kogo pytać,
3) restart usług i opróżnienie cache.

Poniżej pełna, usystematyzowana diagnostyka i procedury naprawcze.

---

Diagnostyka krok po kroku (10–15 min)

1) Łączność i czas (wykluczamy problemy ogólne)
- ping 1.1.1.1 lub 8.8.8.8 (jeśli brak odpowiedzi – to nie jest tylko DNS).
- timedatectl status (System clock synchronized: yes; NTP service: active). Jeśli zegar jest „rozjechany”, DNSSEC potrafi dawać SERVFAIL.

2) Czy resolved faktycznie działa i nasłuchuje
- systemctl status systemd-resolved
- sudo ss -lntup ‘sport = :53’
Powinieneś zobaczyć /usr/lib/systemd/systemd-resolved na 127.0.0.53:53 (i u Ciebie również 127.0.0.54:53). Jeśli nasłuchuje coś jeszcze na :53 (dnsmasq, pihole-FTL, coredns) – to potencjalny konflikt.

3) Sprawdzenie kluczowych plików
- ls -l /etc/resolv.conf
- cat /etc/resolv.conf
Na desktopowym Ubuntu z aktywnym stubem powinien to być symlink do /run/systemd/resolve/stub-resolv.conf i zawierać nameserver 127.0.0.53. Jeśli stub jest wyłączony (DNSStubListener=no), wtedy /etc/resolv.conf powinien wskazywać na /run/systemd/resolve/resolv.conf (lista faktycznych upstreamów). Niezgodność = brak DNS.

4) Co resolved „widzi” i z czego korzysta
- resolvectl status
Sprawdź sekcje Global oraz dla poszczególnych „Link … (ethX/wlanX/tunX)”: Current DNS Server i DNS Servers. Puste albo błędne adresy oznaczają, że resolved nie ma dokąd przekazać zapytań.

5) Testy funkcjonalne resolved
- resolvectl query elektroda.pl
- dig @127.0.0.53 elektroda.pl +tcp
Jeśli to nie działa, zajrzyj w log:
- journalctl -u systemd-resolved -b --no-pager | tail -n 200
Szukaj: „DNSSEC validation failed”, „No appropriate name servers”, „Network unreachable”.

6) NetworkManager / netplan / interfejsy
- nmcli device show | egrep -i 'IP4.DNS|IP6.DNS|DOMAINS'
- systemctl is-active NetworkManager; networkctl list
- netplan get (lub przejrzyj /etc/netplan/*.yaml) – czy jest dhcp4: true oraz/lub nameservers: { addresses: […] }.

7) Zapora/filtry
- sudo ufw status verbose
- sudo iptables -S | egrep 'DROP|REJECT'
W typowej konfiguracji ruch wychodzący na 53/udp i 53/tcp nie powinien być blokowany.

8) Dlaczego u Ciebie jest także 127.0.0.54?
To zwykle efekt ustawienia DNSStubListenerExtra=127.0.0.54 (w /etc/systemd/resolved.conf lub w plikach drop‑in /etc/systemd/resolved.conf.d/*.conf). Sprawdź finalną konfigurację:
- systemd-analyze cat-config systemd/resolved.conf
- grep -R "DNSStubListener" /etc/systemd/resolved.conf /etc/systemd/resolved.conf.d/

---

Szybkie ścieżki naprawcze (sprawdzone w praktyce)

A) Uszkodzony / niepoprawny /etc/resolv.conf
- sudo mv /etc/resolv.conf /etc/resolv.conf.bak
- Jeśli chcesz używać stub‑a (typowo na desktopie):
sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
- Jeśli stub ma być wyłączony:
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
- sudo systemctl restart systemd-resolved
- resolvectl status; dig @127.0.0.53 example.com

B) Brak upstreamów DNS (DHCP/VPN nie podał serwerów)
- Ustaw tymczasowo per‑interfejs (bez edycji plików):
sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl domain eth0 ~.
- Lub trwale (globalnie) w /etc/systemd/resolved.conf:
[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=1.0.0.1 8.8.4.4
(potem: sudo systemctl restart systemd-resolved)
- Jeśli używasz NetworkManagera i chcesz, by to on zarządzał DNS: w edycji połączenia ustaw IPv4 → „Automatic (DHCP) addresses only” + „DNS: 1.1.1.1,8.8.8.8”.

C) DNSSEC lub czas
- Jeśli w resolved.conf masz DNSSEC=yes, a zegar nie był zsynchronizowany – pojawi się SERVFAIL. Najpierw napraw NTP:
sudo systemctl restart systemd-timesyncd; timedatectl status
- Dla testu możesz na chwilę zbić do allow-downgrade lub no:
DNSSEC=allow-downgrade
i restart resolved. Po korekcie czasu przywróć preferowany poziom.

D) Konflikt z innym lokalnym resolverem (dnsmasq/Pi‑hole/AdGuard/libvirt)
- Zidentyfikuj proces nasłuchujący na :53 (ss/lsof).
- Albo przełącz ów serwer na inny adres/port (np. 127.0.0.1:5353), a w /etc/systemd/resolved.conf ustaw DNSStubListener=no i zlinkuj /etc/resolv.conf do /run/systemd/resolve/resolv.conf,
- albo zostaw systemd‑resolved jako stub i wskaż do niego aplikacjom 127.0.0.53, a zewnętrzny resolver niech działa tylko jako upstream (np. 127.0.0.1:5353 wpisany w DNS=…).

E) Dodatkowy stub 127.0.0.54 niepotrzebny / powoduje zamieszanie
- Usuń/skomenuj w konfiguracji linie DNSStubListenerExtra=127.0.0.54 (lub odpowiedni drop‑in),
- sudo systemctl restart systemd-resolved.

F) Stub wyłączony, ale /etc/resolv.conf nadal na 127.0.0.53
- Ustaw w resolved.conf: DNSStubListener=yes (lub usuń override),
albo popraw symlink na /run/systemd/resolve/resolv.conf.

G) Ostateczne obejście: bez systemd‑resolved
- sudo systemctl disable --now systemd-resolved
- sudo rm -f /etc/resolv.conf
- W NetworkManager.conf (sekcja [main]) ustaw dns=default
- sudo systemctl restart NetworkManager
NM wygeneruje klasyczny /etc/resolv.conf z upstreamami z DHCP.

Na koniec warto:
- resolvectl flush-caches
- resolvectl statistics
- dig +trace elektroda.pl (widzisz, gdzie „pęka” rozwiązywanie)

---

Zestaw poleceń diagnostycznych do wklejenia (proszę o wyniki)

- systemctl status systemd-resolved
- ls -l /etc/resolv.conf; cat /etc/resolv.conf
- resolvectl status
- sudo ss -lntup ‘sport = :53’
- journalctl -u systemd-resolved -b --no-pager | tail -n 200
- timedatectl status
- nmcli device show | egrep -i 'IP4.DNS|IP6.DNS|DOMAIN'
- netplan get (ew. zawartość /etc/netplan/*.yaml)
- dig @127.0.0.53 elektroda.pl +tcp

Na podstawie tych danych podam precyzyjne zalecenia dopasowane do Twojej konfiguracji.

---

Uwaga praktyczna

- 127.0.0.53 to domyślny lokalny „stub resolver” systemd-resolved. Obecność 127.0.0.54 zwykle wynika z konfiguracji DNSStubListenerExtra – nie jest to standard i bywa pozostałością po modyfikacjach lub integracji z innym oprogramowaniem.
- Jeżeli korzystasz z VPN (tun0/wg0), zwróć uwagę, aby domeny split‑DNS (np. ~firma.local) były przypisane do właściwego interfejsu:
sudo resolvectl domain tun0 ~firma.local
sudo resolvectl dns tun0 10.0.0.53

Gdy podasz wyniki z sekcji „Zestaw poleceń…”, wskażę dokładny scenariusz i najkrótszą ścieżkę naprawy w Twoim przypadku.

_jta_ napisał:

@ElektrodaBot - symlink /etc/resolv.conf jest prawidłowy, wskazywany plik podaje adres nameserwera na 127.0.0.53 - ten nameserwer źle działa; żeby było ciekawiej, 127.0.0.54 działa dobrze, a oba adresy obsługuje ten sam proces.

Co może być powodem, że ten proces nasłuchuje na dwóch adresach - 127.0.0.53 i 127.0.0.54?

Jest coś ciekawego w wynikach: ss -lntup "sport = :53"
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=67506,fd=16))
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=67506,fd=14))
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=67506,fd=15))
tcp LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:(("systemd-resolve",pid=67506,fd=17))

- przy tym adresie DNS, dla którego źle działa, występuje "%lo".

Bezpośrednia odpowiedź

- To, że systemd-resolved nasłuchuje równocześnie na 127.0.0.53 i 127.0.0.54, jest zachowaniem zamierzonym (od lat w systemd). 127.0.0.53 to „pełny” lokalny stub (z DNSSEC, LLMNR/mDNS itd.), a 127.0.0.54 to „proxy-only” – uproszczony stub, który głównie przekazuje zapytania do upstreamów bez lokalnego „magicznego” przetwarzania. Stąd może działać 127.0.0.54, gdy 127.0.0.53 odmawia z powodu np. walidacji DNSSEC. (man7.org)
- „%lo” przy 127.0.0.53 oznacza, że gniazdo jest jawnie związane z interfejsem loopback (lo). To także jest celowe – główny stub jest przypięty do lo, natomiast „proxy-only” na 127.0.0.54 zwykle nie jest sztywno przywiązany do urządzenia, aby mógł być wykorzystywany np. przy NAT‑owym przekierowaniu ruchu DNS. (serverfault.com)

W Twoim przypadku różnica w działaniu najczęściej wynika z: (a) problemów z DNSSEC (np. czas/NTP, uszkodzone kotwice zaufania), (b) konfliktu/filtracji na lo (reguły firewall), (c) „inteligentnych” funkcji pełnego stuba (LLMNR/mDNS, split‑DNS), których nie ma na 127.0.0.54. Najszybciej potwierdzisz to w logach systemd‑resolved i przez testy z DNSSEC.

Poniżej precyzyjna diagnostyka i naprawa.

---

Co oznaczają dwa adresy i „%lo”

- Domyślnie systemd‑resolved wystawia lokalny DNS na 53/UDP i 53/TCP równocześnie na 127.0.0.53 i 127.0.0.54. 127.0.0.53 to pełny resolver (waliduje DNSSEC, może mieszać LLMNR/mDNS), 127.0.0.54 to tryb „proxy-only” (nie waliduje DNSSEC, nie robi LLMNR/mDNS; może tylko „tunelować” DoT do upstreamu). (freedesktop.org)
- W „ss” zapis 127.0.0.53%lo oznacza socket zbindowany do interfejsu lo. To normalne – główny stub jest sztywno na lo; „proxy-only” bywa wiązany inaczej, by dało się go wystawić na zewnątrz przez NAT/route_localnet (stąd często brak „%lo” w wyświetlaniu). Potwierdzają to zarówno praktyczne obserwacje, jak i kod/commit dodający 127.0.0.54 jako „proxy-only”. (serverfault.com)

---

Diagnostyka różnicy: dlaczego 127.0.0.53 „psuje się”, a 127.0.0.54 działa

1) Szybkie testy funkcjonalne
- dig @127.0.0.53 elektroda.pl +dnssec +tcp
- dig @127.0.0.54 elektroda.pl +tcp
- resolvectl query elektroda.pl
Jeżeli 127.0.0.53 daje SERVFAIL/timeout, a 127.0.0.54 odpowiada, to podejrzenie pada na DNSSEC/EDNS/LLMNR/mDNS po stronie pełnego stuba. 127.0.0.54 nie waliduje DNSSEC i zwykle „po prostu” przekaże zapytanie. (freedesktop.org)

2) Logi i status resolved
- journalctl -u systemd-resolved -b --no-pager | egrep -i 'dnssec|fail|timeout|unreachable'
- resolvectl status (sprawdź „DNSSEC setting”, „Current DNS Server”, per‑link DNS)
- timedatectl status (czy „System clock synchronized: yes”).
Częsty scenariusz: błąd walidacji DNSSEC przy niesynchronicznym zegarze lub problem z upstreamem – pełny stub odrzuca, „proxy-only” przechodzi. (freedesktop.org)

3) Reguły zapory i lo
- sudo ufw status verbose; sudo iptables -S | egrep 'DROP|REJECT|53'
Zdarza się, że ktoś ma reguły filtrujące ruch do 127.0.0.53 na lo, podczas gdy 127.0.0.54 nie jest objęty taką regułą. W „ss” 127.0.0.53 jest jawnie %lo, więc filtracja interfejsowa może mieć wpływ. (serverfault.com)

4) Routing domen i split‑DNS
- Jeśli używasz VPN (wg0/tun0), sprawdź w „resolvectl status” domeny ~… przypięte do interfejsów. Pełny stub respektuje routing domen, co może powodować inne zachowanie niż prosty „proxy-only”. (freedesktop.org)

---

Naprawa – rekomendowane ścieżki (od najczęstszych)

A) DNSSEC powoduje SERVFAIL
- Upewnij się, że czas/NTP jest OK: sudo systemctl restart systemd-timesyncd; timedatectl status.
- Na próbę obniż poziom: w /etc/systemd/resolved.conf ustaw DNSSEC=allow-downgrade (lub no), potem sudo systemctl restart systemd-resolved. Jeśli problem znika – winny był DNSSEC/upstream. Docelowo lepiej naprawić NTP lub problem z upstreamem niż stale wyłączać walidację. (freedesktop.org)

B) Tymczasowe obejście „na już”
- Zmuszenie systemu do użycia 127.0.0.54:
sudo rm -f /etc/resolv.conf
echo "nameserver 127.0.0.54" | sudo tee /etc/resolv.conf
To potwierdzi, że „proxy-only” działa stabilnie. Pamiętaj, że to obejście – po aktualizacjach/NM może wrócić symlink do stub‑resolv.conf (127.0.0.53). (man7.org)

C) Reset do sensownych domyślnych i czyszczenie cache
- Upewnij się, że /etc/resolv.conf → /run/systemd/resolve/stub-resolv.conf (jeśli chcesz 127.0.0.53) lub świadomie wskaż 127.0.0.54 (jeśli chcesz „proxy-only”).
- resolvectl flush-caches; resolvectl statistics. (freedesktop.org)

D) Zapora / kolizje usług na 53/tcp,udp
- Sprawdź, czy nic innego nie słucha na :53 (dnsmasq/AdGuard/libvirt). systemd‑resolved i tak ma prawo do 127.0.0.53/54, ale jeżeli wymuszasz inny demon DNS, rozważ DNSStubListener=no i klasyczny /etc/resolv.conf z upstreamami. (manpages.ubuntu.com)

E) Gdy chcesz „oficjalnie” używać 127.0.0.54 jako głównego stuba
- Możesz ręcznie ustawić /etc/resolv.conf na 127.0.0.54 i tak zostawić (świadomie rezygnujesz z DNSSEC/LLMNR/mDNS po stronie lokalnego stuba). Dokumentacja systemd nazywa 127.0.0.54 „local DNS proxy”. (man7.org)

---

Dlaczego to się „nagle” psuje?

- W Ubuntu 24.04 (systemd 255/256) mechanizm dwóch stubów jest standardem. Aktualizacje pakietów/systemu lub zmiany w upstreamowych DNS (np. nietypowe odpowiedzi, problemy z DNSSEC) obnażają różnice: pełny stub (127.0.0.53) waliduje, więc odrzuca, a „proxy-only” (127.0.0.54) po prostu przekazuje. Stąd obserwacja „.54 działa, .53 nie”. (manpages.ubuntu.com)

---

Minimalny pakiet poleceń diagnostycznych (proszę o wyniki)

- resolvectl status
- journalctl -u systemd-resolved -b --no-pager | tail -n 200
- dig @127.0.0.53 elektroda.pl +dnssec +tcp; echo $?
- dig @127.0.0.54 elektroda.pl +tcp; echo $?
- timedatectl status
- sudo ufw status verbose; sudo iptables -S | egrep 'DROP|REJECT|53'

Na tej podstawie wskażę dokładny powód (DNSSEC vs filtracja/lo vs split‑DNS) i najkrótszą trwałą korektę.

---

Dodatkowe uwagi praktyczne

- Specjalne nazwy: _localdnsstub → 127.0.0.53, _localdnsproxy → 127.0.0.54, co ułatwia testy: resolvectl query _localdnsstub. (man7.org)
- „%lo” w ss/lsof to normalny objaw bindowania do urządzenia – nie jest to błąd sam w sobie. Jeżeli masz nietypowe reguły na lo, mogą one trafić tylko w 127.0.0.53 (z „%lo”), a ominąć 127.0.0.54. (serverfault.com)

Chcesz iść w kierunku „naprawić pełny stub” (zachować DNSSEC) czy wolisz „uprościć” i używać 127.0.0.54 jako domyślnego? Jeśli podasz logi/status, doprecyzuję zalecenia krok po kroku.

_jta_ napisał:

@ElektrodaBot
A) (DNSSEC powoduje SERVFAIL) - czas jest prawidłowy; DNSSEC=allow-downgrade nie pomogło.
B) (Zmuszenie systemu do użycia 127.0.0.54) - wypróbowałem (nieco inaczej - dopisując nameserver), pomaga.
C) (Reset do sensownych domyślnych i czyszczenie cache) - rozwiązywanie nazw nie działa.
D) na portach 53 TCP i UDP słucha wyłącznie /usr/lib/systemd/systemd-resolved; nie ma reguł firewall-a do portu 53/TCP, 53/UDP, ani adresów 127.0.0.53, 127.0.0.54.

Okazało się, że powodem było ustawienie MASQUERADE w "iptables" tak, że działało to na pakiety do interfejsu "lo" - jeśli chce się robić DNAT-a z MASQUERADE między interfejsami sieciowymi, to trzeba ustawiać MASQUERADE np. poleceniem "iptables -t nat -A POSTROUTING \! -o lo -j MASQUERADE", wtedy to nie zakłóca działania DNS.

Pytanie: w jaki sposób MASQUERADE na pakietach idących do interfejsu "lo" blokowało działanie DNS-a?

Bezpośrednia odpowiedź

- MASQUERADE zastosowany także dla ruchu wychodzącego przez lo spowodował, że zapytania do lokalnego stuba 127.0.0.53 „wychodziły” z nie‑localhostowego adresu źródłowego (np. z adresu interfejsu z default‑route). systemd‑resolved ma celową ochronę: stub na 127.0.0.53 przyjmuje tylko pakiety, w których źródło i cel są z puli 127.0.0.0/8; inne odrzuca komunikatem „Got packet on unexpected IP range, refusing.”. Stąd SERVFAIL/timeout przy 127.0.0.53. Wykluczenie lo w regule NAT naprawia problem. (unix.stackexchange.com)
- 127.0.0.54 to „proxy‑only” listener systemd‑resolved (bez lokalnej walidacji DNSSEC/LLMNR/mDNS), dlatego w takiej konfiguracji zwykle działa mimo szerokiego MASQUERADE. Docelowo lepiej naprawić NAT niż stale używać 127.0.0.54. (manpages.opensuse.org)

---

Szczegółowa analiza mechanizmu

1) Co dokładnie „psuje się” przy MASQUERADE na lo
- Dla ruchu lokalnego klient→127.0.0.53 pakiet trafia do łańcucha nat/POSTROUTING. Szeroka reguła MASQUERADE (bez -o albo bez wykluczenia lo) potrafi przepisać adres źródłowy na adres wybrany wg logiki wyjściowego interfejsu/gateway. Efekt: do gniazda 127.0.0.53%lo trafia zapytanie, którego source IP nie jest 127/8. Kod systemd‑resolved sprawdza oba adresy (sender i destination) i jeśli którykolwiek nie jest localhost, odmawia obsługi i zwraca SERVFAIL („Got packet on unexpected IP range, refusing.”). To zachowanie jest udokumentowane i wielokrotnie obserwowane w praktyce. (unix.stackexchange.com)

2) Dlaczego 127.0.0.54 „przechodziło”
- W nowszych wydaniach systemd resolver wystawia dwa lokale:
• 127.0.0.53 – pełny stub (walidacja DNSSEC, integracja z LLMNR/mDNS, ścisłe ograniczenie do localhost).
• 127.0.0.54 – tryb „proxy‑only” (przekazywanie zapytań możliwie niezmienionych do upstreamu; bez lokalnej walidacji DNSSEC/LLMNR/mDNS). W wielu scenariuszach działa mimo nietypowego NAT na hoście, dlatego wymuszenie 127.0.0.54 w /etc/resolv.conf maskuje błąd, ale kosztem funkcji bezpieczeństwa. (manpages.opensuse.org)

3) Skąd „%lo” przy 127.0.0.53 w ss
- Gniazdo stuba 127.0.0.53 jest świadomie zbindowane do interfejsu lo. To podkreśla, że ten listener ma być wyłącznie lokalny i jest jedną z przyczyn, dla których pakiety z nie‑localhostowym źródłem są odrzucane. (Patrz też nazwy syntetyczne: _localdnsstub → 127.0.0.53, _localdnsproxy → 127.0.0.54). (manpages.debian.org)

4) Dlaczego poprawka „! -o lo” działa zawsze
- Ograniczenie MASQUERADE do interfejsów innych niż lo („iptables -t nat -A POSTROUTING ! -o lo -j MASQUERADE”) albo wskazanie konkretnego interfejsu zewnętrznego usuwa translację ze ścieżki klient↔stub na lo, więc systemd‑resolved widzi poprawne 127/8 jako źródło i obsługuje zapytanie. To znana i zalecana praktyka przy NAT. (unix.stackexchange.com)

---

Weryfikacja i testy (dla ciekawości i przyszłych przypadków)

- Podgląd objawu:
journalctl -u systemd-resolved -b | grep -i 'unexpected'
tcpdump -ni lo 'port 53'
W problematycznej konfiguracji widać pakiety do 127.0.0.53 z source ≠ 127/8. (bugs.launchpad.net)
- A/B test:
dig @127.0.0.53 elektroda.pl +tcp (przed i po zmianie reguł NAT)
dig @127.0.0.54 elektroda.pl +tcp
- Sprawdzenie ról stubów:
resolvectl query _localdnsstub; resolvectl query _localdnsproxy. (man7.org)

---

Zalecenia operacyjne (trwałe)

- Utrzymuj NAT tylko na interfejsach zewnętrznych, albo jawnie wyklucz lo:
iptables: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
lub: iptables -t nat -A POSTROUTING ! -o lo -j MASQUERADE. (usavps.com)
- Jeśli używasz nftables (domyślny backend w Ubuntu 24.04), ekwiwalent:
table inet nat { chain postrouting { type nat hook postrouting priority 100; oifname != "lo" masquerade } }
- Pozostań przy 127.0.0.53 jako domyślnym nameserverze (pełna funkcjonalność i DNSSEC); 127.0.0.54 traktuj jako tymczasowe obejście/diagnostykę. (manpages.opensuse.org)

---

Dygresja: dlaczego to bywa „nagłe”

Aktualizacje firewalli, kontenerów lub skryptów DNAT (np. dodających uogólnione „-t nat POSTROUTING -j MASQUERADE”) potrafią niespodziewanie objąć też ruch lo. Wtedy od razu widać różnicę: 127.0.0.54 „działa”, a 127.0.0.53 zwraca SERVFAIL – dokładnie jak u Ciebie. W logach systemd‑resolved pojawia się cytowany komunikat o „unexpected IP range”. (reddit.com)

---

Podsumowanie

- Przyczyną była translacja źródła (SNAT/MASQUERADE) zastosowana do ruchu loopback, przez co lokalny stub 127.0.0.53 widział zapytania z nie‑localhostowych adresów i je odrzucał.
- Wykluczenie lo z MASQUERADE (lub zawężenie NAT do interfejsu zewnętrznego) to prawidłowa i bezpieczna poprawka.
- 127.0.0.54 działał, bo to „proxy‑only” listener bez lokalnych „udziwnień”; nie jest to jednak preferowane rozwiązanie stałe. (unix.stackexchange.com)

Jeśli będziesz chciał, mogę pomóc przełożyć Twoje reguły iptables na spójny zestaw nftables z testami „regresji” (tcpdump/journalctl), aby podobny przypadek nie wrócił przy kolejnych zmianach.