macOS-resolverfil för en lokal domän bredvid en VPN

Ditt arbets-VPN löser företagsnamn perfekt medan skrivaren hemma förblir onåbar via namn, och den vanliga åtgärden folk tar till är att peka hela Macen mot hemroutern. Det är en mycket större förändring än problemet kräver. macOS kan skicka ett enda DNS-suffix till sin egen server genom en liten resolverfil och låta varje annan uppslagning bli exakt där den var.

Behörighetsgränsen kommer först: detta gäller en domän som du administrerar eller har behörighet att konfigurera. Det är inte en väg runt en organisations påtvingade DNS-policy eller dess begränsningar i det lokala nätverket.

En fil med en snäv uppgift

Anta att den lokala zonen är lab.example.org och att servern svarar på 192.168.55.1. På en Mac där du får göra ändringen skapar en administratör en vanlig textfil med domänen själv som namn, /etc/resolver/lab.example.org, innehållande en enda rad nameserver 192.168.55.1. Katalogen kanske inte finns på ett nytt system, så skapa den med administratörsrättigheter och titta innan du skriver ifall hanteringsprogramvara redan äger en fil där.

Apples dokumentation för resolverkonfiguration beskriver konventionen att filnamnet anger domänen när ingen separat domäninställning finns inuti filen. Den namnregeln är hela tricket, och det är därför filen måste heta efter zonen och inte efter servern.

Hur macOS väljer bland resolvers

Mer än en resolverklient kan vara aktiv, och den mest specifika matchande domänen vinner. En resolver för lab.example.org har därför en annan omfattning än standardresolvern, och en mer specifik underdomän med egen fil kan återigen få företräde. Det är detta som låter ett arbets-VPN behålla sitt eget suffix medan din labbzon går någon annanstans. Inget i arrangemanget är globalt, och det är poängen som är värd att komma ihåg.

Låt /etc/resolv.conf vara i fred. macOS skriver den filen själv, och den har aldrig innehållit hela bilden av domänspecifik uppslagning. Konfiguration kan också komma från systemets konfigurationsdatabas i stället för från filer i den här katalogen, och därför kan en hanteringsprofil skriva över det du skrev.

Tre saker som filen inte kan tillhandahålla

Servern måste vara nåbar. Om VPN:en blockerar lokalt nätverk, eller en företagsrutt fångar upp serverns adressintervall, kan en helt korrekt suffixfil ändå inte leverera en fråga. Ta det till nätverksägaren i stället för att själv vidga lokala undantag.

Zonen måste innehålla rätt svar, och det testas bäst med ett fullständigt kvalificerat namn som printer.lab.example.org. Ett kort namn kan utlösa sökdomänbeteende och till slut ställa en annan fråga än den du menade.

Slutligen måste programmet kunna använda svaret. Att lösa en skrivares namn ger ingen åtkomst till dess adress, och det öppnar inte tjänsten bakom den. Den returnerade adressen behöver fortfarande en tillåten rutt och en åtkomstpolicy som tillåter anslutningen. En resolverfil ändrar var ett namn slås upp; den reserverar inte en väg för resultatet.

Verifiera urvalet i stället för att byta ut DNS

Kontrollera vad macOS faktiskt använder just nu, och fråga efter det fullständiga kvalificerade namnet inifrån själva programmet eller från ett verktyg som löser på samma sätt som program gör. En direkt fråga till 192.168.55.1 bevisar att servern svarar; den bevisar inte att macOS valde den servern för vanliga uppslagningar. Det är olika fakta, och bara det andra beskriver vad din webbläsare kommer att uppleva.

Om en annan resolver redan gör anspråk på samma suffix, ta reda på vem som äger det innan du lägger till prioritetstips. Den dokumenterade inställningen search_order ordnar klienter som delar en domän; den är inte en global preferensbrytare som gör att en allmän resolver vinner varje fråga.

Bekräfta att företagsnamn fortfarande löses med VPN:en ansluten, och anteckna sedan filen och dess syfte i dina lokala anteckningar. När arrangemanget avvecklas, radera bara den filen och kontrollera båda namnrymderna igen i stället för att återställa alla nätverkets DNS-inställningar.