Jou VPN stuur drie DNS-bedieners: watter een antwoord?

Maak die instellingsbladsy oop nadat jy gekoppel het, en drie DNS-adresse word gelys; die ouditvraag is watter een jou laaste navraag hanteer het. Die aantal alleen antwoord niks, want ’n kliënt-stoot, ’n fisiese koppelvlak en ’n domein-spesifieke beleid skryf almal in dieselfde aansig. Daardie inskrywings dra verskillende omvange, en omvang eerder as posisie bepaal wie antwoord. Begin deur die bronne te skei en toets dan die een wat die naam besit waarvoor jy omgee.

Waarom die lys langer is as jou profiel

’n VPN-kliënt stoot oplosseradresse vir die tonnelskakel, en die bedryfstelsel hou hulle langs wat die fisiese koppelvlak reeds gehad het. ’n Roeteerder, ’n korporatiewe DHCP-leasing, ’n tweede VPN en ’n domein-spesifieke beleid dra elkeen ’n eie inskrywing by. Drie adresse op die bladsy kan dus drie omvange beteken eerder as drie kandidate vir een taak. Om die aantal as bewyse van ’n lek te lees, is die eerste fout in hierdie oudit.

Binne een koppelvlak probeer ’n kliënt wel sy bedieners in volgorde, so ’n geordende lys is nie betekenisloos nie. Wat nie ’n tou is nie, is die saamgevoegde aansig, waar inskrywings van die profiel, die fisiese skakel en domein-spesifieke reëls sonder een rangorde langs mekaar staan. Daardie onderskeid bepaal wat jy toets: volgorde verduidelik gedrag binne een omvang, en omvang verduidelik al die res.

Geënkripteerde DNS breek die prentjie van binne ’n toepassing. ’n Blaaier of ’n kletskliënt met sy eie DNS-over-HTTPS-oplosser stuur navrae heeltemal verby die bedryfstelsel se lys, so die adresse op die instellingsbladsy beskryf verkeer wat die app nooit gegenereer het nie. Kontroleer die app se eie oplosserinstelling voordat jy die profiel blameer vir ’n naam wat verkeerd uitgekom het.

Wat elke een van die drie kontroles vir jou sê

Elke bron laat sy merk op ’n ander plek, en geen enkele opdrag wys almal nie. Dit is die kartering wat langs die instellingsbladsy gehou moet word:

Op ’n stelsel wat systemd-resolved gebruik, is resolvectl status gesaghebbend, want dit rapporteer DNS per skakel saam met die roeteringsdomeine. macOS antwoord deur scutil --dns, wat omvang-oplossers lys in die volgorde waarin hulle probeer word. Windows splits die twee helftes: Get-DnsClientServerAddress vir per-koppelvlak-bedieners en Get-DnsClientNrptPolicy vir die agtervoegselreëls. Voer die opdrag uit wat by die oplosser hoort wat werklik in gebruik is, want ’n masjien met ’n houerruntime en ’n lessenaar-oplosser kan meer as een geïnstalleer hê.

’n Rugsteun-oplosser wat jou sone nie kan antwoord nie

’n Tweede inskrywing is gewoonlik daar vir beskikbaarheid, en beskikbaarheid werk net as die rugsteun die name ken. Vra ’n publieke oplosser vir ’n interne gasheernaam en dit gee NXDOMAIN terug, of ’n wildcard-antwoord van ’n soekdomein wat niks met jou te doen het nie. ’n Oorskakeling wat niemand getoets het nie, veroorsaak dan ’n onderbreking op presies die oomblik wanneer dit nodig is.

Split-DNS bestaan om dit te voorkom: maatskappy-agtervoegsels gaan na ’n oplosser wat die sone hou, en publieke name bly op die verstekpad. Die ontwerp is gesond, en dit hang daarvan af dat die agtervoegsellys volledig is. Microsoft dokumenteer die beleid per agtervoegsel wat dit op Windows aandryf, en dieselfde idee verskyn as roeteringsdomeine in systemd-resolved en as omvang-oplossers op macOS.

Vergelyk die sones wat die rugsteun mag antwoord met die agtervoegsels in die beleid. Daardie vergelyking vind die gaping voordat ’n gebruiker rapporteer dat een interne webwerf ná ’n tonnelverandering opgehou oplos het.

Vra deur die beleid, nie daaromheen nie

Vra deur die bedryfstelsel se oplosser, want ’n direkte navraag aan ’n bediener omseil beleid en rapporteer net wat daardie bediener sou sê. Die gaping tussen die twee antwoorde is die hele punt:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

As die stelselnavraag ’n private adres teruggee terwyl die direkte navraag NXDOMAIN teruggee, werk die beleid en is die rugsteun die swak punt. As albei dieselfde publieke antwoord teruggee, word die naam buite die omvang wat jy bedoel het, opgelos, en die agtervoegsellys is waar om te kyk. Hou albei uitsette, want ’n oplosser-argument word vinniger met twee reëls besleg as met ’n skermkiekie van die instellingsbladsy.

Oefen dan die foutpad, want ’n terugval wat niemand getoets het nie, is ’n aanname. Maak die voorkeur-oplosser vir een navraag ’n swartgat en kyk watter adres terugkom:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Vee daardie roete uit sodra die navraag klaar is, of die volgende persoon erf ’n raaisel. As interne name in daardie venster steeds oplos, het iets buite die bedoelde omvang hulle geantwoord. As hulle eerder uitty, ontbreek die terugval of is dit korrek omvang, en die oplosser se eie log sê vir jou watter van die twee dit was.

Besluit: hou, beperk of verwyder

Hou ’n tweede oplosser wanneer dit die naamruimte antwoord wat jy nodig het en bereikbaar bly onder die profiel. Beperk dit tot een omvang wanneer dit een agtervoegsel en niks anders moet sien, en verwyder dit wanneer dit nóg ’n omvang nóg ’n gedokumenteerde doel het. ’n Inskrywing sonder ’n taak is ’n toekomstige lek sonder voordeel, en ’n verskaffer-verstek is nie ’n doel nie.

Teken die uitkoms as vier kolomme aan: agtervoegsel, oplosser, koppelvlak en eienaar. Daardie reël beantwoord die volgende ouditvraag vinniger as enige skermkiekie, en dit oorleef die kliënt-opdatering wat die lys stilweg herrangskik.