VPN DNS səhvdir? Bir səlahiyyətli server köhnəlmiş ola bilər
VPN-i qoşun və bir ad dünənki ünvana çevrilir. Tunel DNS-i sındırmadı; dərc olunmuş səlahiyyətli server bütün müddət köhnəlmiş zona məlumatı verirdi.
VPN-i qoşun və bir host adı dünənki ünvana, ya da heç bir yerə çevrilir. Ayırın və yenidən işləyir. İlk refleks tunelin ötürdüyü həlledicini günahlandırmaqdır, lakin daha çox rastlanan səbəb zona yeniləmələrini qəbul etməyi dayandırmış dərc olunmuş ad serveridir. Yeni yol sadəcə keşlənmiş cavabınızın gəldiyi səlahiyyətlidən fərqli bir səlahiyyətliyə çatdı.
Simptom həlledici ilə dəyişir
Rekursiv həlledici səlahiyyətlinin ona dediyini qaytarır, sonra həmin cavabı TTL müddətində saxlayır. Əgər tunel başqa həlledici ötürürsə və ya köhnənin artıq əlçatan olmadığı bir yol yaradırsa, müştəri başqa səlahiyyətliyə sorğu göndərir və başqa cavab alır. Domen həmin anda dəyişmədi; ona baxışınız dəyişdi.
Buna görə eyni ad bir ofisdə işləyə, mehmanxanadan isə uğursuz ola bilər və buna görə yerli keşin təmizlənməsi yalnız bəzən kömək edir. Keşin təmizlənməsi sualı yenidən eyni səlahiyyətliyə göndərir.
Fərqləndirici sınaq hər dərc olunmuş serverə birbaşa sorğudur.
Hər səlahiyyətliyə birbaşa sorğu verin
Yadda saxladığınız siyahıdan deyil, delegasiyadan başlayın. Valideyndən NS dəstini soruşun, sonra həmin dəstdəki hər adı sizi maraqlandıran qeyd üçün sorğulayın. Eyni ada qarşı müxtəlif səlahiyyətlilərdə iki sorğu zonanın ardıcıl olub-olmadığını dərhal göstərir.
dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A
Eyni şeyi zona zirvəsindəki NS qeydləri üçün edin, çünki valideyn delegasiyası və zonanın öz NS dəsti miqrasiyadan sonra fərqlənə bilər. SOA üzərindəki seriya nömrələri müqayisə ediləcək növbəti şeydir və çox geridə qalan ikincil server cavab problemi deyil, köçürmə problemidir.
Bu sorğuları yalnız masanızdan deyil, uğursuz olan şəbəkədən icra edin.
Nəzərdə tutulan görünüşləri pozulmuşlardan ayırın
Bəzi domenlər bölgəyə və ya həlledici qrupuna görə qəsdən fərqli cavab verir və split-horizon quruluşları müəssisə şəbəkələrində normaldır.
Sual fərqin sənədləşdirilmiş və sabit olub-olmadığıdır. Nəzərdə tutulmayan görünüş başqa cür görünür: bir səlahiyyətlinin digərlərinin heç vaxt almadığı qeydi var, ya da hamısının bölüşdüyü qeyd ondan çatışmır. RFC 2182 seçim və yerləşdirmə təlimatı səlahiyyətli əlçatanlığı ortaq məsuliyyət kimi qəbul edir və burada doğru çərçivə budur. Ehtiyat yalnız o zaman mövcuddur ki, hər dərc olunmuş server nəzərdə tutulan məlumatı cavablandıra bilsin, sadəcə 53 portunda bağlantı qəbul etməsin.
SERVFAIL cavab verən server, inamla və səhv cavab verəndən daha asan diaqnoz edilir.
Miqrasiya keşin gizlətdiyini üzə çıxarır
Provayder dəyişikliyi zamanı iki səlahiyyətli yer dəyişir: valideyn delegasiyası və zonanın öz NS qeydləri. Hər ikisi yenilənməlidir və hər ikisi TTL müddətləri üçün keşlənir. Köhnə server işləməyə davam edib əvvəlki zonanı verməyə davam etsə, həllediciləri ona sorğu göndərən müştərilər keçid tam göründükdən çox sonra da köhnə cavabı almağa davam edəcək.
Uzunömürlü keşin gizlətdiyi vəziyyət məhz budur. Bütün həftə işləyən iş stansiyası yeni səlahiyyətlinin təzə cavabını saxlayan həlledici ilə danışırdı, köhnə isə hamıya köhnəlmiş məlumat verməyə davam edirdi.
Noutbukda həlledicini dəyişmək yalnız o noutbuku düzəldir, başqa heç nəyi.
Zonanı düzəldin, həlledicini deyil
Zona üçün hansı serverlərin səlahiyyətli olması nəzərdə tutulduğunu müəyyən edin, idarə olunan zonanı və ya delegasiyanı hər birinin nəzərdə tutulan məlumatı verməsi üçün düzəldin və planlaşdırdığınız ehtiyatı saxlayın. Bir VPN çıxışı qəribə cavab aldığı üçün ad serverini silmək əlçatanlığı azaldır və uyğunsuzluğu yerində saxlayır.
Sonra birbaşa sorğuları hər iki şəbəkədən yenidən icra edin və dəyişdirdiyiniz qeydin TTL müddətinin bitməsini gözləyin.
Cavabın hər səlahiyyətlidən sabit olduğunu təsdiqləyin və nəzərdə tutulan görünüşü zona sənədləşməsinə yazın ki, növbəti fərqi asanlıqla təsnif etmək mümkün olsun.