Split-DNS-opname: zeg waar elke observatie is gedaan

Twee mensen onderzoeken hetzelfde Split-DNS-probleem en krijgen verschillende resolveradressen. Eén gebruikte een opzoektool, één legde pakketten vast op de adapter en een derde las de diagnostiek van de client zelf. Niemand liegt, en niemand beschrijft dezelfde fase. Het observatiepunt benoemen maakt van een tegenspraak een kaart.

Eén lookup, meerdere observatiepunten

Voor één interne naam zijn er minstens vijf plaatsen om te kijken: de applicatie en de resolver-API die zij aanroept, het geldende domeinbeleid op de client, een opname op de adapter of het filter, een beheerste gatewaygrens en de resolver die de query werkelijk ontvangt.

Elk beantwoordt een andere vraag, en geen enkele alleen bewijst waar de query naartoe ging.

Een opname op de adapter toont pakketten, geen bedoeling. Zij zegt niet welke resolver de client koos, en een lege opname kan een gecacht antwoord of een andere resolver-API betekenen in plaats van een weggegooid pakket. Behandel elke observatie als bewijs over één fase. Zet daarna de fasen in elkaar tot een pad.

Het filter van de client zit tussen app en draad

Een VPN-client met Split-DNS past domeinovereenkomst toe voordat het pakket de machine verlaat. Namen in het getunnelde suffix gaan naar de interne resolver; al het andere gaat naar de lokale. Het filter is beleid, en beleid kan per platform en clientversie verschillen.

De Split-DNS-richtlijnen van Secure Client van Cisco behandelen domeinovereenkomst en het Windows-filter, en zij scheiden wat een app ziet wanneer zij de native resolver-API gebruikt van wat een hulpmiddel als nslookup ziet. Die verschillen zijn het punt.

Begin bij het geldende profiel en één gewone applicatieopzoeking. Elke test die een expliciete server noemt, is een bewuste omweg; verklaar hem met de diagnostiek van de client zelf, en laat hem niet het acceptatiecriterium worden.

nslookup neemt een andere route dan de app

nslookup bouwt zijn eigen DNS-query en kan het resolverbeleid van het besturingssysteem omzeilen. Dat maakt het nuttig om een bepaalde server een bepaalde vraag te stellen, en misleidend om te testen wat een applicatie zal ervaren.

Op Windows bepaalt de naamoplossingsbeleid-tabel welk suffix welke server gebruikt. Die lezen toont het beleid dat de applicatie volgt, en dat is vaak het ontbrekende stuk.

Lees het beleid en stel daarna dezelfde vraag via de normale resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Versleutelde resolvers verbergen de query, niet de verbinding

Een browser met zijn eigen DNS-over-HTTPS-resolver is een heel ander geval. De query gaat naar buiten binnen TLS, dus een pakketopname toont een verbinding naar een resolveradres maar niet de gevraagde naam.

Bepaal eerst het beheerde beleid van de browser en vergelijk dat daarna met een opzoeking van het besturingssysteem. Een browser die zijn eigen resolver mag kiezen, ziet het Split-DNS-beleid misschien helemaal niet.

Dezelfde voorzichtigheid geldt voor elke client die zijn eigen resolver meebrengt. Een opname die de externe verbinding herkent, is geen bewijs over de querynaam. Als je de naam nodig hebt, haal die dan uit de logboeken van de resolver zelf of uit de diagnostiek van de applicatie, met de geldende privacyregels.

Vergelijk met een gelabelde test

Kies een goedgekeurde interne naam voor de test, plus een openbare naam zonder gevoelige betekenis. Noteer voor elk de tijd, het recordtype, het antwoord en het verwachte beleid.

Waar het is toegestaan, vergelijk de ontvangst door de resolver met één smalle observatie van de client of de gateway:

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

Stuur nooit privénamen naar ongerelateerde openbare resolvers alleen om een vergelijking te maken, en redigeer alles wat je deelt. Scheid ten slotte een juist DNS-antwoord van de dienstverbinding die volgt: het opgeloste privéadres heeft nog steeds een route en een applicatieautorisatie nodig.