Split-DNS qeydi: hər müşahidənin harada götürüldüyünü deyin

İki nəfər eyni Split-DNS problemini araşdırır və fərqli resolver ünvanları əldə edir. Biri axtarış alətindən istifadə etdi, biri adapterdə paketləri tutdu, üçüncüsü isə müştərinin öz diaqnostikasını oxudu. Heç biri yalan demir və heç biri eyni mərhələni təsvir etmir. Müşahidə nöqtəsini adlandırmaq ziddiyyəti xəritəyə çevirir.

Bir axtarış, bir neçə müşahidə nöqtəsi

Tək bir daxili ad üçün baxmaq lazım olan ən azı beş yer var: tətbiq və onun çağırdığı resolver API-si, müştəridəki effektiv domen siyasəti, adapter və ya filtr qeydi, nəzarət edilən şlüz sərhədi və sorğunu həqiqətən qəbul edən resolver.

Hər biri fərqli suala cavab verir və heç biri təkbaşına sorğunun hara getdiyini sübut etmir.

Adapter qeydi paketləri göstərir, niyyəti yox. Müştərinin hansı resolveri seçdiyini demir və boş qeyd paketin atıldığını deyil, keşlənmiş cavabı və ya fərqli resolver API-sini göstərə bilər. Hər müşahidəni bir mərhələyə dair sübut kimi qəbul edin. Sonra mərhələləri bir yolda birləşdirin.

Müştəri filtri tətbiqlə naqil arasında dayanır

Split-DNS ilə VPN müştərisi paket maşından çıxmadan əvvəl domen uyğunlaşdırmasını tətbiq edir. Tunel şəbəkəsinin şəkilçisindəki adlar daxili resolverə gedir; qalan hər şey yerli resolverə gedir. Filtr siyasətdir və siyasət platformaya və müştəri versiyasına görə fərqlənə bilər.

Cisco-nun Secure Client Split-DNS təlimatı domen uyğunlaşdırmasını və Windows filtrini əhatə edir və tətbiqin yerli resolver API-sini işlətdiyi zaman gördüyü şeyi nslookup kimi bir alətin gördüyündən ayırır. Bu fərqlər əsas məqamdır.

Effektiv profildən və bir adi tətbiq axtarışından başlayın. Açıq şəkildə konkret server göstərən istənilən test qəsdən edilən yayınmadır; onu izah etmək üçün müştərinin öz diaqnostikasından istifadə edin və onun qəbul meyarına çevrilməsinə imkan verməyin.

nslookup tətbiqdən fərqli yol tutur

nslookup öz DNS sorğusunu qurur və əməliyyat sisteminin resolver siyasətini yan keçə bilir. Bu onu konkret serverə konkret sual vermək üçün faydalı, tətbiqin nə yaşayacağını test etmək üçün isə yanıldıcı alət edir.

Windows-da ad həlli siyasəti cədvəli hansı şəkilçinin hansı serveri işlədəcəyini müəyyən edir. Onu oxumaq tətbiqin izləyəcəyi siyasəti göstərir və çox vaxt çatışmayan hissə elə budur.

Siyasəti oxuyun və sonra eyni sualı adi resolver vasitəsilə verin:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Şifrələnmiş resolverlər sorğunu gizlədir, bağlantını yox

Öz DNS-over-HTTPS resolveri olan brauzer tamamilə başqa bir haldır. Sorğu TLS-in içində çıxır, buna görə paket qeydi resolver ünvanına bağlantı göstərir, amma soruşulan adı göstərmir.

Əvvəlcə brauzerin idarə olunan siyasətini müəyyənləşdirin, sonra onu əməliyyat sistemi axtarışı ilə müqayisə edin. Öz resolverini seçməyə icazə verilən brauzer Split-DNS siyasətini heç görməyə bilər.

Eyni ehtiyat tədbiri öz resolverini gətirən istənilən müştəriyə aiddir. Uzaq bağlantını müəyyən edən qeyd sorğu adı barədə sübut deyil. Əgər ada ehtiyacınız varsa, onu resolverin öz jurnallarından və ya tətbiqin diaqnostikasından götürün, tətbiq olunan məxfilik qaydaları ilə.

İşarələnmiş testlə müqayisə edin

Test üçün təsdiqlənmiş daxili ad, həmçinin heç bir həssas məna daşımayan ictimai ad seçin. Hər biri üçün vaxtı, qeyd növünü, cavabı və gözlədiyiniz siyasəti qeyd edin.

İcazə verildiyi yerlərdə resolverin qəbulunu bir dar müştəri və ya şlüz müşahidəsi ilə müqayisə edin:

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

Sadəcə müqayisə yaratmaq üçün şəxsi adları əlaqəsiz ictimai resolverlərə heç vaxt göndərməyin və paylaşdığınız hər şeyi redaktə edin. Nəhayət, düzgün DNS cavabını ondan sonra gələn xidmət bağlantısından ayırın: həll edilmiş şəxsi ünvan hələ də marşrut və tətbiq icazəsi tələb edir.