Jo VPN stjoert trije DNS-tsjinners: hokker antwurdet?

Iepenje nei it ferbinen de ynstellingsside en der steane trije DNS-adressen; de fraach fan ’e audit is hokker ien jo lêste fraach ôfhannele. It oantal allinnich antwurdet neat, omdat in klantstjit, in fysike ynterface en in belied per domein allegear yn deselde werjeft skriuwe. Dy ynfieringen drage ferskate beriken, en it berik, net de posysje, beslút wa’t antwurdet. Begjin mei it skieden fan ’e boarnen en test dan dyjinge dy’t de namme hat dy’t jo oanbelanget.

Wêrom de list langer is as jo profyl

In VPN-klant stjoert resolveradressen foar de tunnelkeppeling, en it bestjoeringssysteem hâldt se njonken wat de fysike ynterface al hie. In router, in bedriuws-DHCP-liening, in twadde VPN en in belied per domein drage elk har eigen ynfiering by. Trije adressen op ’e side kinne dêrom trije beriken betsjutte yn stee fan trije kandidaten foar ien taak. It oantal as bewiis fan in lek lêze is de earste flater yn dizze audit.

Binnen ien ynterface besiket in klant syn tsjinners wol op folchoarder, dus in oardere list is net sinleas. Wat gjin wachtrige is, is de gearfoege werjeft, dêr’t ynfieringen fan it profyl, de fysike keppeling en regels per domein njonken elkoar steane sûnder ien rangskikking. Dat ferskil beslút wat jo teste: folchoarder ferklearret gedrach binnen ien berik, en berik ferklearret al it oare.

Fersifere DNS brekt it byld fan binnen in applikaasje. In browser of chatklant mei syn eigen DNS-over-HTTPS-resolver stjoert fragen folslein bûten de list fan it bestjoeringssysteem, dus de adressen op ’e ynstellingsside beskriuwe ferkear dat de applikaasje nea opwekte. Kontrolearje de eigen resolverynstelling fan ’e applikaasje foardat jo it profyl de skuld jouwe fan in namme dy’t ferkeard kaam.

Wat elk fan ’e trije kontrôles seit

Elke boarne lit syn spoar op in oar plak efter en gjin inkeld kommando lit se allegear sjen. Dit is de mapping dy’t de muoite wurdich is om njonken de ynstellingsside te hâlden:

Op in systeem dat systemd-resolved brûkt, is resolvectl status gesachhawwend, omdat it DNS per keppeling rapportearret tegearre mei de rûtedomeinen. macOS antwurdet fia scutil --dns, dat berikresolvers listet yn ’e folchoarder dêr’t se besocht wurde. Windows splitst de twa helten: Get-DnsClientServerAddress foar tsjinners per ynterface en Get-DnsClientNrptPolicy foar de efterheakselregels. Fier it kommando út dat heart by de resolver dy’t feitlik brûkt wurdt, want in masine mei in container-runtime en in buroblêdresolver kin mear as ien ynstallearre hawwe.

In reserveresolver dy’t jo sône net antwurdzje kin

In twadde ynfiering is der meastentiids foar beskikberens, en beskikberens wurket allinnich as de reserve de nammen ken. Freegje in iepenbiere resolver om in ynterne hostnamme en hy jout NXDOMAIN werom, of in wildcard-antwurd út in sykdomein dat neat mei jo te meitsjen hat. In failover dy’t nimmen kontrolearre hat, soarget dan foar in steuring krekt op it momint dat er nedich is.

Split DNS bestiet om dat foar te kommen: bedriuwsachterheaksels geane nei in resolver dy’t de sône hat, en iepenbiere nammen bliuwe op it standertpaad. It ûntwerp is goed, en it hinget ôf fan ’e folsleinens fan ’e efterheaksel list. Microsoft dokumintearret it resolverbelied per efterheaksel dat dit op Windows dryst, en itselde idee ferskynt as rûtedomeinen yn systemd-resolved en as berikresolvers op macOS.

Fergelykje de sônes dêr’t de reserve antwurd op jaan mei mei de efterheaksels yn it belied. Dy fergeliking fynt it gat foardat in brûker meldt dat ien ynterne side nei in tunnelferoaring opholden is mei oplossen.

Freegje troch it belied, net deromhinne

Freegje troch de resolver fan it bestjoeringssysteem, want in direkte fraach oan in tsjinner giet om it belied hinne en rapportearret allinnich wat dy tsjinner sizze soe. It gat tusken de beide antwurden is it hiele punt:

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

As de systeemfraach in privee adres weromjout wylst de direkte fraach NXDOMAIN weromjout, wurket it belied en is de reserve it swakke punt. As beide itselde iepenbiere antwurd weromjouwe, wurdt de namme bûten it bedoelde berik oplost, en de efterheaksel list is it plak om te sykjen. Bewarje beide útfieringen, want in resolverdiskúsje wurdt flugger besljochte mei twa rigels as mei in skermôfbylding fan ’e ynstellingsside.

Oefenje dan it flaterpaad, want in reserve dy’t nimmen test hat is in oanname. Meitsje de foarkarresolver foar ien fraach in swart gat en sjoch hokker adres weromkomt:

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

Wiskje dy rûte sa gau as de fraach dien is, oars erft de folgjende persoan in riedsel. As ynterne nammen yn dat finster noch oplost wurde, hat eat bûten it bedoelde berik se beantwurde. As se ynstee ferrinne, ûntbrekt de reserve of is er korrekt begrinzge, en it eigen logboek fan ’e resolver fertelt jo hokker fan de twa it wie.

Beslút: hâlde, begrinzgje of ferwiderje

Hâld in twadde resolver as er de nammeromte antwurdet dy’t jo nedich hawwe en ûnder it profyl berikber bliuwt. Begrinzgje him as er ien efterheaksel en neat oars sjen moat, en ferwiderje him as er noch in berik noch in dokumintearre doel hat. In ynfiering sûnder taak is in takomstige lek sûnder foardiel, en in leveransierstandert is gjin doel.

Registrearje de útkomst as fjouwer kolommen: efterheaksel, resolver, ynterface en eigner. Dy rigel antwurdet flugger op ’e folgjende auditfraach as hokker skermôfbylding dan ek, en hy oerlibbet de klantupdate dy’t de list stil omskiktet.