Две особе истражују исти проблем Split-DNS и добијају различите адресе резолвера. Једна је користила алат за претрагу, друга је снимила пакете на адаптеру, а трећа је прочитала сопствену дијагностику клијента. Нико од њих не лаже и нико не описује исту фазу. Именовање тачке посматрања претвара противречност у мапу.

Једна претрага, неколико тачака посматрања

За једно унутрашње име постоји најмање пет места за гледање: апликација и API резолвера који позива, важећа доменска политика на клијенту, снимање на адаптеру или филтеру, контролисана граница пролаза и резолвер који заиста прима упит.

Свако одговара на друго питање и ниједно само по себи не доказује куда је упит отишао.

Снимање на адаптеру показује пакете, а не намеру. Не каже који је резолвер клијент изабрао, а празно снимање може значити кеширан одговор или други API резолвера, а не одбачен пакет. Третирајте свако посматрање као доказ о једној фази. Затим саставите фазе у путању.

Филтер клијента стоји између апликације и жице

VPN клијент са Split-DNS примењује подударање домена пре него што пакет напусти машину. Имена у тунелском суфиксу иду ка унутрашњем резолверу; све остало иде ка локалном. Филтер је политика, а политика се може разликовати по платформи и верзији клијента.

Упутство Secure Client-а за Split-DNS од Cisco-а покрива подударање домена и Windows филтер и раздваја оно што апликација види када користи изворни API резолвера од онога што види алат као што је nslookup. Управо те разлике су поента.

Почните од важећег профила и једне обичне претраге апликације. Сваки тест који именује одређени сервер је намерно заобилажење; објасните га сопственом дијагностиком клијента и не дозволите да постане критеријум прихватања.

nslookup иде другим путем од апликације

nslookup гради сопствени DNS упит и може заобићи политику резолвера оперативног система. То га чини корисним алатом за постављање одређеног питања одређеном серверу и обмањујућим алатом за тестирање онога што ће апликација доживети.

У Windows-у табела политике разрешавања имена одлучује који суфикс користи који сервер. Њено читање показује политику коју ће апликација следити, а то је често део који недостаје.

Прочитајте политику и затим поставите исто питање кроз обични резолвер:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Шифровани резолвери крију упит, а не везу

Прегледач са сопственим резолвером DNS-over-HTTPS је сасвим други случај. Упит излази унутар TLS-а, па снимање пакета показује везу са адресом резолвера, али не и име које се пита.

Прво утврдите управљану политику прегледача, затим је упоредите са претрагом оперативног система. Прегледач коме је дозвољено да изабере сопствени резолвер можда уопште неће видети политику Split-DNS.

Иста пажња важи за сваког клијента који доноси сопствени резолвер. Снимање које идентификује удаљену везу није доказ о имену упита. Ако вам је име потребно, узмите га из сопствених евиденција резолвера или из дијагностике апликације, уз правила приватности која важе.

Упоредите са означеним тестом

Изаберите одобрено унутрашње име за тестирање, плус јавно име које не носи осетљиво значење. За свако запишите време, тип записа, одговор и политику коју сте очекивали.

Где је дозвољено, упоредите пријем у резолверу са једним уским посматрањем клијента или пролаза:

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

Никада не шаљите приватна имена неповезаним јавним резолверима само да бисте направили поређење и уредите све што делите. На крају, одвојите тачан DNS одговор од везе са сервисом која следи: решена приватна адреса и даље захтева путању и дозволу апликације.

Повезани чланци