Split-DNS-opname: sis wêr’t elke observaasje nommen is

Twa minsken sykje itselde Split-DNS-probleem út en krije ferskate resolver-adressen. Ien brûkte in sykark, ien naam pakketten op ’e adapter op, en in tredde lies de eigen diagnostyk fan ’e kliïnt. Nimmen fan harren lieget, en nimmen beskriuwt itselde stadium. It observaasjepunt neame makket fan in tsjinstelling in kaart.

Ien syktocht, ferskate observaasjepunten

Foar ien ynterne namme binne der teminsten fiif plakken om te sjen: de applikaasje en de resolver-API dy’t er oanropt, it jildende domeinbelied op ’e kliïnt, in opname op ’e adapter of it filter, in kontrolearre gateway-grins en de resolver dy’t de fraach wier ûntfangt.

Elk fan harren beantwurdet in oare fraach, en gjinien bewisset allinnich wêr’t de fraach hinne gie.

In opname op ’e adapter lit pakketten sjen, gjin bedoeling. It seit net hokker resolver de kliïnt keas, en in lege opname kin in cached antwurd of in oare resolver-API betsjutte ynstee fan in dipt pakket. Behannelje elke observaasje as bewiis oer ien stadium. Set dan de stadia gear ta in paad.

It filter fan ’e kliïnt sit tusken applikaasje en tried

In VPN-kliïnt mei Split-DNS past domeinmatching ta foardat it pakket de masine ferlitt. Nammen yn it tunnelde efterheaksel gean nei de ynterne resolver; al it oare giet nei de lokale. It filter is belied, en belied kin ferskille per platfoarm en kliïntferzje.

Cisco’s Secure Client Split-DNS-rigline behannelje domeinmatching en it Windows-filter, en se skiede wat in applikaasje sjocht as er de native resolver-API brûkt fan wat in helpmiddel as nslookup sjocht. Dy ûnderskieden binne it punt.

Begjin by it jildende profyl en ien gewoane applikaasjesyktocht. Elke test dy’t in eksplisite tsjinner neamt is in bewust omwei; ferklearje him mei de eigen diagnostyk fan ’e kliïnt, en lit him gjin akseptkriterium wurde.

nslookup folget in oar paad as de applikaasje

nslookup bout syn eigen DNS-fraach en kin it resolver-belied fan it bestjoeringssysteem omgean. Dat makket it in nuttich helpmiddel om in spesifike tsjinner in spesifike fraach te stellen, en in misliedend helpmiddel om te testen wat in applikaasje ûnderfynt.

Op Windows beslút de tabel foar namme-oplossingsbelied hokker efterheaksel hokker tsjinner brûkt. It lêzen dêrfan lit it belied sjen dat de applikaasje folget, en dat is faak it ûntbrekkende stik.

Lês it belied en stel dan deselde fraach fia de normale resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Fersifere resolvers ferbergje de fraach, net de ferbining

In browser mei syn eigen DNS-over-HTTPS-resolver is in hiel oar gefal. De fraach giet binnen TLS fuort, sadat in pakketopname in ferbining nei in resolver-adres lit sjen, mar net de frege namme.

Sykje earst it beheard belied fan ’e browser út, en ferlykje dat dan mei in syktocht fan it bestjoeringssysteem. In browser dy’t syn eigen resolver kieze mei, sjocht it Split-DNS-belied miskien hielendal net.

Deselde foarsichtigheid jildt foar elke kliïnt dy’t syn eigen resolver meinimt. In opname dy’t de fiere ferbining identifisearret is gjin bewiis oer de fraachnamme. As jo de namme nedich hawwe, helje dy dan út ’e eigen logboeken fan ’e resolver of út ’e diagnostyk fan ’e applikaasje, mei de jildende privacyregels.

Ferlykje mei in markearre test

Kies in goedkarde ynterne namme foar it testen, plus in iepenbiere namme dy’t gjin gefoelige betsjutting hat. Skriuw foar elk de tiid, it recordtype, it antwurd en it ferwachte belied op.

Wêr’t it tastien is, ferlykje de ûntfangst fan ’e resolver mei ien smelle observaasje fan ’e kliïnt of gateway:

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

Stjoer nea privee nammen nei net-relatearre iepenbiere resolvers allinnich om in ferliking te meitsjen, en bewurkje alles wat jo diele. Skied úteinlik in korekt DNS-antwurd fan ’e tsjinstferbining dy’t folget: it oploste privee adres hat noch altyd in rûte en applikaasje-autorisaasje nedich.