Guide för distribution av Split DNS för lokala och fjärranslutna egenhostade appar

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

Det säkra tillvägagångssättet är att behandla en stegvis split-DNS-distribution med deterministisk resolveromfattning, matchad TLS-identitet, övergångstester och återställning som en sekvens av observerbara kontrollpunkter, inte som ett enda kommando.

För egenhostade appar bakom lokala och fjärranslutna reverse proxy-vägar är den praktiska risken att samma appvärdnamn måste lösas till avsiktliga lokala, VPN- och offentliga slutpunkter utan överraskningar med certifikat eller routing. Dokumentera aktuell identitet och återställningspunkt, börja med den minst ingripande särskiljaren, tolka godkända och underkända resultat innan du ändrar en annan variabel och stoppa när lagringen blir instabil eller den enda återställningsbara kopian skulle exponeras. Arbetsflödet nedan avslutas först när den ursprungliga arbetsbelastningen fungerar eller bevisen når en eskaleringsgräns.

Definiera namn, vyer och förtroendegränser

Välj ett fullständigt kvalificerat värdnamn per applikation och dokumentera vilket svar som förväntas för betrodda LAN-, VPN-, gäst- och offentliga klienter. Behåll applikationens identitet och TLS-namn konstanta medan den returnerade adressen ändras; användning av orelaterade interna namn bryter ofta omdirigeringar, callback-adresser, bokmärken och mobilklienter.

Ett praktiskt hemmalabbsupplägg är att returnera en privat proxyadress internt och en offentlig proxy- eller tunnel-slutpunkt externt. split-DNS-designen med ett namn visar denna design med ett namn och två svar och framhäver att DNS challenge-validering kan utfärda ett certifikat utan att göra en intern tjänst offentligt nåbar.

Bestäm vilka nätverk som aldrig får privata poster. Gäst- och IoT-klienter kan behöva den offentliga vägen eller inget svar alls, och den offentliga zonen får inte exponera privata adresser eller interna värdnamn.

Distribuera den lokala vyn utan att ändra den offentliga vägen

Sänk relevanta TTL-värden före migreringen, lägg till den interna åsidosättningen på den valda resolvern och fråga uttryckligen denna resolver från en kanarieklient. Verifiera A- och AAAA-poster separat, eftersom ett korrekt IPv4-svar kan kringgås av ett inaktuellt eller offentligt IPv6-svar.

Annonsera den interna resolvern via DHCP och VPN-konfigurationen och kontrollera den aktiva resolvern på varje operativsystem. Webbläsarens säkra DNS, privat DNS på mobilen, cachade svar och en manuellt konfigurerad resolver kan kringgå den avsedda vyn även när den lokala zonen är korrekt.

Använd den befintliga split-horizon-DNS-konfigurationen för ZimaSpace som konfigurationsgräns, medan detta arbetsflöde fokuserar på distributionsordning och godkännande. Ändra inte offentlig DNS, lokal proxyrouting och klienternas resolverpolicy i ett enda steg; varje lager behöver ett separat godkänt resultat eller en separat återställning.

Samordna DNS-svar med proxy- och certifikatidentiteten

Öppna värdnamnet från LAN-kanarien och dokumentera den upplösta adressen, routen, TLS-certifikatets namn, svarsvärden, omdirigeringar, WebSocket-beteendet och den URL som applikationen genererar. Det räcker inte att nå en webbsida om begäran hamnar på fel virtuella värd eller omdirigeras till en IP-adress.

Upprepa från mobilnätet eller ett annat externt nätverk med Wi-Fi avstängt. Adressen kan ändras, men värdnamnet, certifikatidentiteten, inloggningen och applikationsdata måste förbli konsekventa. Om interna och externa vägar avsiktligt använder olika proxyservrar måste båda routa samma värd korrekt.

Testa VPN-åtkomst utifrån hemmet. Om VPN:et ska få det privata svaret men får det offentliga, korrigera DNS-tilldelningen eller den delade routingen innan du lägger till ytterligare en åsidosättning för en applikation.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Validera övergångar och spara en återställningspost

Flytta kanarien mellan LAN, mobilnät och VPN och dokumentera frågeresultaten när TTL-värdet har löpt ut. Testa en ny webbläsarsession och en befintlig inloggad session så att DNS-framgång inte döljer cookie-, callback- eller sessionsbeteende som är kopplat till ett annat värdnamn.

Starta om resolvern och proxyn en gång, förnya klientens lease och upprepa vägm angeringen. Bekräfta att orelaterade offentliga poster och interna tjänster behåller sina tidigare svar; en delad zon som skuggar saknade offentliga poster är en ofullständig distribution.

Distribuera till andra klienter först när varje vy är deterministisk. Återställ den interna åsidosättningen om klienterna inte kan hållas på den avsedda resolvern, certifikatidentiteten skiljer sig eller en privat adress läcker offentligt; spara frågeutdata och tidsstämplar inför nästa försök.