macOS-resolverbestand voor een lokaal domein naast een VPN
Eén smal resolverbestand kan één lokaal domein naar zijn eigen DNS-server op een Mac sturen, zonder de resolver van de werk-VPN te vervangen of een route aan te maken.
Je werk-VPN lost bedrijfsnamen perfect op, terwijl de printer thuis niet bij naam bereikbaar blijft, en de gebruikelijke oplossing die mensen aangrijpen is de hele Mac naar de thuisrouter wijzen. Dat is een veel grotere wijziging dan het probleem vereist. macOS kan één DNS-suffix via een klein resolverbestand naar zijn eigen server sturen en elke andere opzoeking precies laten waar die was.
De toestemmingsgrens komt eerst: dit is voor een domein dat je beheert of waarvoor je bevoegdheid hebt gekregen om het te configureren. Het is geen weg rond het door een organisatie afgedwongen DNS-beleid of haar beperkingen voor het lokale netwerk.
Eén bestand met een smalle taak
Stel dat de lokale zone lab.example.org is en dat de server antwoordt op 192.168.55.1. Op een Mac waar je de wijziging mag doorvoeren, maakt een beheerder een eenvoudig tekstbestand aan dat naar het domein zelf is vernoemd, /etc/resolver/lab.example.org, met één regel nameserver 192.168.55.1. De map bestaat misschien niet op een vers systeem, dus maak die aan met beheerdersrechten, en kijk voordat je schrijft of beheersoftware er al een bestand bezit.
De resolverconfiguratiedocumentatie van Apple beschrijft de conventie dat de bestandsnaam het domein levert wanneer er geen afzonderlijke domeininstelling in het bestand staat. Die naamgevingsregel is de hele truc, en daarom moet het bestand naar de zone heten en niet naar de server.
Hoe macOS tussen resolvers kiest
Er kan meer dan één resolverclient actief zijn, en het meest specifieke overeenkomende domein wint. Een resolver voor lab.example.org heeft daardoor een ander bereik dan de standaardresolver, en een specifieker subdomein met een eigen bestand kan opnieuw voorrang krijgen. Dat is wat een werk-VPN zijn eigen suffix laat behouden terwijl je labzone ergens anders heen gaat. Niets aan deze regeling is globaal, en dat is het punt dat het onthouden waard is.
Laat /etc/resolv.conf met rust. macOS schrijft dat bestand zelf, en het heeft nooit het volledige beeld van domeinspecifieke resolutie bevat. Configuratie kan ook uit de systeemconfiguratiedatabase komen in plaats van uit bestanden in deze map, en daarom kan een beheerprofiel overschrijven wat je hebt geschreven.
Drie dingen die het bestand niet kan leveren
De server moet bereikbaar zijn. Als de VPN lokale netwerken blokkeert, of een bedrijfsroute het adresbereik van de server opvangt, kan een volkomen correct suffixbestand nog steeds geen query afleveren. Breng dat naar de netwerkeigenaar in plaats van zelf lokale uitzonderingen te verruimen.
De zone moet het juiste antwoord bevatten, en dat test je het beste met een volledig gekwalificeerde naam zoals printer.lab.example.org. Een korte naam kan het gedrag van zoekdomeinen oproepen en uiteindelijk een andere vraag stellen dan je bedoelde.
Ten slotte moet de toepassing het antwoord kunnen gebruiken. Het oplossen van de naam van een printer geeft geen toegang tot het adres, en het opent de dienst erachter niet. Het teruggegeven adres heeft nog steeds een toegestane route en een toegangsbeleid nodig dat de verbinding toestaat. Een resolverbestand verandert waar een naam wordt opgezocht; het reserveert geen pad voor het resultaat.
Controleer de selectie in plaats van DNS te vervangen
Controleer wat macOS op dit moment werkelijk gebruikt, en vraag de volledig gekwalificeerde naam op vanuit de toepassing zelf of vanuit een hulpmiddel dat oplost zoals toepassingen dat doen. Een rechtstreekse query op 192.168.55.1 bewijst dat de server antwoordt; het bewijst niet dat macOS die server voor gewone opzoekingen heeft gekozen. Dat zijn verschillende feiten, en alleen het tweede beschrijft wat je browser zal ervaren.
Als een andere resolver al dezelfde suffix opeist, zoek dan uit wie hem bezit voordat je prioriteitshints toevoegt. De gedocumenteerde instelling search_order ordent clients die een domein delen; het is geen globale voorkeursschakelaar die een algemene resolver elke query laat winnen.
Bevestig dat bedrijfsnamen nog steeds oplossen terwijl de VPN verbonden is, en noteer daarna het bestand en het doel ervan in je lokale notities. Wanneer de regeling wordt opgeheven, verwijder dan alleen dat bestand en controleer beide naamruimten opnieuw in plaats van alle DNS-instellingen van het netwerk te resetten.