რატომ აბრუნებს კერძო Route 53 ზონა NXDOMAIN-ს საჯარო სახელებისთვის

კერძო Route 53 ზონები ცვლიან სახელის პასუხს, ნაცვლად იმისა, რომ საჯარო ჩანაწერს შეუერთდნენ, და ეს ხალხს ყველაზე ცუდ მომენტში აკვირვებს. დაამატეთ ერთი შიდა ჩანაწერი api.example.net სახელისთვის კერძო ზონაში example.net სახელისთვის, დაუკავშირეთ იგი VPC-ს, და ამ მშობლის ქვეშ არსებული ყველა სხვა სახელი ახლა მხოლოდ კერძო ზონიდან პასუხობს. კლიენტი, რომელსაც გუშინ შეეძლო მიეღწია www.example.net მისამართზე, დღეს უარყოფით პასუხს იღებს. ქვემოთ მოცემული გზამკვლევი იწყება იმ წარუმატებელი მოთხოვნიდან და გარეთ მიდის იმ ზონისკენ, რომელმაც მას უპასუხა.

დაიწყეთ მოთხოვნიდან და არა კონსოლიდან

გაამრავლეთ ხარვეზი იმ კლიენტზე, რომელმაც ის შეატყობინა, და ჩაწერეთ ზუსტი სახელი და ჩანაწერის ტიპი. სახელი, რომელიც ვერ მუშაობს A ტიპისთვის, შეიძლება მაინც გადაწყდეს AAAA ტიპისთვის, და ქეშირებული სახელის ხელახლა ცდის ბრაუზერი მალავს, რომელი მათგანი გატყდა. გაუშვით მოთხოვნა ორჯერ: ერთხელ იმ რეზოლვერის გავლით, რომელსაც კლიენტი რეალურად იყენებს, და ერთხელ მის გვერდის ავლით მიმდინარე კვალის გამოყენებით.

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

მეორე ბრძანებაა მთავარი. მისი სტატუსის ხაზი და authority განყოფილება ასახელებს იმ ზონას, რომელმაც პასუხი შექმნა, ასე რომ შეგიძლიათ განასხვავოთ კერძო ზონიდან მიღებული უარყოფითი პასუხი დროის ამოწურვისგან, დაბლოკილი პორტისგან ან რეზოლვერისგან, რომელსაც მოთხოვნა არასდროს მიუღია. resolvectl აჩვენებს, რომელ ზედა სერვერს ჰკითხეს, და ხშირად ეს არ არის ის რეზოლვერი, რომლის გაგზავნასაც VPN-ისგან ვარაუდობდით.

თუ კვალდაკვალ მოთხოვნა აბრუნებს საჯარო მისამართს, ჩვეულებრივი კი არა, საჯარო ჩანაწერი ხელუხლებელია და პასუხობს კერძო ხედი. სწორედ ეს ერთი შედარება წყვეტს, ამ გვერდის დარჩენილი ნაწილის რომელი ნახევარი გეხებათ.

წაიკითხეთ, რომელმა ზონამ უპასუხა

პასუხი, რომელიც შეიცავს NXDOMAIN და authority განყოფილებაში კერძო ზონის SOA-ს, ამ ზონის საბოლოო პასუხია და არა წარუმატებელი ძიება. Route 53 Resolver-მა აირჩია კერძო ჰოსტირებული ზონა, რადგან სახელი დაემთხვა, შემდეგ ვერ იპოვა მოთხოვნილი ტიპის ჩანაწერი, და დოკუმენტირებული ქცევა არის უარყოფითი პასუხის დაბრუნება იმის ნაცვლად, რომ კითხვა საჯარო DNS-ს გადაეცეს.

არჩევანი სპეციფიკურობას მიჰყვება. როცა რამდენიმე კერძო სახელთა სივრცე ერთმანეთს ემთხვევა, იმარჯვებს ყველაზე სპეციფიკური დამთხვეული ზონა, და უფრო ფართო კერძო მშობელი მეორე შანსს არ იღებს იმ სახელისთვის, რომელიც არჩეულ შვილობილ ზონას არ აქვს. გადამისამართების წესები კიდევ ერთ ფენას ამატებს, რადგან დომენისთვის სპეციფიკური Resolver წესი შეიძლება სძლიოს კერძო ჰოსტირებული ზონის მიბმას. ჩამოთვალეთ მიბმები და წესები, სანამ დაასკვნით, რომ ზონა ცარიელია.

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]"

ორივე ბრძანებას სჭირდება ზონის მფლობელი ანგარიშის სერთიფიკატები, ხოლო მეორეს პირველიდან მიღებული ზონის ID. შეცვალეთ ის თქვენი ID-ით; ზემოთ მოცემული დამჭერი განზრახ არ არის რეალური.

რატომ იმარჯვებს კერძო ზონა

მიბმაა ის, რაც ზონას VPC-სთვის ხილვადს ხდის, და სწორედ იმ VPC-ის რეზოლვერი იყენებს მას. კერძო ზონას, რომელიც არ არის მიბმული იმ VPC-ზე, საიდანაც კლიენტის ტრაფიკი მოდის, საერთოდ არ აქვს ეფექტი, ხოლო არასწორ VPC-ზე მიბმა არასწორი მოსახლეობისთვის კერძო პასუხს ქმნის. შეამოწმეთ მიბმების სია ჩანაწერების რედაქტირებამდე, რადგან ზონა შეიძლება სწორი იყოს და მაინც უხილავი.

გადამფარავი სახელთა სივრცეები დაბნეულობის მეორე წყაროა. კერძო ზონა example.net სახელისთვის და კერძო ზონა api.example.net სახელისთვის ორივე ემთხვევა API მოთხოვნას, და პასუხობს უფრო სპეციფიკური. ეს სასარგებლოა, როცა გსურთ ვიწრო შიდა სახელთა სივრცე, და საშიში, როცა ვიწრო ზონას აკლია ჩანაწერი, რომელიც უფრო ფართოს აქვს. კერძო ჰოსტირებული ზონების განხილვები Route 53 დოკუმენტაციაში აღწერს როგორც ქვევით ვარდნის ქცევას, ისე წესების უპირატესობას, და ღირს მათი წაკითხვა მეორე გადამფარავი ზონის დამატებამდე.

ამიდან არცერთი არ ცვლის საჯარო ზონას. საჯარო რეზოლვერები კვლავ სწორად პასუხობენ საჯარო ჩანაწერებს, და ამიტომ VPC-ის გარეთ მყოფ ყველასთვის ეს ხარვეზი კლიენტის პრობლემად გამოიყურება.

აირჩიეთ სახელთა სივრცე ჩანაწერების დამატებამდე

თუ კერძო სახელები მხოლოდ შიდა სერვისების ახალ ოჯახს სჭირდება, მიეცით მას გამოყოფილი კერძო ქვედომენი და საჯარო მშობელი მარტო დატოვეთ. სახელი, როგორიცაა internal.example.net ვერ დაჩრდილავს www.example.net, და დაკარგული ჩანაწერის ზემოქმედების რადიუსი შემოიფარგლება იმ სახელებით, რომლებიც თქვენ ამ მიზნისთვის გამოიგონეთ. ფასი ის არის, რომ არსებული URL-ები და სერთიფიკატები შეიძლება ახალ სახელს არ შეესაბამებოდეს.

როცა საჯარო და კერძო მომხმარებლებმა ერთი და იგივე ჰოსტის სახელი უნდა შეინარჩუნონ, გაყოფილი ხედის DNS არის მხარდაჭერილი დიზაინი და ის მოითხოვს, რომ თითოეულ ხედში ჩანაწერები ცხადად შეინახოთ. ერთი ჩანაწერის მქონე ფართო კერძო ზონა არ ინახავს ამ ზონის ქვეშ არსებულ საჯარო დამოკიდებულებებს; ისინი ჩაანაცვლებს ერთი ჩანაწერის მქონე ზონით.

სანამ კლიენტების პოპულაციას კერძო ხედისკენ მიმართავთ, ჩამოთვალეთ ის სახელები, რომლებსაც აპლიკაცია რეალურად იძახებს. შესვლის ჰოსტები, სტატიკური რესურსების ჰოსტები, გადამისამართების სამიზნეები და API ბოლო წერტილები პირველები იტეხება, და ისინი ჩვეულებრივ რამდენიმე გუნდის ჩანაწერებზეა გაფანტული.

თვალყური ადევნეთ რეზოლვერის გზას, შემდეგ მარშრუტს

ლეპტოპი კერძო ხედს მხოლოდ მაშინ ხედავს, როცა მისი მოთხოვნები აღწევს იმ რეზოლვერამდე, რომელსაც მიბმა აქვს. VPN სერვერზე hosts ფაილის რედაქტირება არაფერს აქვეყნებს დაკავშირებული კლიენტებისთვის, და საჯარო რეზოლვერით კონფიგურირებული კლიენტი გააგრძელებს საჯარო პასუხების მიღებას, სანამ გვირაბი აწეულია. დაადასტურეთ რეზოლვერის მისამართი, რომელიც კლიენტმა მიიღო, შემდეგ გაიმეორეთ მოთხოვნა კლიენტიდან და არა სერვერიდან.

როცა სახელი გადაწყდა, შეამოწმეთ გზა დაბრუნებულ მისამართამდე ცალკე ნაბიჯად, მაგალითად ip route get ბრძანებით მოთხოვნის მიერ დაბრუნებული მისამართის მიმართ. სწორი კერძო პასუხი მისამართამდე მარშრუტის გარეშე მარშრუტიზაციის პრობლემაა, ხოლო ჩანაწერის არარსებობის პასუხი DNS ხედის პრობლემა; ორივეს ერთ პრობლემად მოპყრობა იძლევა ისეთ შესწორებებს, რომლებიც არ ძლებს. დატოვეთ სერვისის TLS ჰოსტის სახელისა და სერთიფიკატის შემოწმებები უცვლელად, რადგან კერძო მისამართი ცვლის, სად მიდის კავშირი, და არაფერს იმაზე, თუ რომელი სერთიფიკატია ძალაში.

დაასრულეთ ცვლილების ჩანაწერში ზონის, მიბმის, რეზოლვერისა და თქვენს მიერ შემოწმებული სახელების ჩაწერით. მაშინ შემდეგმა ადამიანმა, რომელიც ჩანაწერს დაამატებს, იცის, რომელი სახელთა სივრცეა ავტორიტეტული იმ კლიენტური პოპულაციისთვის.