Kan en hemrouter lösa split-DNS för både IPv4 och IPv6?

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.

Can a Home Router Resolve Split DNS for Both IPv4 and IPv6? - Zima Store Online

Ja, om routern eller den delegerade resolvern levererar de avsedda A- och AAAA-svaren till rätt klientnätverk och klienterna faktiskt använder den resolvern för båda adressfamiljerna.

Detta blir en verklig kompatibilitetsfråga när interna värdnamn måste matchas mot privata IPv4- och IPv6-adresser, medan offentliga klienter får offentliga svar. Börja med en temporär sökväg eller ett testkonto, behåll det tidigare fungerande tillståndet tillgängligt och bedöm designen utifrån den ursprungliga arbetsbelastningen i stället för ett engångstest av anslutningen.

Separera den stödda arkitekturen från den riskfyllda

Den stödda grenen är klientanpassade A- och AAAA-svar från en gemensam auktoritativ policy. Den konkurrerande grenen är att IPv6-klienter kringgår den lokala resolvern eller får en global adress eller ULA-adress som inte går att nå. Dokumentera versioner, identiteter, adresser, monteringssökvägar, behörigheter och det aktuella observerbara tillståndet innan du ändrar någon av grenarna.

De relevanta split DNS-vyerna definierar den första kompatibilitetsgränsen. Använd dem för att avgränsa påståendet och verifiera sedan samma beteende på just denna hemserver i stället för att behandla en dokumenterad funktion som bevis på att hela designen fungerar.

Skriv beslutsregeln före testningen: godkänt måste innebära att varje nätverk får den avsedda adressfamiljen och når samma certifikatförsedda tjänst utan offentlig hairpinning; underkänt omfattar att AAAA läcker en offentlig eller inaktuell adress, att klienter använder krypterad extern DNS eller att IPv6-routning och brandväggspolicy inte stämmer överens med svaret. Detta förhindrar att en delvis fungerande anslutning eller ett rent kommandoavslut misstolkas som kompatibilitet från början till slut.

Återskapa den exakta lagrings- och nätverkssökvägen

Använd en kontrollerad skiljefaktor: fråga efter A och AAAA från varje VLAN, kontrollera vilken resolver som faktiskt används och anslut sedan över båda adressfamiljerna med offentlig reservväg avstängd under testet. Håll klient, arbetsbelastning, filuppsättning, konto och tidpunkt konstanta så att den ändrade komponenten är den enda rimliga förklaringen.

Använd dnsmasq-adressregler för att välja den andra observationen som är viktig för denna sökväg. Fånga båda sidorna av transaktionen: resolver eller rutt, förhandlat protokoll, processidentitet, avslutningsstatus, latens, överförda byte och eventuella återställningshändelser.

Upprepa testet efter den livscykelhändelse som anges i rubriken - återskapande, återanslutning, återmontering, omstart, redundansväxling eller klientbyte. En design som bara fungerar medan gamla socketar, cacheposter eller autentiseringsuppgifter fortfarande är aktiva har inte klarat testet.

dig A app.home @router
dig AAAA app.home @router
curl -4 https://app.home
curl -6 https://app.home

Tolka resultat för varaktighet, tidsgränser och återställning

GODKÄNT: varje nätverk får den avsedda adressfamiljen och når samma certifikatförsedda tjänst utan offentlig hairpinning. Spara de exakta versionerna och den topologi som skapade detta tillstånd, eftersom slutsatsen gäller dessa förhållanden och inte varje implementering av protokollet.

UNDERKÄNT: AAAA läcker en offentlig eller inaktuell adress, klienter använder krypterad extern DNS eller IPv6-routning och brandväggspolicy inte stämmer överens med svaret. Kontrollera gemensamma beroenden som DNS, MTU, identitet, brandväggstillstånd, lagringslatens och cachade sessioner innan du fastställer att någon av huvudgrenarna är ansvarig.

UNDANTAG: ta bort den felaktiga AAAA-överskrivningen, återställ en nåbar uppsättning svar och korrigera annonseringen av resolvern samt IPv6-routningen innan du aktiverar den igen. Utöka inte behörigheter, radera inte källdata, försvaga inte transportsäkerheten och ersätt inte fungerande lagring förrän en reproducerbar observation har identifierat vilken gräns som brast.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Behåll designen först efter en återställningsklar kontroll

Tillämpa endast den åtgärd som motsvarar den observerade grenen och kör sedan den ursprungliga arbetsbelastningen igen. Behåll designen endast när varje nätverk får den avsedda adressfamiljen och når samma certifikatförsedda tjänst utan offentlig hairpinning under två relevanta livscykelcykler och vid den förväntade samtidiga belastningen.

Använd split-horizon DNS för att verifiera det närmast beroende arbetsflödet. Dess åtkomst-, tids- och återställningsbeteende måste förbli oförändrat medan den nya designen är aktiv.

Avbryt och återgå till det sparade tillståndet om AAAA läcker en offentlig eller inaktuell adress, klienter använder krypterad extern DNS eller IPv6-routning och brandväggspolicy inte stämmer överens med svaret. Eskalera med tidsstämplar, exakta versioner, bevis från rutter eller monteringar och den minsta reproduktionen i stället för att lägga till ännu en tillfällig lösning.

Jämför resultatet med IPv6-brandväggsreglerna så att risken inte bara flyttas till ett annat nätverks-, identitets-, säkerhetskopierings- eller lagringslager.

För dual-stack split DNS är det kvalificerade svaret därför den inledande bedömningen - inte ett ovillkorligt ja. Det observerbara godkända tillståndet är acceptansgränsen; det underkända tillståndet är återställningsgränsen.