WireGuard-DNS op iPhone: het domein is alleen een zoeksuffix

Je schrijft één regel met een resolveradres en een bedrijfsdomein, in de verwachting dat alleen namen in dat domein de tunnelresolver gebruiken. Op de Apple-client gaan nu alle namen daarheen, en korte namen in het domein worden ook opgelost. De regel doet twee afzonderlijke dingen, en slechts één ervan gaat over welke queries de tunnel afhandelt. Het andere is een typgemak dat door wensdenken tot beleid is verheven.

Waar de DNS-regel in wordt geparseerd

De client leest de invoer als een lijst en classificeert elk item op vorm. Alles wat op een adres lijkt, wordt een DNS-server; alles wat op een domein lijkt, wordt een zoeksuffix. Beide belanden in de tunnelinstellingen, maar in verschillende velden. Een voorbeeldregel voor een tunnel met een private resolver en één intern domein ziet er zo uit.

DNS = 10.24.8.53, lab.internal.example

Het adres levert de resolver. Het domein levert een suffix waarmee een client een korte naam kan typen en het systeem de rest aanvult voordat het vraagt. Geen van beide zegt iets over het beperken van de resolver tot dat domein, en dat is precies het deel dat mensen verwachten en niet krijgen. Slechts één veld op het platform kan die beperking uitdrukken, en dat is niet dit veld.

Twee Apple-velden, twee verschillende taken

Apple maakt het onderscheid zichtbaar in zijn DNS-instellingenobject. De zoekdomeinenlijst is gedocumenteerd als de lijst die wordt gebruikt om hostnamen met één label te kwalificeren: typ een kale hostnaam en het systeem kan elk suffix om de beurt toevoegen. Dat is een aanvullingsregel, geen routeringsregel. Niets in die lijst bepaalt welke server wordt gevraagd.

De matchdomeinenlijst is een andere eigenschap. Die bepaalt welke naamruimten deze set DNS-instellingen gebruiken, en een lege vermelding betekent het standaarddomein en niet één specifiek suffix. generator voor pakkettunnelinstellingen op de Apple-client volgt dat model. Het plaatst geparseerde zoeksuffixen in de zoeklijst, en wanneer er servers zijn, zet het de matchlijst op de lege string. Het resultaat is een tunnelresolver die alles beantwoordt wat het systeem hem stuurt, plus een suffix dat helpt bij korte namen.

Een domein op die regel is dus geen naamruimteselector. Nog een toevoegen vernauwt niet welke queries de tunnel gebruikt, en het verwijderen verbreedt ze ook niet. Het enige dat verandert, is hoeveel korte namen worden aangevuld.

Waarom elke naam toch de tunnelresolver bereikt

Met de lege matchvermelding is de tunnel een kandidaat-resolver voor gewone namen, niet alleen voor het bedrijfsdomein. Bij een fulltunnelconfiguratie maakt dat meestal weinig uit, omdat al het verkeer toch in de tunnel zit. Bij een gesplitste tunnel maakt dat veel uit. Openbare namen kunnen nu worden opgelost door een resolver die alleen een private zone heeft, en een storing ziet eruit als een kapotte VPN terwijl het eigenlijk een resolver is die slechts een deel van de naamruimte beantwoordt. De tunnel is in orde, de queries gaan naar buiten, en de antwoorden komen leeg terug.

Er zijn twee oplossingen en het zijn verschillende beslissingen. Maak de tunnelresolver een volledige resolver die openbare namen via het goedgekeurde pad doorstuurt, of stop met het sturen van openbare namen daarheen door de clientconfiguratie te wijzigen in plaats van de domeinenlijst. De eerste houdt elke query op de tunnel en vertrouwt de upstream. De tweede houdt sommige queries lokaal en accepteert dat private namen mogelijk niet meer worden opgelost zolang de tunnel uit staat.

Wat gesplitste DNS echt nodig zou hebben

Een resolverbeleid dat tot een naamruimte beperkt is, vereist een client die je het laat uitdrukken: laat domeinen overeenkomen op Apple-platforms, of een gelijkwaardige instelling in het product dat je gebruikt. Een configuratieveld dat alleen servers en suffixes accepteert, kan het niet uitdrukken, hoe het ook wordt geïnterpungeerd. Een profiel kan het beleid dragen omdat het een beheerde configuratie beschrijft en geen hint op het moment van verbinden. Het kan het domein, de servers en wat er moet gebeuren als dat domein onbereikbaar is, benoemen. Dat is het verschil tussen een instelling en een contract.

Op beheerde Apple-apparaten wordt dit meestal geleverd via een configuratieprofiel dat de domeinspecifieke DNS-instellingen bevat. Dat is een ander mechanisme dan een WireGuard-configuratiebestand, en de twee kunnen alleen naast elkaar bestaan als de client het profiel respecteert. Controleer hoe je client het veld werkelijk noemt voordat je aanneemt dat de twee producten zich hetzelfde gedragen. Een script met wg-quick op een Mac en de WireGuard-app op een iPhone lezen vergelijkbare regels en installeren ze via verschillende lagen.

Lees de geïnstalleerde instellingen, niet de configuratie

Op een Mac kun je inspecteren waar het systeem op uitkwam, wat informatiever is dan het bestand dat je schreef opnieuw lezen. De resolverlijst toont welke servers voor welke domeinen zijn geconfigureerd, en de afgebakende queries tonen welke gewonnen heeft. Een client die de regel verprutst, toont dat hier in plaats van in het bestand dat je schreef. Op iOS is er geen equivalente opdrachtregel, dus het bewijs daar is een resultaat: een private naam die via de tunnel wordt opgelost, en een openbare naam waarvan het antwoord verraadt welke resolver heeft geantwoord.

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

Deze twee opdrachten drukken de huidige resolverconfiguratie en de DNS-servers voor de actieve dienst af. Als de tunnelresolver als standaardresolver zonder domeinbeperking verschijnt, doet de configuratie precies wat de client vroeg. Los dat op door het mechanisme te wijzigen, niet door een tweede suffix toe te voegen en te hopen dat het gedrag verandert.