Come verificare se il DNS sta causando errori di connessione a Immich

Il DNS è un probabile responsabile di Immich solo quando il client che presenta il problema non riesce a convertire il nome host esatto di Immich nell’indirizzo che dovrebbe gestire il servizio, oppure quando tale risposta cambia a seconda dei resolver, delle reti o del momento.

Verifica separatamente la risoluzione del nome e la raggiungibilità dell’applicazione. Una connessione riuscita a livello IP può dimostrare che esistono un percorso e una porta disponibili, ma non prova che HTTPS, il routing del reverse proxy, i certificati o le regole basate sull’host funzioneranno senza il nome host. Il flusso di lavoro più sicuro registra il nome esatto che presenta il problema, lo interroga dal client interessato, confronta i resolver e quindi ripete l’azione originale in Immich dopo una singola modifica al livello DNS.

Definisci il nome host esatto e il percorso dell’errore

Annota il nome host effettivamente utilizzato dal client Immich che presenta il problema, la rete a cui è connesso, l’orario dell’errore e se il problema riguarda l’app web, l’app mobile o entrambe. Non iniziare con un test generico, ad esempio risolvendo un dominio pubblico non correlato, perché ciò dimostra soltanto che un qualche percorso DNS funziona.

Confronta lo stesso nome host da un client funzionante e da quello che presenta il problema. Registra ogni risposta A e AAAA, il resolver che ha risposto e se il client si trova nella rete domestica, sulla rete dati mobile o dietro una VPN. Risposte diverse possono essere intenzionali con lo split DNS, ma devono comunque indirizzare ogni client verso un endpoint raggiungibile.

Come controllo, verifica se l’indirizzo e la porta del server previsti sono raggiungibili senza affidarti alla normale ricerca DNS. Consideralo soltanto un modo per distinguere il percorso di rete: certificati HTTPS, SNI, reverse proxy e host virtuali possono comunque rifiutare una richiesta basata sull’indirizzo IP anche quando il servizio è integro.

Interroga il DNS dal client interessato, non solo dal server

Esegui una query DNS sul dispositivo o nell’ambiente in cui si verifica effettivamente il problema. Se il client Immich si trova dietro una VPN, un profilo DNS privato, uno stub del container o un resolver fornito dal router, una query eseguita direttamente dal server potrebbe utilizzare un percorso DNS diverso e nascondere il problema.

Interroga prima il nome host che presenta il problema tramite il resolver predefinito del client, quindi interroga esplicitamente un resolver di confronto noto o il resolver interno previsto. Una query mirata con dig mostra la risposta restituita, il server che ha risposto, lo stato e il tempo della query, consentendo di capire se il problema dipende da un resolver specifico.

Ripeti la query più volte invece di fidarti di un singolo risultato positivo. Registra NXDOMAIN, SERVFAIL, timeout, indirizzi obsoleti o risposte A/AAAA incoerenti. Una risposta corretta e stabile sposta i sospetti dalla risoluzione DNS di base verso il routing, il proxy, TLS, il firewall o la configurazione dell’applicazione.

Confronta i risultati dei resolver e i tipi di errore

Interpreta il codice di risposta prima di modificare le impostazioni. NXDOMAIN significa che, secondo quel resolver, il nome interrogato non esiste; SERVFAIL significa che la risoluzione non è stata completata; un timeout significa che il resolver non ha risposto in tempo. Una risposta sintatticamente corretta può comunque essere errata se punta al vecchio indirizzo del router o a un endpoint irraggiungibile.

Gli errori di nome non trovato e gli errori temporanei del resolver seguono percorsi diversi. Usa le differenze tra gli errori di risoluzione dei nomi per decidere se correggere un record mancante, un resolver irraggiungibile o un percorso DNS instabile, invece di trattare ogni errore di ricerca come lo stesso problema.

Se solo il resolver domestico restituisce l’indirizzo vecchio o errato mentre un altro resolver restituisce il valore pubblico previsto, controlla gli override locali, i record split DNS, il DNS fornito dal DHCP, i servizi di filtraggio e le cache. Se tutti i resolver restituiscono lo stesso indirizzo corretto, smetti di modificare il DNS e passa al percorso del servizio.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Usa un bypass controllato per confermare o escludere il DNS

Crea un controllo temporaneo e reversibile che modifichi soltanto la risoluzione dei nomi per il client interessato. Ad esempio, interroga direttamente un resolver diverso oppure usa temporaneamente una voce nel file hosts che associ il nome host esatto di Immich all’endpoint noto e previsto. Conserva le impostazioni originali per poter annullare immediatamente il test.

Se il flusso di lavoro originale di Immich inizia a funzionare mentre il nome host resta identico e cambia soltanto il percorso di risoluzione, il DNS è fortemente sospettato. Se lo stesso nome host continua a non funzionare dopo essere stato risolto verso l’endpoint verificato, il problema è a valle del DNS e devi controllare il routing del proxy, i certificati, il NAT, le regole del firewall o il servizio Immich stesso.

Se una singola query eseguita correttamente non riesce a riprodurre il problema riscontrato nella rete domestica, confronta nel tempo lo stato dell’host, del container, del resolver locale, del resolver upstream, del DHCP, della VPN e della cache. Un controllo DNS multilivello aiuta a individuare i casi intermittenti che scompaiono durante un test una tantum.

Svuota la cache corretta e ripeti il flusso di lavoro originale in Immich

Dopo aver corretto un record DNS, un resolver, un’opzione DHCP, una regola split DNS o un override locale, svuota, quando possibile, soltanto la cache del client o del resolver pertinente. Non svuotare ripetutamente ogni livello senza annotare ciò che hai modificato, perché potresti rendere impossibile spiegare un successo temporaneo.

Risolvi nuovamente il nome host dal client interessato e verifica la risposta A/AAAA prevista, il resolver e il tempo di risposta. Poi accedi a Immich tramite il normale nome host, carica risorse meno recenti, esegui una ricerca e completa un caricamento sicuro o un’altra azione di scrittura, così il test copre più della sola pagina di accesso.

Ripeti il controllo nello stato di rete in cui si è verificato originariamente il problema, ad esempio sulla rete dati mobile, sul Wi-Fi domestico, sul Wi-Fi con VPN connessa o dopo il rinnovo del router/DHCP. Il DNS può essere escluso come causa principale solo quando il normale nome host rimane corretto durante l’evento che in precedenza causava il problema; in caso contrario, conserva le nuove informazioni e prosegui al livello di rete successivo.