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

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

Tillatelsesgrensen kommer først: dette gjelder et domene du administrerer eller har fått fullmakt til å konfigurere. Det er ingen vei rundt organisasjonens påtvungne DNS-policy eller dens restriksjoner på lokalnettet.

Én fil med en smal oppgave

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

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

Hvordan macOS velger mellom resolvere

Flere 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 få forrang. Det er dette som gjør at en arbeids-VPN kan beholde sitt eget suffiks mens labsonen 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 inneholdt hele bildet av domenespesifikk oppløsning. Konfigurasjon kan også komme fra systemets konfigurasjonsdatabase i stedet for fra filer i denne katalogen, og derfor kan en administrasjonsprofil overstyre det du skrev.

Tre ting filen ikke kan tilby

Tjeneren må være nåbar. Hvis VPN-en blokkerer lokalnett, eller en bedriftsrute fanger opp tjenerens adresseområde, kan en helt korrekt suffiksfil fortsatt ikke levere en spørring. Ta det opp med netteieren i stedet for å utvide lokale unntak selv.

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

Til slutt må applikasjonen kunne bruke svaret. Å løse navnet til en skriver 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.

Bekreft valget i stedet for å bytte ut DNS

Sjekk hva macOS faktisk bruker akkurat nå, og spør etter det fullt kvalifiserte navnet fra applikasjonen selv eller fra et verktøy som løser slik applikasjoner gjør. En direkte spørring mot 192.168.55.1 beviser at tjeneren svarer; det beviser ikke at macOS valgte den tjeneren 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 prioriteringstips. 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 med den i de lokale notatene dine. Når ordningen avvikles, slett bare den filen og kontroller begge navnerommene på nytt i stedet for å tilbakestille alle DNS-innstillingene for nettet.