[Risolto]24.04.1 LTS - resolv.conf che viene sovrascritto ad ogni avvio. Credo sia normale ma....

[DjDiabolik]

ma........... vi sembrerà una cosa strana ma ho provato, prima di aprire questo thread a trovare qualche soluzione con "Google" senza riuscire a trovare una vera soluzione oppure qualche thread inerente che mi aiuti a capire come configurare il tutto.

Ma veniamo ad una descrizione:
Se ho capito correttamente ora il file su /etc/resolv.conf è un collegamento ad un'altro file resolv-stub.conf se non sbaglio a quello in /run/systemd/resolve/stub-resolv.conf

Io ho provato a modificare quel file togliendo il dns che c'è in nameserver ed ho aggiunto i due di cloudflare cioè 1.1.1.1 e 1.0.0.1 salvo il file e la modifica sembra averla accettata.

Il problema sta che quando riavvio però ubuntu questo file sembra resettarsi e torna il singolo nameserver impostato su 127.0.0.53

Perchè mai questa cosa ? Come la evito sta cosa oppure come la configuro al meglio ?

*EDIT*
Il problema è che con questa cosa col 127.0.0.53 c'è per esempio Kodi flatpak che ignora i dns settati nel sistema e bensi va a prendersi quelli che sono presenti nel file stub-resolv.conf e alcuni addons non trovano la rete internet.
Se invece io ci metto i dns nel file ed avvio kodi nelle impostazioni dice che lui usa correttamente i dns settati allora tutti i problemi di rete spariscono come se kodi avesse ora una connessione diretta ad internet.

[SaulGoodman]

Se ho capito correttamente ora il file su /etc/resolv.conf è un collegamento ad un'altro file resolv-stub.conf se non sbaglio a quello in /run/systemd/resolve/stub-resolv.conf

Io ho provato a modificare quel file togliendo il dns che c'è in nameserver ed ho aggiunto i due di cloudflare cioè 1.1.1.1 e 1.0.0.1 salvo il file e la modifica sembra averla accettata.

Il problema sta che quando riavvio però ubuntu questo file sembra resettarsi e torna il singolo nameserver impostato su 127.0.0.53

Certo, ed è così che dev'essere, visto che quel file non è persistente e viene generato a runtime (non a caso sta sotto /run).

Perchè mai questa cosa ? Come la evito sta cosa oppure come la configuro al meglio ?

Perché Ubuntu ha scelto ormai da qualche anno di utilizzare systemd-resolved come default DNS cache/resolver.

I DNS li configuri semplicemente dall'interfaccia grafica del tuo DE (che non specifichi per cui è impossibile fornirti ulteriore aiuto).

[DjDiabolik]

Se ho capito correttamente ora il file su /etc/resolv.conf è un collegamento ad un'altro file resolv-stub.conf se non sbaglio a quello in /run/systemd/resolve/stub-resolv.conf

Io ho provato a modificare quel file togliendo il dns che c'è in nameserver ed ho aggiunto i due di cloudflare cioè 1.1.1.1 e 1.0.0.1 salvo il file e la modifica sembra averla accettata.

Il problema sta che quando riavvio però ubuntu questo file sembra resettarsi e torna il singolo nameserver impostato su 127.0.0.53

Certo, ed è così che dev'essere, visto che quel file non è persistente e viene generato a runtime (non a caso sta sotto /run).

Perchè mai questa cosa ? Come la evito sta cosa oppure come la configuro al meglio ?

Perché Ubuntu ha scelto ormai da qualche anno di utilizzare systemd-resolved come default DNS cache/resolver.

I DNS li configuri semplicemente dall'interfaccia grafica del tuo DE (che non specifichi per cui è impossibile fornirti ulteriore aiuto).

Ok e quello l'ho capito anche io..... in teoria il systemd-resolved dovrebbe avere un file /etc/systemd/resolved.conf che ora ho configurato in questa maniera:

Codice: Seleziona tutto

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
DNS=1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
#FallbackDNS=
#Domains=

Ho tolto il commento dalla riga DNS ed inseriti i dns... ho poi riavviato il servizio dal terminale usando:

Codice: Seleziona tutto

sudo systemctl restart systemd-resolved

In teoria ora i DNS dovrebbero essere usati correttamente perchè dal terminale posso vedere questo:

Codice: Seleziona tutto

diabolik@NUC-Ubuntu:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001

Link 2 (eno1)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 1.0.0.1

Link 3 (wlo2)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Il problema è che il file stub-resolv.conf sembra esser rimasto invariato.... c'è forse da riavviare completamente Ubuntu ?

Tu poi dici che i DNS li configuro semplicemente dall'interfaccia grafica significa che in teoria io li configuro direttamente da GNOME e dalle opzioni ? Si e cosi avevo fatto però poi scopro che praticamente la maggior parte delle app usa invece 127.0.0.53 e non i DNS che invece ho settato dall'interfaccia grafica. E pensa un pò me ne sono accorto per puro caso proprio perchè Kodi ogni tanto nel suo log (controllato per altri motivi) dice che fallisce di connettersi ad internet e va a cercare di risolvere link utilizzando questo dns invece di usare quelli che io ho settato proprio dall'interfaccia grafica.

E qui che ho provato a cercare info in google applicando la modifica sopra fatta ma che poi non sembra essere applicata a pieno....

Per assurdo essendo Kodi un'applicazione flatpak non vorrei che poi le applicazioni flatpak abbiano appunto un sistema tutto loro per gestire la rete e ignorare le impostazioni di sistema, mi sembra anche di aver letto qualcosa del genere in qualche informazione trovata tramite google che dicono di andare a modificare i settaggi e i permessi delle app flatpak in qualche modo ma ciò che ho trovato era relativa ad un'altra app e non kodi e non vorrei fare disastri irreparabili diciamo.

[woddy68]

Sinceramente non ho trovato flatpak che utilizzino dns diversi da quelli impostati in network manager, solo quelle applicazioni come alcuni browser e forse anche Kodi dalle impostazioni è possibile settare un dns differente che utilizza solo quella specifica applicazione.

[DjDiabolik]

Sinceramente non ho trovato flatpak che utilizzino dns diversi da quelli impostati in network manager, solo quelle applicazioni come alcuni browser e forse anche Kodi dalle impostazioni è possibile settare un dns differente che utilizza solo quella specifica applicazione.

Guarda te lo dice Kodi se accedi alle info di sistema.... seppur ora ora ho resettato le configurazioni del resolved.conf e quindi ora la situazione dovrebbe essere questa:

Codice: Seleziona tutto

diabolik@NUC-Ubuntu:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (eno1)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 1.1.1.1 1.0.0.1

Link 3 (wlo2)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Il "problema" (metto le virgolette perchè le righe nel log di kodi dove sembra fallire il check della rete sono sporadiche... sembra farlo però quando lui prova a fare il check degli aggiornamenti per gli addons installati... e per alcuni di essi dice che non riesce a raggiungere i link quanto invece dal browser si aprono gli stessi link. A quel punto non so se è questo 127.0.0.53 che in qualche modo fa fallire la cosa) però resta sempre Kodi che invece dice questo:


Ma anche perchè da Gnome e quindi dall'interfaccia grafica io ho messo i due DNS cloudflare quando invece Kodi ne usa solo uno.

Per assurdo c'è un opzione nel resolved.conf del systemd-resolver... questa forse:

Codice: Seleziona tutto

#DNSStubListener=yes

Se ho capito bene settando su no e togliendo in # del commento dovrebbe fare il link corretto al file resolv.conf e non usare il file stub. Risulta ?


*EDIT dopo alcuni test*
Allora alla fine questa forse è la soluzione migliore.... questa è la parte del file /etc/systemd/resolved.conf

Codice: Seleziona tutto

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
DNS=1.1.1.1
FallbackDNS=1.0.0.1

Da terminale poi ho riavviato il systemd-resolver e quindi ora ho questo su /run/systemd/resolve/resolv.conf:

Codice: Seleziona tutto

# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 1.1.1.1
nameserver 1.1.1.1
nameserver 1.0.0.1
search .

Prima con alcune modifiche che avevo fatto compariva una riga che mi diceva che c'erano troppi DNS settati e che ignorava qualcuno e mi metteva una lista sotto... ora invece compaiono solo questi 3 anche se c'è un doppione che spero non faccia confusione. Dal terminale poi posso vedere questo:

Codice: Seleziona tutto

diabolik@NUC-Ubuntu:~$ resolvectl status
Global
           Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
         DNS Servers: 1.1.1.1
Fallback DNS Servers: 1.0.0.1

Link 2 (eno1)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 1.1.1.1 1.0.0.1

Link 3 (wlo2)
    Current Scopes: none
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
diabolik@NUC-Ubuntu:~$ 

In teoria ora i DNS sono settati come globali... c'è il principale di Cloudflare come principale e il secondo nel Fallback (che onestamente non ho capito quanto entra in gioco).
Nella "Link2 (eno1)" in teoria sono quelli che poi io ho inserito tramite GNOME.

Resta cmq la questione del file stub che invece punta sempre a 127.0.0.53 cosi:

Codice: Seleziona tutto

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

Ora non so.... sono indeciso se cambiassi quel link simbolico e punto al resolv.conf invece che allo stub faccio danni ?


*EDIT Dopo ulteriori test*
Forse sono arrivato al dunque... il problema sta che ora Kodi usa lo stesso DNS due volte.... però ho risolto praticamente cancellando il link simbolico al file stub-resolv.conf e ricreandolo però che punti al file resolv.conf che in teoria dovrebbe creare il systemd-resolved.


Ora c'è da capire se questa cosa viene resettata completamente al riavvio di UBUNTU e devo capire perchè usa due volte lo stesso DNS... forse perchè lo prende uno dal systemd e l'altro da quello che ho inserito in GNOME ? Chi me lo spiega come funziona sta cosa ?

*EDIT 3a volta... credo*
Forse ci siamo.. il resolved.conf è cosi:

Codice: Seleziona tutto

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=1.1.1.1
FallbackDNS=1.0.0.1

Cosi facendo in pratica il resolv.conf viene aggiornato in /run/systemd/resolve/resolv.conf ed è cosi:

Codice: Seleziona tutto

# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 1.1.1.1
nameserver 1.0.0.1
search .

Il link simbolico in /etc/resolv.conf riporta appunto a questo resolv.conf che in teoria viene creato ogni volta dallo stesso systemd-resolved

Kodi ora vede i due DNS settati correttamente......... se nel frattempo avete altri consigli fate pure perchè il file stub per assurdo ha una riga prima del "search ." ma qua non me la ricrea... serve ? E' vitale ?

[SaulGoodman]

Il problema è che il file stub-resolv.conf sembra esser rimasto invariato.... c'è forse da riavviare completamente Ubuntu ?

Tu poi dici che i DNS li configuro semplicemente dall'interfaccia grafica significa che in teoria io li configuro direttamente da GNOME e dalle opzioni ? Si e cosi avevo fatto però poi scopro che praticamente la maggior parte delle app usa invece 127.0.0.53 e non i DNS che invece ho settato dall'interfaccia grafica.

Rispondo a questo perché riguarda il topic, tutto il resto riguarda Kodi da Flatpak che invece non conosco.

127.0.0.53 è un indirizzo "loopback" cioé "locale" cioè fa capo a systemd-resolved che come detto è il default DNS resolver&cache per Ubuntu. Questo non va cambiato (a meno uno non voglia usare systemd-resolved, ovvio, ma questo richiederebbe altre configurazioni).

Quindi è assolutamente normale che le applicazioni usino l'indirizzo 127.0.0.53 come resolver, ed è assolutamente normale che /etc/resolv.conf punti a /run/systemd/resolve/stub-resolv.conf, ed è assolutamente normale che se editi /etc/resolv.conf in realtà stai editando /run/systemd/resolve/stub-resolv.conf, cosa che è assolutamente INUTILE, perché come detto prima /run/systemd/resolve/stub-resolv.conf non è persistente e viene generato a runtime (cioè a ogni avvio del PC). Semmai può essere conveniente modificare i file di configurazione di systemd-resolved, o meglio ancora tramite l'intefaccia grafica di NM che si integra con SySD ed è quindi la via preferibile, piu semplice.

Così facendo ogni applicazione che quera il DNS tramite chiamate di sistema, dovrebbe finire a parlare con systemd che, configurato con i DNS che vuoi (Cloudflare), userà questi. Non devi però cancellare il symlink o editare direttamente /etc/resolv.conf per i motivi anzidetti. Anzi, controlla che il symlink si ancora presente, se no ricrealo.

Detto questo, con i flatpak installati sul mio sistema, non ho mai avuto problemi di risoluzione DNS e Kodi non lo uso. Ma io i DNS li modifico sul DHCP del router, e SysD si limita a girare le query DNS a quelli che il DHCP gli assegna. Per tanto lascio la parola a chi ne sa o ha avuto esperienze simili.

[DjDiabolik]

Il problema è che il file stub-resolv.conf sembra esser rimasto invariato.... c'è forse da riavviare completamente Ubuntu ?

Tu poi dici che i DNS li configuro semplicemente dall'interfaccia grafica significa che in teoria io li configuro direttamente da GNOME e dalle opzioni ? Si e cosi avevo fatto però poi scopro che praticamente la maggior parte delle app usa invece 127.0.0.53 e non i DNS che invece ho settato dall'interfaccia grafica.

Rispondo a questo perché riguarda il topic, tutto il resto riguarda Kodi da Flatpak che invece non conosco.

127.0.0.53 è un indirizzo "loopback" cioé "locale" cioè fa capo a systemd-resolved che come detto è il default DNS resolver&cache per Ubuntu. Questo non va cambiato (a meno uno non voglia usare systemd-resolved, ovvio, ma questo richiederebbe altre configurazioni).

Quindi è assolutamente normale che le applicazioni usino l'indirizzo 127.0.0.53 come resolver, ed è assolutamente normale che /etc/resolv.conf punti a /run/systemd/resolve/stub-resolv.conf, ed è assolutamente normale che se editi /etc/resolv.conf in realtà stai editando /run/systemd/resolve/stub-resolv.conf, cosa che è assolutamente INUTILE, perché come detto prima /run/systemd/resolve/stub-resolv.conf non è persistente e viene generato a runtime (cioè a ogni avvio del PC). Semmai può essere conveniente modificare i file di configurazione di systemd-resolved, o meglio ancora tramite l'intefaccia grafica di NM che si integra con SySD ed è quindi la via preferibile, piu semplice.

Così facendo ogni applicazione che quera il DNS tramite chiamate di sistema, dovrebbe finire a parlare con systemd che, configurato con i DNS che vuoi (Cloudflare), userà questi. Non devi però cancellare il symlink o editare direttamente /etc/resolv.conf per i motivi anzidetti. Anzi, controlla che il symlink si ancora presente, se no ricrealo.

Detto questo, con i flatpak installati sul mio sistema, non ho mai avuto problemi di risoluzione DNS e Kodi non lo uso. Ma io i DNS li modifico sul DHCP del router, e SysD si limita a girare le query DNS a quelli che il DHCP gli assegna. Per tanto lascio la parola a chi ne sa o ha avuto esperienze simili.

Quello che tu indichi è tutto esattamente corretto......... Se seguirai quello che ho fatto qua sopra alla fine è quello che ho provato a fare io poi ho introdotto Kodi perchè in effetti e quello che, almeno quanto pare, con alcuni addons va in errore di risoluzione dell'ip relativi all'uso del 127.0.0.53.
Sta cosa alla fine ora che sembra sia riuscito a far usare a Kodi direttamente i due 1.1.1.1 e 1.0.0.1 devo verificare se questi log scompaiono...

Cmq sia torniamo a quanto tu dici:
Quello che è chiaro è cmq sia una cosa...... Ubuntu di default sembra usare proprio il systemd-resolver per gestire i DNS e seppur io dal Desktop e quindi dalle impostazioni di GNOME ho configurato i due DNS manualmente Cloudflare lui passa sempre per questo DNS ponte diciamo.

Visto che questo è un loopback locale non dovrebbe creare problemi di sorta un pò come se pinghi l'indirizzo ip 127.0.0.1 se usato come localhost esatto ?

Con NM credo tu citi Network Manager che io non ho installato....

Cmq quello che ho fatto io ora in teoria è agire direttamente sul file .conf del sistemd-revolver cioè andando a configurare il file resolved.conf come indicato.

Riavviando poi il systemd-resolved direttamente (che credo riavvi anche il processo di sistema a sto punto) ho notato che appunto viene modificato a sua volta e viene adeguato il resolv.conf che è su /run/systemd/resolve/

Originalmente però come detto il file /etc/resolv.conf, come detto, punta alla sua controparte stub-resolv.conf.

Io in pratica ora ho cambiato questo link... invece di farlo puntare al file stub-resolv.conf l'ho fatto puntare al resolv.conf cosi, in teoria, escludendo l'uso di questo DNS loopback e quindi facendo che il sistema interroga direttamente il DNS invece di passare per il loopbak.

Da quello che poi ho capito questo loopback 127.0.0.53 viene poi utilizzato perchè tramite il systemd-resolved vengono automaticamente gestiti più DNS contemporaneamente e invece di settare 10 DNS insieme appunto c'è questo loopback che credo possiamo dire fa lui questo lavoro.

Poi magari sto solo facendo un pastrocchio infinito...... spero solo che se domani o dopodomani rimango senza rete di poter ripristinare tutto alla conf default e poter ripartire da zero ... lol.

[SaulGoodman]

https://unix.stackexchange.com/question ... nd-run-sys

Scrivi meno, per cortesia. Sei troppo prolisso.

[DjDiabolik]

https://unix.stackexchange.com/question ... nd-run-sys

Scrivi meno, per cortesia. Sei troppo prolisso.

E sono prolisso io ? Il commento sotto allora cos'è ?

https://unix.stackexchange.com/a/783931

Se è questo il problema chiudiamola qua perchè tanto s'è detto tutto. Visto che anche quell'infinito post alla fine indica ciò che ho appena fatto io cioè :

Codice: Seleziona tutto

  # ln -s /run/systemd/resolve/resolv.conf   /etc/resolv.conf 

e le configurazioni dirette nel systemd direttamente nel file resolved.conf.

Cosi facendo da quello che ho capito perdo qualche teorico vantaggio che ha invece l'uso del systemd ma il sistema interroga il dns direttamente. Il lungo commento parla di una cache o di dettagli tecnici che onestamente non credo siano nemmeno il mio caso specifico.

Poi sono prolisso cosa ? Se non vi dico poi mi dite che non vi spiego i dettagli e che ometto le informazioni.... scherziamo vero ?
Intanto metto la discussione come [Risolto] perchè cmq dovrei aver capito come funziona....... al massimo vi chiedo come e se possibile resettare tutto.

[SaulGoodman]

in una richiesta di supporto bisogna riportare le informazioni essenziali e quello che ti serve fare, non le tue supposizioni, interpretazioni e quant'altro che non fanno altro che appesantire e rendere difficile l'aiuto. Ma te lo dico da amico eh, non per sgridarti o altro.

In ogni caso, il punto saliente è questo:

Using resolv.conf instead of stub-resolv.conf will bypass a lot of systemd-resolved configuration, such as DNS answer caching, per-interface DNS configuration, DNSSec enforcement, etc.

Se vuoi leggerti anche il resto della risposta (la prima in ordine di voti, non è poi tanto lunga) in cui si spiega la differenza tra le due opzioni. Per il resto si, credo non ci sia altro da aggiungere. Alla fine hai trovato la soluzione che era meglio per te. : ciao:

[DjDiabolik]

in una richiesta di supporto bisogna riportare le informazioni essenziali e quello che ti serve fare, non le tue supposizioni, interpretazioni e quant'altro che non fanno altro che appesantire e rendere difficile l'aiuto. Ma te lo dico da amico eh, non per sgridarti o altro.

Ma infatti non me la sono presa ho semplicemente spiegato il perchè trovo giusto essere prolisso sopratutto in quelle situazioni non so dove metter mano e voler evitar di far danni.
Poi non ho fatto supposizioni... ho fatto EDIT e miei test semplicemente perchè non sono uno che mi piace stare con le mani in mano e anche dopo aver aperto un thread di supporto sono andato e continuato a cercare info in rete e possibili alternative su come arrivare ad una possibile soluzione.

In ogni caso, il punto saliente è questo:

Using resolv.conf instead of stub-resolv.conf will bypass a lot of systemd-resolved configuration, such as DNS answer caching, per-interface DNS configuration, DNSSec enforcement, etc.

Se vuoi leggerti anche il resto della risposta (la prima in ordine di voti, non è poi tanto lunga) in cui si spiega la differenza tra le due opzioni. Per il resto si, credo non ci sia altro da aggiungere. Alla fine hai trovato la soluzione che era meglio per te. : ciao:

Ma infatti alla fine il punto è quello. Quel post lungo che t'ho citato andrebbe riletto perchè, seppur sia tutto in inglese, mi sembra contiene esempi e spiegazioni che entrano molto nello specifico della differenza di usare ciò che ho fatto io ed invece usare il file stub-resolv.conf.

Quel post li è sicuramente interessante perchè entra parecchio nello specifico... nel mio caso particolare poi bisognerebbe veramente vedere quali sono veramente i limiti e quali gli svantaggi ad usare una soluzione o l'altra.
Spulciando sempre quel reply li dice che se tu hai un'applicazione che utilizza il protocollo NSS e lasciando il systemd-resolver completamente stock dovrebbe velocizzare la procedura stessa rispetto invece usare un solo DNS fisso perchè, sempre ammesso che ho capito correttamente, riesce ad usare più DNS contemporaneamente ?
Mi riferisco in pratica a ciò che viene detto nell'ultima parte e che ho tradotto col google traduttore questa:

The point is that what dns server or servers will be used to process our dns request when it gets inside SR depends on the content of all sections of SR. For instance in this particular configuration g.com will be forwarded to 1.1.1.1, and ns1.nyc3.example.com will be forwarded to 172.16.10.11 and request google.net will be processed via 1.1.1.1 AND 172.16.10.11 AT THE SAME TIME.
It will be so only if an application uses NSS. If it doesnt it depends if it reads /etc/resolv.conf or not.

Ma onestamente poi... per ciò che serve a me serve veramente tutto questo ? Me ne accorgerò col tempo.

Intanto ovviamente, e non l'ho fatto ancora e scusami, grazie per questa ultima e per le precedenti tue risposte qua sopra.


*EDIT*
Ebbene si... per ampie parti del lungo articolo avevo usato Google Translator. Ma perchè non chiedere il parere a ChatGPT ? linkandogli lo stesso tuo link... la sua spiegazione è questa sostanzialmente quello che abbiamo già detto:

Questo articolo tratta di come funziona **systemd-resolved** (SR), un programma di Linux che risolve i nomi di dominio (come "google.com") trasformandoli in indirizzi IP (come "8.8.8.8"). Ecco una spiegazione semplificata di ciò che accade, come se stessi spiegando a un bambino:

### Cos'è systemd-resolved?
**systemd-resolved (SR)** è come un "intermediario" che aiuta il computer a trovare gli indirizzi IP associati ai nomi dei siti web. Quando un programma del computer (come il browser o il terminale) vuole connettersi a un sito web (ad esempio "google.com"), ha bisogno di conoscere l'indirizzo IP di quel sito. SR si occupa di questo, facendo da "intermediario" e chiedendo a un altro server DNS per trovare l'indirizzo giusto.

### La configurazione di SR
SR usa dei file speciali per sapere dove trovare gli indirizzi IP dei server DNS (gli "intermediari" che danno gli indirizzi IP). Ecco i file importanti che SR crea:

- **/run/systemd/resolve/resolv.conf**
- **/run/systemd/resolve/stub-resolv.conf**
- **/lib/systemd/resolv.conf**

Ogni file ha un compito diverso:
- Il file **stub-resolv.conf** dice che il server DNS che SR usa è "127.0.0.53", che è come un indirizzo speciale per il servizio SR.
- Il file **resolv.conf** invece può indicare altri server DNS, come ad esempio "1.1.1.1" (un server pubblico di Cloudflare).

### Come funziona la risoluzione DNS
Quando un'applicazione come **ping** o **curl** deve risolvere un dominio (ad esempio "google.com"), può farlo in vari modi:
1. **Se usa NSS** (un tipo di "sistema" che aiuta a risolvere i domini), l'applicazione manda la richiesta a SR, che quindi la inoltra al server DNS giusto.
2. **Se non usa NSS**, l'applicazione può usare un altro metodo per risolvere i domini, come il programma **dig**, che può saltare SR e andare direttamente a un server DNS come "8.8.8.8".

### I file **/etc/resolv.conf**
Anche se **/etc/resolv.conf** è un file importante per la risoluzione dei DNS, SR non lo usa per trovare i server DNS. Invece, crea i propri file di configurazione. Se vuoi che il tuo sistema usi SR come server DNS, puoi creare un "collegamento simbolico" (come una scorciatoia) in **/etc/resolv.conf**, che punti a uno dei file di SR. Ad esempio:

```bash
ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
```

### Differenza tra i file di configurazione
- Se un'applicazione legge **stub-resolv.conf**, manda la richiesta a SR (e SR la inoltra al server DNS giusto).
- Se un'applicazione legge **resolv.conf**, la richiesta va direttamente al server DNS indicato lì (come "1.1.1.1").

### Come funziona l'applicazione
- Le applicazioni che usano **NSS** (come ping o Firefox) possono inviare le richieste a SR senza bisogno di usare **/etc/resolv.conf**. Quindi, anche se non vedono questo file, SR è comunque coinvolto.
- Se un'applicazione non usa NSS, allora potrebbe usare direttamente **/etc/resolv.conf** o un altro metodo, a seconda di come è configurata.

### Perché è importante?
- **Se usi SR come server DNS**, ottieni dei vantaggi, come una maggiore velocità (perché SR può "memorizzare" le risposte per non doverle cercare di nuovo ogni volta) e la possibilità di instradare le richieste DNS in modo più flessibile.

### Riassumendo
- **NSS** è un sistema che molte applicazioni usano per risolvere i nomi di dominio. Se un'applicazione usa NSS, non ha bisogno di leggere **/etc/resolv.conf**. Piuttosto, invia la richiesta a SR.
- Se un'applicazione non usa NSS, potrebbe comunque leggere **/etc/resolv.conf** per sapere dove inviare la richiesta DNS.
- Puoi fare in modo che SR gestisca tutte le richieste DNS usando il giusto collegamento simbolico a **/etc/resolv.conf**.

### Sintesi:
Immagina SR come un "traduttore" che ti aiuta a capire gli indirizzi IP partendo dai nomi di dominio. Le applicazioni possono decidere se parlare direttamente con SR o se parlare direttamente con altri server DNS. Se tutto è configurato correttamente, SR ti aiuta a mantenere tutto organizzato e a velocizzare le cose.

Se hai domande più specifiche su una parte del testo o vuoi chiarimenti su qualcosa, fammi sapere!

ora mi odierai profondamente..... ma ChatGPT ci conferma ancora un volta che già ci eravamo detti in precedenti. Gli ho chiesto quindi se la mia soluzione potrebbe essere una buona soluzione.. se ne esce così:

La tua soluzione di cambiare il link simbolico di `/etc/resolv.conf` per farlo puntare a `/run/systemd/resolve/resolv.conf` può risolvere il problema in alcune circostanze, ma è importante capire bene cosa implica e se sia la scelta migliore in base alla tua situazione.

### Analisi della tua soluzione

#### 1. **Che cosa fa il file `/run/systemd/resolve/resolv.conf`?**
Questo file è una versione di **resolv.conf** generata da **systemd-resolved** (SR) e contiene l'indirizzo IP di un server DNS che SR sta utilizzando (in genere un server upstream configurato in `/etc/systemd/resolved.conf`). Se tu fai puntare **/etc/resolv.conf** a questo file, stai dicendo al sistema di usare direttamente il server DNS configurato da SR come **server DNS principale**.

- Questo approccio significa che **SR** sarà ancora in uso, ma la configurazione avverrà tramite un file che è gestito da SR, piuttosto che attraverso il file **stub-resolv.conf** (che di solito reindirizza a **127.0.0.53**, un indirizzo locale usato per la comunicazione con SR).

#### 2. **Qual è la differenza tra stub-resolv.conf e resolv.conf?**
- **/run/systemd/resolve/stub-resolv.conf**: Questo file è pensato per essere usato da applicazioni che si aspettano di comunicare direttamente con SR tramite l'indirizzo **127.0.0.53**. Se un'applicazione tenta di fare una richiesta DNS a **127.0.0.53**, il traffico viene indirizzato a SR che poi risolve il nome di dominio.
- **/run/systemd/resolve/resolv.conf**: Questo file contiene il server DNS (come **1.1.1.1** o **8.8.8.8**) che SR sta utilizzando per risolvere i domini. Se cambi **/etc/resolv.conf** per puntare a questo file, non stai più comunicando con SR tramite **127.0.0.53**, ma stai dicendo al sistema di usare direttamente il server DNS configurato in SR.

### Pro e contro della tua soluzione
**Pro:**
- Se il problema dell'applicazione è legato al fatto che sta cercando di comunicare con SR tramite **127.0.0.53** e riscontra errori, indirizzarla direttamente al server DNS configurato in `/run/systemd/resolve/resolv.conf` potrebbe bypassare il problema.
- Potresti migliorare la situazione se SR sta causando conflitti o ritardi nelle risoluzioni DNS.

**Contro:**
- **Vantaggi di SR**: Una delle principali caratteristiche vantaggiose di SR è che gestisce il caching delle risoluzioni DNS, il che può velocizzare le richieste successive. Inoltre, SR offre una gestione più flessibile delle risoluzioni DNS, come la possibilità di avere diverse configurazioni per interfacce di rete.
- Se disabiliti completamente SR cambiando il link simbolico come hai fatto, perderesti questi benefici.
- Se l'applicazione funziona correttamente senza SR e non hai bisogno di funzionalità avanzate come il caching, potrebbe non esserci un vero "contro" nel cambiare il comportamento, ma è qualcosa da tenere a mente se un giorno vuoi sfruttare le funzionalità di SR.

### Cosa ti consiglio?
- **Testa la soluzione**: Se il cambiamento a `/run/systemd/resolve/resolv.conf` risolve il problema dell'applicazione senza causare altri effetti collaterali, allora probabilmente va bene. Tuttavia, monitora il comportamento della rete e la risoluzione dei domini in altre applicazioni per verificare che tutto funzioni correttamente.

- **Alternativa senza disabilitare SR**: Se vuoi mantenere i vantaggi di SR (come il caching e la gestione flessibile dei DNS), puoi provare un'altra soluzione senza disabilitarlo completamente:
- **Usa il file `stub-resolv.conf`** come hai fatto, ma risolvi eventuali problemi con l'applicazione che ne fa uso, magari configurando meglio l'applicazione stessa o modificando il comportamento di SR tramite la configurazione di `/etc/systemd/resolved.conf`.

- **Considera disabilitare SR**: Se SR non è necessario per il tuo ambiente e non hai bisogno delle sue funzionalità, puoi anche disabilitarlo completamente, ma dovresti poi configurare un altro resolver DNS come **dnsmasq** o **unbound** per gestire le richieste DNS in modo manuale.

### Conclusione
La tua soluzione di usare **/run/systemd/resolve/resolv.conf** è valida per bypassare SR se il problema riguarda la comunicazione con SR stesso, ma assicurati che non influisca su altre funzionalità importanti, come il caching DNS e la flessibilità nelle risoluzioni. Se SR ti offre vantaggi che desideri mantenere, potresti dover cercare una soluzione diversa che permetta all'applicazione di comunicare correttamente con SR (ad esempio, verificando la configurazione di SR o dell'applicazione).

Detto questo passo e chiudo per ora.