Split-DNS-vang: sê waar elke waarneming gemaak is

Twee mense doen foutsoek op dieselfde Split-DNS-probleem en kry verskillende resolver-adresse. Een het ’n opsoekgereedskap gebruik, een het pakkies op die adapter vasgelê, en ’n derde het die kliënt se eie diagnostiek gelees. Nie een van hulle lieg nie, en nie een van hulle beskryf dieselfde stadium nie. Om die waarnemingspunt te benoem, verander ’n teenstrydigheid in ’n kaart.

Een opsoektog, verskeie waarnemingspunte

Vir ’n enkele interne naam is daar minstens vyf plekke om te kyk: die toepassing en die resolver-API wat dit aanroep, die effektiewe domeinbeleid op die kliënt, ’n adapter- of filtervaslegging, ’n beheerde deurgangsgrens, en die resolver wat die navraag werklik ontvang.

Elkeen beantwoord ’n ander vraag, en nie een alleen bewys waar die navraag heen gegaan het nie.

’n Adaptervaslegging wys pakkies, nie opset nie. Dit sê nie vir jou watter resolver die kliënt gekies het nie, en ’n leë vaslegging kan ’n gekasde antwoord of ’n ander resolver-API beteken eerder as ’n weggelate pakkie. Behandel elke waarneming as bewyse oor een stadium. Rangskik dan die stadiums in ’n pad.

Die kliënt se filter sit tussen toepassing en netwerkdraad

’n VPN-kliënt met Split-DNS pas domeinpassing toe voordat die pakkie die masjien verlaat. Name in die tonnel-agtervoegsel gaan na die interne resolver; alles anders gaan na die plaaslike een. Die filter is beleid, en beleid kan per platform en kliëntweergawe verskil.

Cisco se Secure Client split-DNS-riglyne dek domeinpassing en die Windows-filter, en dit skei wat ’n toepassing sien wanneer dit die inheemse resolver-API gebruik van wat ’n gereedskap soos nslookup sien. Dié onderskeidings is die punt.

Begin by die effektiewe profiel en een gewone toepassingopsoek. Enige toets wat ’n eksplisiete bediener noem, is ’n doelbewuste ompad; gebruik die kliënt se eie diagnostiek om dit te verduidelik, en moenie toelaat dat dit die aanvaardingskriterium word nie.

nslookup volg ’n ander pad as die toepassing

nslookup bou sy eie DNS-navraag en kan die bedryfstelsel se resolverbeleid omseil. Dit maak dit ’n nuttige gereedskap om ’n spesifieke bediener ’n spesifieke vraag te vra, en ’n misleidende gereedskap om te toets wat ’n toepassing sal ervaar.

Op Windows besluit die naamresolusiebeleidstabel watter agtervoegsel watter bediener gebruik. Om dit te lees wys die beleid wat die toepassing sal volg, en dit is dikwels die ontbrekende stuk.

Lees die beleid en vra dan dieselfde vraag deur die normale resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Geënskripteerde resolvers verberg die navraag, nie die verbinding nie

’n Blaaier met sy eie DNS-over-HTTPS-resolver is ’n heeltemal ander geval. Die navraag verlaat binne TLS, so ’n pakkievaslegging wys ’n verbinding na ’n resolveradres maar nie die naam waarvoor gevra word nie.

Werk eers die blaaier se bestuurde beleid uit, vergelyk dit dan met ’n bedryfstelselopsoek. ’n Blaaier wat toegelaat word om sy eie resolver te kies, sien dalk glad nie die Split-DNS-beleid nie.

Dieselfde waarskuwing geld vir enige kliënt wat sy eie resolver insluit. ’n Vaslegging wat die afgeleë verbinding identifiseer, is nie bewyse oor die navraagnaam nie. As jy die naam nodig het, kry dit uit die resolver se eie logboeke of uit die toepassing se diagnostiek, met die privaatheidsreëls wat geld.

Vergelyk met ’n gemerkte toets

Kies ’n goedgekeurde interne naam vir toetsing, plus ’n publieke naam wat geen sensitiewe betekenis dra nie. Teken vir elkeen die tyd, die rekordtipe, die antwoord en die beleid aan wat jy verwag het.

Waar dit toegelaat word, vergelyk die resolver se ontvangs met een noukeurige kliënt- of deurgangswaarneming:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Moet nooit private name na onverwante publieke resolvers stuur net om ’n vergelyking te skep nie, en redigeer enigiets wat jy deel. Skei laastens ’n korrekte DNS-antwoord van die diensverbinding wat daarop volg: die opgeloste private adres het steeds ’n roete en toepassingsmagtiging nodig.