macOS-resolverfil for et lokalt domene ved siden av en VPN

Arbeids-VPN-en din løser firmanavn perfekt mens skriveren hjemme forblir utilgjengelig ved navn, og den vanlige løsningen folk griper til er å peke hele Macen mot hjemmeruteren. Det er en mye større endring enn problemet krever. macOS kan sende ett enkelt DNS-suffiks til sin egen server gjennom en liten resolverfil, og la hvert annet oppslag bli nøyaktig der det var.

Tillatelsesgrensen kommer først: dette er for et domene du administrerer eller har fått myndighet til å konfigurere. Det er ikke en vei rundt en organisasjons påtvungne DNS-policy eller dens begrensninger i det lokale nettverket.

Én fil med en smal oppgave

Anta at den lokale sonen er lab.example.org og at serveren svarer på 192.168.55.1. På en Mac der du har lov til å gjøre endringen, oppretter en administrator en ren tekstfil som heter domenet selv, /etc/resolver/lab.example.org, med én enkelt nameserver 192.168.55.1-linje. Katalogen finnes kanskje ikke på et nytt system, så opprett den med administratorrettigheter, og se etter før du skriver i tilfelle administrasjonsprogramvare allerede eier en fil der.

Apples dokumentasjon for resolverkonfigurasjon beskriver konvensjonen at filnavnet gir domenet når ingen egen domeneinnstilling vises inne i filen. Den navneregelen er hele trikset, og det er derfor filen må hete etter sonen og ikke etter serveren.

Hvordan macOS velger blant resolvere

Mer enn én resolverklient kan være aktiv, og det mest spesifikke samsvarende domenet vinner. En resolver for lab.example.org har derfor et annet omfang enn standardresolveren, og et mer spesifikt subdomene med sin egen fil kan igjen ta forrang. Det er dette som lar en arbeids-VPN beholde sitt eget suffiks mens labsone din går et annet sted. Ingenting ved ordningen er globalt, og det er poenget som er verdt å huske.

La /etc/resolv.conf være i fred. macOS skriver den filen selv, og den har aldri holdt hele bildet av domenespesifikk oppløsning. Konfigurasjon kan også komme fra systemets konfigurasjonsdatabase i stedet for fra filer i denne katalogen, og det er derfor en administrasjonsprofil kan overstyre det du skrev.

Tre ting filen ikke kan levere

Serveren må være nåbar. Hvis VPN-en blokkerer lokalt nettverk, eller en bedriftsrute fanger opp serverens adresseområde, kan en helt korrekt suffiksfil fortsatt ikke levere en spørring. Ta det til nettverkseieren i stedet for å utvide lokale unntak på egen hånd.

Sonen må inneholde det riktige svaret, og det testes best med et fullt kvalifisert navn som printer.lab.example.org. Et kort navn kan utløse søkedomeneatferd og ende med å stille et annet spørsmål enn det du mente å stille.

Til slutt må applikasjonen kunne bruke svaret. Å løse et skrivernavn gir ikke tilgang til adressen, og det åpner ikke tjenesten bak den. Den returnerte adressen trenger fortsatt en tillatt rute og en tilgangspolicy som tillater tilkoblingen. En resolverfil endrer hvor et navn slås opp; den reserverer ikke en vei for resultatet.

Verifiser valget i stedet for å bytte ut DNS

Sjekk hva macOS faktisk bruker akkurat nå, og spør etter det fullt kvalifiserte navnet fra inne i applikasjonen selv eller fra et verktøy som løser på samme måte som applikasjoner. En direkte spørring til 192.168.55.1 beviser at serveren svarer; det beviser ikke at macOS valgte den serveren for vanlige oppslag. Det er forskjellige fakta, og bare det andre beskriver det nettleseren din vil oppleve.

Hvis en annen resolver allerede gjør krav på samme suffiks, finn ut hvem som eier det før du legger til prioritetshint. Den dokumenterte innstillingen search_order ordner klienter som deler et domene; den er ikke en global preferansebryter som gjør at en generell resolver vinner hver spørring.

Bekreft at firmanavn fortsatt løses med VPN-en tilkoblet, og noter deretter filen og formålet i dine lokale notater. Når ordningen avvikles, slett bare den filen og kontroller begge navnerommene på nytt i stedet for å tilbakestille alle DNS-innstillinger for nettverket.