WireGuard-DNS op iPhone: it domein is mar in syk-suffiks

Jo skriuwe ien rigel mei in resolveradres en in bedriuwsdomein, en ferwachtsje dat allinnich nammen yn dat domein de resolver fan de tunnel brûke. Op de Apple-klant geane no alle nammen dêrhinne, en koarte nammen yn it domein wurde ek oplost. De rigel docht twa aparte dingen, en mar ien dêrfan giet oer hokker fragen de tunnel behannelet. De oare is in typgemak dat troch winskjen ta belied ferheven is.

Wêryn't de DNS-rigel parst wurdt

De klant lêst de ynfier as in list en klassifisearret elk item nei foarm. Alles dat op in adres liket, wurdt in DNS-tsjinner; alles dat op in domein liket, wurdt in syk-suffiks. Beide einigje yn de tunnelynstellingen, mar yn ferskillende fjilden. In yllustrative rigel foar in tunnel dy't in privee resolver en ien yntern domein draacht, sjocht der sa út.

DNS = 10.24.8.53, lab.internal.example

It adres leveret de resolver. It domein leveret in suffiks wêrmei't in klant in koarte namme typearje kin en it systeem de rest tafoeget foardat it freget. Gjint fan beide seit eat oer it beheinen fan de resolver ta dat domein, en dat is krekt it part dat minsken ferwachtsje en net krije. Mar ien fjild op it platfoarm kin dy beheining útdrukke, en it is net dit fjild.

Twa Apple-fjilden, twa ferskillende taken

Apple lit it ûnderskied sjen yn syn DNS-ynstellingsobject. De sykdomeinlist is dokumintearre as de list dy't brûkt wurdt om hostnammen mei ien label te kwalifisearjen: typ in keale hostnamme en it systeem kin elk suffiks om bar tafoegje. Dat is in foltôgingsregel, gjin routingregel. Neat yn dy list beslút hokker tsjinner frege wurdt.

De meinferdrachdomeinlist is in oare eigenskip. It beslút hokker nammromten dizze set DNS-ynstellingen brûke, en in lege ynfier betsjut it standertdomein ynstee fan ien spesifyk suffiks. generator foar pakket-tunnel-ynstellingen op 'e Apple-klant folget dat model. It set parste syk-suffiksen yn 'e syklist, en as der tsjinners binne, set it de meinferdrachlist op 'e lege string. It resultaat is in tunnelresolver dy't alles beantwurdet wat it systeem him stjoert, plus in suffiks dat helpt by koarte nammen.

Sa is in domein op dy rigel gjin nammromte-kiezer. In oaren tafoegje beheint net hokker fragen de tunnel brûkt, en it fuortheljen ferbreedt se ek net. It iennige dat feroaret is hoefolle koarte nammen foltôge wurde.

Wêrom't elke namme noch altyd de tunnelresolver berikt

Mei de lege meinferdrachynfier is de tunnel in kandidaatresolver foar gewoane nammen, net allinnich foar it bedriuwsdomein. By in folsleine tunnelkonfiguraasje makket dat meastentiids net folle út, omdat al it ferkear dochs yn 'e tunnel sit. By in splitste tunnel makket dat in soad út. Iepenbiere nammen kinne no oplost wurde troch in resolver dy't allinnich in privee sône hat, en in flater liket op in brutsen VPN wylst it eins in resolver is dy't mar in part fan 'e nammromte beantwurdet. De tunnel is goed, de fragen geane fuort, en de antwurden komme leech werom.

Der binne twa reparaasjes beskikber en it binne ferskillende besluten. Meitsje de tunnelresolver in folsleine resolver dy't iepenbiere nammen fia it goedkarde paad trochstjoert, of stopje mei it stjoeren fan iepenbiere nammen dêrhinne troch de klantkonfiguraasje te feroarjen ynstee fan 'e domeinlist. De earste hâldt elke fraach op 'e tunnel en fertrout de upstream. De twadde hâldt guon fragen lokaal en akseptearret dat privee nammen ophâlde kinne mei oplossen wylst de tunnel del is.

Wat splitst DNS eins nedich hawwe soe

In resolverbelied dat ta in nammromte beheind is, freget in klant dy't jo it útdrukke lit: meitsje domeinen oerien op Apple-platfoarmen, of in lykweardige ynstelling yn it produkt dat jo brûke. In konfiguraasjefjild dat allinnich tsjinners en suffiksen akseptearret kin it net útdrukke, hoe't it ek punktuearre is. In profyl kin it belied drage, omdat it in beheard konfiguraasje beskriuwt en gjin hint by it ferbinen. It kin it domein, de tsjinners en wat der barre moat as dat domein net berikber is, beneame. Dat is it ferskil tusken in ynstelling en in kontrakt.

Op beheardere Apple-apparaten wurdt dit meastentiids levere troch in konfiguraasjeprofyl dat de domeinspezifike DNS-ynstellingen draacht. Dat is in oar meganisme as in WireGuard-konfiguraasjefile, en de beide kinne allinnich njonkeninoar bestean as de klant it profyl respektearret. Kontrolearje hoe't jo klant it fjild eins neamt foardat jo oannimme dat de beide produkten itselde dogge. In skript mei wg-quick op in Mac en de WireGuard-app op in iPhone lêze ferlykbere rigels en ynstallearje se fia ferskillende lagen.

Lês de ynstallearre ynstellingen, net de konfiguraasje

Op in Mac kinne jo besjen wêr't it systeem op útkaam is, wat ynformative is as it opnij lêzen fan 'e file dy't jo skreaunen. De resolverlist lit sjen hokker tsjinners foar hokker domeinen konfigurearre binne, en de beheinde fragen litte sjen hokker wûn hat. In klant dy't de rigel skuort, lit dat hjir sjen ynstee fan yn 'e file dy't jo skreaunen. Op iOS is der gjin lykweardige kommandorigel, dus it bewiis dêr is in útkomst: in privee namme dy't fia de tunnel oplost, en in iepenbiere namme wêrfan't it antwurd ferriedt hokker resolver antwurde.

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

Dizze twa kommando's printsje de hjoeddeistige resolverkonfiguraasje en de DNS-tsjinners foar de aktive tsjinst. As de tunnelresolver as standertresolver sûnder domeinbeheining ferskynt, docht de konfiguraasje krekt wat de klant frege hat. Reparearje dat troch it meganisme te feroarjen, net troch in twadde suffiks ta te foegjen en te hoopjen dat it gedrach feroaret.