İki sayt, bir özəl DNS zonası: qeydlər kimə aiddir?

Yaşıl saytda host əlavə edirsiniz, o, yaşıl istifadəçilər üçün həll olunur, sarı ofis isə hələ də NXDOMAIN alır. Bu nə VPN nasazlığıdır, nə də xarab resolver; bu, özəl zonadakı sahiblik boşluğudur. Ayrı-ayrı redaktə olunan iki qeyd siyahısı saytlar bir-birinə çata bildiyi üçün bir zonaya çevrilmir. Həll daha bir firewall qaydası deyil, dərcetmə planıdır.

Simptom çatışmayan sahibi adlandırır

Çox güman ki, hər saytda kimsə ad lazım olanda əlavə etdiyi yerli üstünlük, Pi-hole qeydi və ya dnsmasq sətri var. Yaşıl qeyd yalnız yaşıl resolverdə mövcuddur, ona görə sarıdakı müştəri öz resolverindən soruşur və doğru "belə ad yoxdur" cavabını alır. Köhnəlmiş cavab başqa cür görünür: host yerini dəyişib, bir sayt öz surətini yeniləyib, digəri isə hələ də köhnə ünvanı qaytarır.

Heç bir nümunə keşin təmizlənməsi ilə uzun müddət düzəlmir. Yönləndirici resolverin keşi bir vaxtlar aldığı cavabın surətidir, yeni adlar dərc edən səlahiyyət deyil, ona görə bu gün işləyən keş sabahkı host haqqında heç nə demir. BIND sənədləri əsas, ikincil, rekursiv və yönləndirici rolları məhz bu səbəbdən ayrıca təsvir edir.

Deməli, dizayn sualı dardır və cavablandırıla bilər: qeydi kim yarada bilər və o qeyd ona cavab verməli olan hər resolverə necə çatır?

Variant A: ikincillərlə bir səlahiyyətli zona

internal.example.com üçün əsas server işə salın və dəstəklənən ikincillər zonanı hər saytda əldə etsin. Hər saytın rekursiv resolveri yerli ikincildən soruşur, ona görə cavablar keşdən deyil, səlahiyyətli mənbədən gəlir və bir dəfə edilən dəyişiklik yenidən yazılmaq əvəzinə köçürülür.

Bu quruluş asan təxirə salınan və buraxılması baha başa gələn açıq qərarlar tələb edir. Zonanı kim redaktə edə bilər? Hansı serverlərə onu köçürməyə icazə verilir və hansı ünvanlar üzərindən? Saytlar arasındakı tunel söndüyü halda müştərilər nə görməlidir? İkincil son surətindən cavab verməyə davam edir, bu adətən istədiyiniz davranışdır, lakin kəsinti zamanı sürpriz deyil, bəyan edilmiş seçim olmalıdır.

Zona köçürmələrini ünvana görə tanınan ikincillərlə məhdudlaşdırın və tətbiq dəstəklədiyi yerlərdə tranzaksiya imzalarından istifadə edin. Açıq köçürmə, portu çata bilən hər kəs üçün daxili ad məkanınızın surətidir.

Qiymət koordinasiyadır: bir redaktə yolu, bir dəyişiklik baxışı və qeyd səhv olanda kimin növbədə olduğuna dair ortaq anlayış.

Variant B: hər sayt üçün alt domen

green.internal.example.com yaşıl sayta, yellow.internal.example.com sarı sayta delegasiya edin. Hər sayt öz adları üzrə səlahiyyətli olur və üst zona yalnız delegasiya qeydlərini daşıyır. Bir fayl üstündə rəqabət yox olur və yerli komanda mərkəzi dəyişikliyi gözləmədən host əlavə edə bilər.

Delegasiya üst zonada olmalıdır: saytın səlahiyyətli serverlərinə işarə edən NS qeydləri ilə. Tam delegasiya qeyri-mümkün olduqda alt domen üçün şərti yönləndirmə keçərli alternativdir, lakin bu, dərc edilmiş fakt deyil, resolver parametridir, ona görə hər resolver eyni qaydaya ehtiyac duyur.

Qiymət yox olmaq əvəzinə yerini dəyişir: üst zonanın hələ də sahibi lazımdır və yeni sayt yaratmaq artıq bir yerdə deyil, iki yerdə dəyişiklikdir.

Hər resolver seçimi izləsin

Müştərilərə təsdiqlənmiş resolveri və axtarış domenini dəstəklənən konfiqurasiya vasitəsilə verin və əmin olun ki, resolverin sorğu göndərməli olduğu istənilən uzaq DNS serverinə icazə verilmiş VPN marşrutu var. Tətbiqlərə həm də bu cavabların qaytardığı özəl ünvanlara marşrutlar lazımdır, çünki yolu olmayan düzgün ad yenə də qırıq bağlantıdır.

Pi-hole yerli həlli təmin edirsə, hansı qeydlərə sahib olduğunu və hansı sorğuları yönləndirdiyini yazın. Ayrı-ayrı redaktə olunan iki Pi-hole siyahısı yenə də replikasiya etmir. Pi-hole v6-da fərdi dnsmasq sətirləri TOML, CLI və ya mühit dəyişənləri kimi host tərəfli seçimlərlə qurulur və API vasitəsilə göstərilmir; /etc/dnsmasq.d/ fayllarının yüklənməsi isə susmaya görə söndürülmüş ayrı seçimdir.

Sonra hər yerdə görünməli olan bir adla hər iki tərəfdən sınaqdan keçirin:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA cavabı sarı resolverin özünü səlahiyyətli saydığını, ikincildən soruşduğunu yoxsa sadəcə yönləndirdiyini göstərir. Bunlar fərqli uğursuzluq rejimləri olan fərqli dizaynlardır və cavab adətən hansını həqiqətən tətbiq etdiyinizi müəyyən edir.

Üç qəbul halı ilə bitirin: hər saytdan bir ad, bir saat ərzində dəyişdirilmiş bir qeyd və saytlararası əlaqənin əlçatmaz olması. Yalnız birincisini keçən dizaynın kağızda dərcetmə planı, istehsalatda isə yerli üstünlüyü var.