Nə üçün xüsusi Route 53 zonası ictimai adlar üçün NXDOMAIN qaytarır

Xüsusi Route 53 zonaları ictimai qeydlə birləşmək əvəzinə adın cavabını əvəz edir və bu, insanları ən pis anda təəccübləndirir. Bir daxili qeyd əlavə edin: api.example.net üçün xüsusi zonada example.net, onu VPC ilə əlaqələndirin və həmin üst ad altındakı bütün digər adlar artıq yalnız xüsusi zonadan cavablandırılır. Dünən www.example.net ünvanına çata bilən müştəri bu gün mənfi cavab alır. Aşağıdakı icmal həmin uğursuz sorğudan başlayır və ona cavab verən zonaya doğru genişlənir.

Sorğudan başlayın, konsoldan yox

Uğursuzluğu onu bildirən müştəridə təkrarlayın və dəqiq adı və qeyd növünü qeyd edin. Ad A üçün uğursuz olsa da, AAAA üçün həll oluna bilər, və keşlənmiş adı təkrar yoxlayan brauzer hansının pozulduğunu gizlədir. Sorğunu iki dəfə işlədin: bir dəfə müştərinin həqiqətən istifadə etdiyi resolver vasitəsilə, bir dəfə isə onu keçən izləmə ilə.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

İkinci əmr vacib olanıdır. Onun status sətri və səlahiyyət bölməsi cavabı verən zonanı göstərir, beləliklə xüsusi zonadan gələn mənfi cavabı vaxt aşımından, bloklanmış portdan və ya sorğunu heç vaxt almayan resolverdən ayıra bilərsiniz. resolvectl hostun hansı yuxarı serverdən soruşduğunu göstərir və bu, çox vaxt VPN-in ötürdüyünü güman etdiyiniz resolver deyil.

İzlənən sorğu ictimai ünvanı qaytarır, adi sorğu isə qaytarmırsa, ictimai qeyd bütövdür və cavabı xüsusi görünüş verir. Bu tək müqayisə bu səhifənin qalan hissəsinin hansı yarısının sizə aid olduğunu müəyyən edir.

Hansı zonanın cavab verdiyini oxuyun

Cavabda NXDOMAIN olan və səlahiyyət bölməsində xüsusi zonanın SOA-sını daşıyan yanıt həmin zonadan qəti cavabdır, axtarış uğursuzluğu deyil. Route 53 Resolver xüsusi hosted zonanı adı uyğun gəldiyi üçün seçdi, sonra tələb olunan növdə qeyd tapmadı və sənədləşdirilmiş davranış sualı ictimai DNS-ə ötürmək əvəzinə mənfi cavabı qaytarmaqdır.

Seçim spesifikliyə uyğundur. Bir neçə üst-üstə düşən xüsusi ad məkanı olduqda, uyğun gələn ən spesifik zona qalib gəlir və daha geniş xüsusi üst zona seçilmiş alt zonada olmayan ad üçün ikinci şans almır. Yönləndirmə qaydaları bunun üstünə daha bir qat əlavə edir, çünki domenə xas Resolver qaydası xüsusi hosted zona əlaqəsindən üstün ola bilər. Zonanın boş olduğu qənaətinə gəlməzdən əvvəl əlaqələri və qaydaları sadalayın.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Hər iki əmr zonanı sahiblənən hesab üçün etimadnamə tələb edir, ikincisi isə birincidən zona identifikatorunu tələb edir. Onu öz identifikatorunuzla əvəz edin; yuxarıdakı yer tutucu qəsdən real deyil.

Xüsusi zona nə üçün qalib gəlir

Zonanı VPC üçün görünən edən əlaqədir və onu tətbiq edən həmin VPC-dəki Resolverdir. Müştərinin trafiki gəldiyi VPC ilə əlaqələndirilməmiş xüsusi zonanın heç bir təsiri yoxdur, yanlış VPC ilə əlaqə isə yanlış kütlə üçün xüsusi cavab yaradır. Qeydləri redaktə etməzdən əvvəl əlaqə siyahısına baxın, çünki zona düzgün ola bilər və yenə də görünməz qala bilər.

Üst-üstə düşən ad məkanları qarışıqlığın ikinci mənbəyidir. example.net üçün xüsusi zona və api.example.net üçün xüsusi zona hər ikisi API sorğusuna uyğun gəlir və daha spesifik olan cavab verir. Bu, dar daxili ad məkanı istədikdə faydalıdır, dar zonada daha geniş zonada olan qeyd çatışmadıqda isə təhlükəlidir. Xüsusi hosted zona mülahizələri Route 53 sənədlərində həm aşağı səviyyəyə keçmə davranışını, həm də qayda prioritetini təsvir edir və ikinci üst-üstə düşən zona əlavə etməzdən əvvəl oxumağa dəyər.

Bunların heç biri ictimai zonanı dəyişmir. İctimai resolverlər ictimai qeydlərə yenə də düzgün cavab verir, buna görə də VPC-dən kənarda olan hər kəs üçün uğursuzluq müştəri problemi kimi görünür.

Qeydləri əlavə etməzdən əvvəl ad məkanını seçin

Yalnız yeni daxili xidmətlər ailəsi xüsusi adlara ehtiyac duyursa, ona ayrılmış xüsusi subdomen verin və ictimai üst zonanı toxunulmaz qoyun. internal.example.net kimi bir ad www.example.net adını kölgələyə bilməz və çatışmayan qeydin təsir dairəsi bunun üçün uydurduğunuz adlarla məhdudlaşır. Qiyməti odur ki, mövcud URL-lər və sertifikatlar yeni ada uyğun gəlməyə bilər.

İctimai və xüsusi istifadəçilər eyni host adını saxlamalı olduqda, split-view DNS dəstəklənən dizayndır və hər görünüşdə qeydləri açıq şəkildə saxlamağınızı tələb edir. İçində bir qeyd olan geniş xüsusi zona həmin zonanın altındakı ictimai asılılıqları qorumur; onları bir qeydi olan zona ilə əvəz edir.

Müştəri kütləsini xüsusi görünüşə yönəltməzdən əvvəl tətbiqin həqiqətən çağırdığı adları inventarlaşdırın. Giriş hostları, statik resurs hostları, yönləndirmə hədəfləri və API son nöqtələri ilk pozulanlardır və onlar adətən bir neçə komandanın qeydlərinə səpələnib.

Resolyer yolunu, sonra marşrutu izləyin

Noutbuk xüsusi görünüşü yalnız sorğuları əlaqəsi olan resolverə çatdıqda görür. VPN serverində hosts faylını redaktə etmək qoşulmuş müştərilərə heç nə yayımlamır və ictimai resolverlə konfiqurasiya edilmiş müştəri tunel açıq olduqda ictimai cavablar almağa davam edir. Müştərinin aldığı resolver ünvanını təsdiqləyin, sonra sorğunu serverdən deyil, müştəridən təkrarlayın.

Ad həll olunduqdan sonra qaytarılan ünvana gedən yolu ayrı bir addım kimi yoxlayın, məsələn ip route get ilə sorğunun qaytardığı ünvana qarşı. Ünvana marşrut olmadan düzgün xüsusi cavab marşrut problemidir, qeydin olmaması barədə cavab isə DNS görünüşü problemidir; onları bir məsələ kimi qəbul etmək dayanmayan düzəlişlər yaradır. Xidmətin TLS host adını və sertifikat yoxlamalarını dəyişməz saxlayın, çünki xüsusi ünvan bağlantının hara getdiyini dəyişir, hansı sertifikatın etibarlı olması barədə heç nəyi deyil.

Dəyişiklik qeydində zonanı, əlaqəni, resolveri və yoxladığınız adları yazaraq bitirin. Beləliklə qeyd əlavə edən növbəti şəxs həmin müştəri kütləsi üçün hansı ad məkanının səlahiyyətli olduğunu biləcək.