WireGuard-DNS på iPhone: domänen är bara ett söksuffix

Du skriver en rad med en resolveradress och en företagsdomän, och förväntar dig att bara namn i den domänen använder tunnelns resolver. På Apple-klienten går alla namn nu dit, och korta namn i domänen löses också. Raden gör två separata saker, och bara en av dem handlar om vilka frågor tunneln hanterar. Den andra är en skrivhjälp som av önsketänkande upphöjts till policy.

Vad DNS-raden parsas till

Klienten läser posten som en lista och klassificerar varje objekt efter form. Allt som ser ut som en adress blir en DNS-server; allt som ser ut som en domän blir ett söksuffix. Båda hamnar i tunnelinställningarna, men i olika fält. En illustrativ rad för en tunnel som bär en privat resolver och en intern domän ser ut så här.

DNS = 10.24.8.53, lab.internal.example

Adressen tillhandahåller resolvern. Domänen tillhandahåller ett suffix som låter klienten skriva ett kort namn och systemet lägga till resten innan det frågar. Ingen av dem säger något om att begränsa resolvern till den domänen, och det är just den delen folk förväntar sig och inte får. Bara ett fält på plattformen kan uttrycka den begränsningen, och det är inte det här fältet.

Två Apple-fält, två olika jobb

Apple visar skillnaden i sitt DNS-inställningsobjekt. Sökdomänlistan är dokumenterad som listan som används för att kvalificera värdnamn med en etikett: skriv ett bart värdnamn och systemet kan lägga till varje suffix i tur och ordning. Det är en kompletteringsregel, inte en routingregel. Inget på den listan avgör vilken server som tillfrågas.

Matchningsdomänlistan är en annan egenskap. Den avgör vilka namnrymder som använder den här uppsättningen DNS-inställningar, och en tom post betyder standarddomänen snarare än ett specifikt suffix. generator för pakettunnelinställningar på Apple-klienten följer den modellen. Den lägger parsade söksuffix i söklistan, och när det finns servrar sätter den matchningslistan till den tomma strängen. Resultatet är en tunnelresolver som svarar på allt systemet skickar till den, plus ett suffix som hjälper till med korta namn.

Så en domän på den raden är inte en namnrymdsväljare. Att lägga till en till begränsar inte vilka frågor tunneln använder, och att ta bort den utökar dem inte heller. Det enda som ändras är hur många korta namn som fylls ut.

Varför varje namn ändå når tunnelns resolver

Med den tomma matchningsposten är tunneln en kandidatresolver för vanliga namn, inte bara för företagets domän. I en fulltunnelkonfiguration spelar det oftast liten roll, eftersom all trafik ändå är i tunneln. I en delad tunnel spelar det stor roll. Offentliga namn kan nu lösas av en resolver som bara har en privat zon, och ett fel ser ut som en trasig VPN när det egentligen är en resolver som bara svarar på en del av namnrymden. Tunneln är okej, frågorna går ut, och svaren kommer tillbaka tomma.

Det finns två åtgärder och de är olika beslut. Gör tunnelns resolver till en komplett resolver som vidarebefordrar offentliga namn via den godkända vägen, eller sluta skicka offentliga namn dit genom att ändra klientkonfigurationen i stället för domänlistan. Den första håller varje fråga på tunneln och litar på uppströms. Den andra håller vissa frågor lokalt och accepterar att privata namn kan sluta lösas medan tunneln är nere.

Vad delad DNS egentligen skulle kräva

En resolverpolicy begränsad till en namnrymd kräver en klient som låter dig uttrycka den: matcha domäner på Apple-plattformar, eller en motsvarande inställning i produkten du använder. Ett konfigurationsfält som bara accepterar servrar och suffix kan inte uttrycka det, hur det än teckensätts. En profil kan bära policyn eftersom den beskriver en hanterad konfiguration och inte en ledtråd vid anslutning. Den kan namnge domänen, servrarna och vad som ska hända när den domänen inte är nåbar. Det är skillnaden mellan en inställning och ett avtal.

På hanterade Apple-enheter levereras detta vanligtvis via en konfigurationsprofil som bär de domänspecifika DNS-inställningarna. Det är en annan mekanism än en WireGuard-konfigurationsfil, och de två kan bara samexistera om klienten respekterar profilen. Kontrollera vad din klient faktiskt kallar fältet innan du antar att de två produkterna beter sig likadant. Ett skript med wg-quick på en Mac och WireGuard-appen på en iPhone läser liknande rader och installerar dem genom olika lager.

Läs de installerade inställningarna, inte konfigurationen

På en Mac kan du undersöka vad systemet slutade med, vilket är mer informativt än att läsa filen du skrev igen. Resolverlistan visar vilka servrar som är konfigurerade för vilka domäner, och de avgränsade frågorna visar vilken som vann. En klient som förstör raden visar det här i stället för i filen du skrev. På iOS finns ingen motsvarande kommandorad, så beviset där är ett resultat: ett privat namn som löses genom tunneln, och ett offentligt namn vars svar avslöjar vilken resolver som svarade.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

De här två kommandona skriver ut den aktuella resolverkonfigurationen och DNS-servrarna för den aktiva tjänsten. Om tunnelns resolver visas som standardresolver utan domänbegränsning gör konfigurationen exakt det klienten bad om. Åtgärda det genom att ändra mekanismen, inte genom att lägga till ett andra suffix och hoppas att beteendet ändras.