Guida alla configurazione del DNS split per app self-hosted locali e remote

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Split DNS Deployment Guide for Local and Remote Self-Hosted Apps - Zima Store Online

L’approccio sicuro consiste nel trattare una distribuzione staged di split-DNS con ambito del resolver deterministico, identità TLS corrispondente, test di transizione e rollback come una sequenza di controlli osservabili, non come un singolo comando.

Per le app self-hosted dietro percorsi di reverse proxy locali e remoti, il rischio pratico è che lo stesso hostname dell’app debba risolversi in endpoint locali, VPN e pubblici intenzionali, senza sorprese legate a certificati o routing. Registra l’identità attuale e il punto di ripristino, inizia con il discriminatore meno invasivo, interpreta i risultati positivi e negativi prima di modificare un’altra variabile e fermati quando lo storage diventa instabile o l’unica copia recuperabile verrebbe esposta. Il workflow seguente termina solo dopo che il workload originale funziona correttamente o che le evidenze raggiungono una soglia di escalation.

Definisci nomi, viste e confini di attendibilità

Scegli un hostname completo per ogni applicazione e documenta la risposta prevista per client LAN attendibili, VPN, guest e pubblici. Mantieni costanti l’identità dell’applicazione e il nome TLS mentre cambia l’indirizzo restituito; l’uso di nomi interni non correlati spesso interrompe redirect, callback, segnalibri e client mobili.

Un pattern pratico per un home lab consiste nel restituire internamente un indirizzo del proxy privato e, esternamente, un proxy pubblico o un endpoint tunnel. Il design split-DNS con un solo nome mostra questo schema con un nome e due risposte e sottolinea che la convalida tramite DNS challenge può emettere un certificato senza rendere pubblicamente raggiungibile un servizio interno.

Decidi quali reti non devono mai ricevere record privati. I client guest e IoT potrebbero aver bisogno del percorso pubblico o di nessuna risposta, e la zona pubblica non deve esporre indirizzi privati o hostname solo interni.

Distribuisci la vista locale senza modificare il percorso pubblico

Riduci i TTL pertinenti prima della migrazione, aggiungi l’override interno sul resolver scelto ed esegui query esplicite a quel resolver da un client canary. Verifica separatamente i record A e AAAA, perché una risposta IPv4 corretta può essere aggirata da una risposta IPv6 obsoleta o pubblica.

Distribuisci il resolver interno tramite DHCP e la configurazione VPN, quindi controlla il resolver effettivo su ogni sistema operativo. Il DNS sicuro del browser, il DNS privato dei dispositivi mobili, le risposte memorizzate nella cache e un resolver configurato manualmente possono aggirare la vista prevista anche quando la zona locale è corretta.

Usa la configurazione split-horizon DNS di ZimaSpace esistente come confine della configurazione, mentre questo workflow si concentra sull’ordine di distribuzione e sull’accettazione. Non modificare DNS pubblico, routing del proxy locale e criteri del resolver client in un unico passaggio; ogni livello richiede un risultato distinto di superamento o rollback.

Allinea le risposte DNS con l’identità del proxy e del certificato

Apri l’hostname dal client canary della LAN e registra l’indirizzo risolto, il percorso, il nome del certificato TLS, l’host della risposta, i redirect, il comportamento WebSocket e l’URL generato dall’applicazione. Raggiungere una pagina web non è sufficiente se la richiesta arriva al virtual host sbagliato o viene reindirizzata a un indirizzo IP.

Ripeti da una rete cellulare o da un’altra rete esterna con il Wi-Fi disabilitato. L’indirizzo può cambiare, ma hostname, identità del certificato, accesso e dati dell’applicazione devono rimanere coerenti. Se i percorsi interni ed esterni usano intenzionalmente proxy diversi, entrambi devono instradare correttamente lo stesso host.

Testa l’accesso VPN dall’esterno della rete domestica. Se la VPN dovrebbe ricevere la risposta privata ma riceve quella pubblica, correggi l’assegnazione DNS o lo split routing prima di aggiungere un altro override dell’applicazione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Convalida le transizioni e conserva un registro di rollback

Sposta il client canary tra LAN, rete cellulare e VPN, registrando i risultati delle query dopo la scadenza del TTL. Testa una sessione del browser nuova e una sessione con accesso già effettuato, così il successo del DNS non nasconde comportamenti relativi a cookie, callback o sessioni associati a un host diverso.

Riavvia una volta il resolver e il proxy, rinnova il lease del client e ripeti la matrice dei percorsi. Verifica che i record pubblici non correlati e i servizi interni mantengano le risposte precedenti; una zona split che oscura i record pubblici mancanti è una distribuzione incompleta.

Distribuisci agli altri client solo dopo aver reso deterministica ogni vista. Esegui il rollback dell’override interno se i client non possono essere mantenuti sul resolver previsto, l’identità del certificato diverge o un indirizzo privato trapela pubblicamente; conserva l’output delle query e i timestamp per il tentativo successivo.