WireGuard-DNS op iPhone: die domein is net ’n soek-agtervoegsel

Jy skryf een reël met ’n resolver-adres en ’n maatskappydomein, en verwag dat net name in daardie domein die tonnel-resolver sal gebruik. Op die Apple-kliënt gaan alle name nou daarheen, en kort name in die domein word ook opgelos. Die reël doen twee afsonderlike dinge, en net een daarvan gaan oor watter navrae die tonnel hanteer. Die ander een is ’n tikgerief wat deur wensdenkery tot ’n beleid bevorder is.

Waar die DNS-reël ontleed word

Die kliënt lees die inskrywing as ’n lys en klassifiseer elke item volgens vorm. Enigiets wat soos ’n adres lyk, word ’n DNS-bediener; enigiets wat soos ’n domein lyk, word ’n soek-agtervoegsel. Albei beland in die tonnel-instellings, maar in verskillende velde. ’n Voorbeeldlyn vir ’n tonnel wat ’n private resolver en een interne domein dra, lyk so.

DNS = 10.24.8.53, lab.internal.example

Die adres voorsien die resolver. Die domein voorsien ’n agtervoegsel wat ’n kliënt in staat stel om ’n kort naam te tik en die stelsel die res te laat byvoeg voordat dit vra. Nie een van die twee sê iets daaroor om die resolver tot daardie domein te beperk nie, en dit is juis die deel wat mense verwag en nie kry nie. Net een veld in die platform kan daardie beperking uitdruk, en dit is nie hierdie een nie.

Twee Apple-velde, twee verskillende take

Apple stel die onderskeid in sy DNS-instellingsvoorwerp bloot. Die soekdomein-lys word gedokumenteer as die lys wat gebruik word om enkel-etiket-gasheername te kwalifiseer: tik ’n kaal gasheernaam en die stelsel kan elke agtervoegsel op sy beurt byvoeg. Dit is ’n voltooiingsreël, nie ’n roeteringsreël nie. Niks in daardie lys besluit watter bediener gevra word nie.

Die pasdomein-lys is ’n ander eienskap. Dit besluit watter naamruimtes hierdie stel DNS-instellings gebruik, en ’n leë inskrywing beteken die verstekdomein eerder as een spesifieke agtervoegsel. pakkettonnel-instellingsgenerator in die Apple-kliënt volg daardie model. Dit plaas ontlede soek-agtervoegsels in die soeklys, en wanneer bedieners teenwoordig is, stel dit die paslys op die leë string. Die resultaat is ’n tonnel-resolver wat alles antwoord wat die stelsel vir hom stuur, plus ’n agtervoegsel wat met kort name help.

Dus is ’n domein op daardie lyn nie ’n naamruimte-keurder nie. Om nog een by te voeg, vernou nie watter navrae die tonnel gebruik nie, en om dit te verwyder, verbreed dit ook nie. Die enigste ding wat verander, is hoeveel kort name voltooi word.

Waarom elke naam steeds die tonnel-resolver bereik

Met die leë pasinskrywing is die tonnel ’n kandidaat-resolver vir gewone name, nie net vir die maatskappydomein nie. Op ’n volledige tonnel-konfigurasie maak dit gewoonlik min saak, want alle verkeer is in elk geval in die tonnel. Op ’n gesplete tonnel maak dit baie saak. Openbare name kan nou opgelos word deur ’n resolver wat net ’n private sone hou, en ’n mislukking lyk soos ’n stukkende VPN wanneer dit eintlik ’n resolver is wat net ’n deel van die naamruimte antwoord. Die tonnel is reg, die navrae verlaat dit, en die antwoorde kom leeg terug.

Twee herstellings is beskikbaar, en dit is verskillende besluite. Maak die tonnel-resolver ’n volledige resolver wat openbare name deur die goedgekeurde pad stuur, of stop om openbare name daarheen te stuur deur die kliëntkonfigurasie eerder as die domeinlys te verander. Die eerste hou elke navraag op die tonnel en vertrou die opstroom. Die tweede hou sommige navrae plaaslik en aanvaar dat private name kan ophou opgelos word terwyl die tonnel af is.

Wat gesplete DNS eintlik nodig sou hê

’n Naamruimte-gebonde resolver-beleid vereis ’n kliënt wat jou dit laat uitdruk: pas domeine op Apple-platforms aan, of ’n gelykwaardige instelling in die produk wat jy gebruik. ’n Konfigurasieveld wat net bedieners en agtervoegsels aanvaar, kan dit nie uitdruk nie, maak nie saak hoe dit gepunktueer is nie. ’n Profiel kan die beleid dra, want dit beskryf ’n bestuurde konfigurasie eerder as ’n verbindingstyd-wenk. Dit kan die domein, die bedieners en wat moet gebeur wanneer daardie domein onbereikbaar is, noem. Dit is die verskil tussen ’n instelling en ’n kontrak.

Op bestuurde Apple-toestelle word dit gewoonlik gelewer deur ’n konfigurasieprofiel wat die domeinspesifieke DNS-instellings dra. Dit is ’n ander meganisme as ’n WireGuard-konfigurasielêer, en die twee kan net saam bestaan as die kliënt die profiel respekteer. Kyk wat jou kliënt die veld werklik noem voordat jy aanvaar dat die twee produkte dieselfde optree. ’n Skrip met wg-quick op ’n Mac en die WireGuard-app op ’n iPhone lees soortgelyke reëls en installeer dit deur verskillende lae.

Lees die geïnstalleerde instellings, nie die konfigurasie nie

Op ’n Mac kan jy inspekteer waarmee die stelsel geëindig het, wat meer insiggewend is as om die lêer wat jy geskryf het weer te lees. Die resolver-lys wys watter bedieners vir watter domeine gekonfigureer is, en die skopnavrae wys watter een gewen het. ’n Kliënt wat die lyn vermink, wys dit hier eerder as in die lêer wat jy geskryf het. Op iOS is daar geen ekwivalente opdragreël nie, so die bewys daar is ’n uitkoms: ’n private naam wat deur die tonnel opgelos word, en ’n openbare naam wie se antwoord verraai watter resolver geantwoord het.

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

Hierdie twee opdragte druk die huidige resolver-konfigurasie en die DNS-bediener vir die aktiewe diens. As die tonnel-resolver as ’n verstek-resolver sonder domeinbeperking verskyn, doen die konfigurasie presies wat die kliënt gevra het. Herstel dit deur die meganisme te verander, nie deur ’n tweede agtervoegsel by te voeg en te hoop die gedrag verander nie.