למה אזור Route 53 פרטי מחזיר NXDOMAIN עבור שמות ציבוריים

אזורי Route 53 פרטיים מחליפים את התשובה עבור שם במקום להתמזג עם הרשומה הציבורית, וזה מפתיע אנשים ברגע הגרוע ביותר. הוסיפו רשומה פנימית אחת עבור api.example.net באזור פרטי עבור example.net, קשרו אותו ל-VPC, וכל שם אחר תחת אותו אב נענה מעתה רק מהאזור הפרטי. לקוח שיכל להגיע אל www.example.net אתמול מקבל היום תשובה שלילית. הסיור שלהלן מתחיל מאותה שאילתה שנכשלה וממשיך החוצה אל האזור שענה לה.

התחילו מהשאילתה, לא מהקונסולה

שחזרו את הכשל אצל הלקוח שדיווח עליו, ורשמו את השם המדויק ואת סוג הרשומה. שם שנכשל עבור A עשוי בכל זאת להיפתר עבור AAAA, ודפדפן שמנסה שוב שם שמור במטמון מסתיר איזה משניהם נשבר. הריצו את השאילתה פעמיים: פעם אחת דרך ה-resolver שהלקוח באמת משתמש בו, ופעם אחת עם מעקב שעוקף אותו.

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

הפקודה השנייה היא החשובה. שורת הסטטוס וקטע הסמכות שלה מזהים את האזור שהפיק את התשובה, כך שתוכלו להבדיל בין תשובה שלילית מהאזור הפרטי לבין פסק זמן, פורט חסום או resolver שמעולם לא קיבל את השאילתה. resolvectl מראה מאיזה שרת עליון נשאלה, ולעתים קרובות זה אינו ה-resolver שהנחתם שה-VPN דחף.

אם השאילתה עם המעקב מחזירה את הכתובת הציבורית והרגילה לא, הרשומה הציבורית שלמה והתצוגה הפרטית עונה. ההשוואה האחת הזו קובעת איזה חצי מהמשך העמוד הזה חל עליכם.

קראו איזה אזור ענה

תשובה שנושאת NXDOMAIN עם ה-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]"

שתי הפקודות דורשות אישורים לחשבון שבעל האזור, והשנייה דורשת את מזהה האזור מהראשונה. החליפו אותו במזהה שלכם; מציין המקום שלמעלה אינו אמיתי בכוונה.

למה האזור הפרטי מנצח

השיוך הוא מה שהופך את האזור לנראה ל-VPC, וה-resolver באותו VPC הוא שמחיל אותו. לאזור פרטי שאינו משויך ל-VPC שממנו מגיע התעבורה של הלקוח אין שום השפעה, בעוד ששיוך ל-VPC הלא נכון מייצר תשובה פרטית לאוכלוסייה הלא נכונה. בדקו את רשימת השיוכים לפני עריכת רשומות, מפני שאזור יכול להיות נכון ועדיין בלתי נראה.

מרחבי שמות חופפים הם המקור השני לבלבול. אזור פרטי עבור example.net ואזור פרטי עבור api.example.net שניהם תואמים לשאילתת API, והספציפי יותר עונה. זה שימושי כאשר אתם רוצים מרחב שמות פנימי צר, ומסוכן כאשר לאזור הצר חסרה רשומה שיש לרחב יותר. השיקולים לגבי אזורים מאוחסנים פרטיים מופיעים במדריך תיעוד Route 53 ומתארים גם את התנהגות הנפילה וגם את קדימות הכללים, וכדאי לקרוא אותם לפני שמוסיפים אזור חופף שני.

שום דבר מזה לא משנה את האזור הציבורי. Resolvers ציבוריים עדיין עונים נכון על הרשומות הציבוריות, ולכן הכשל נראה כמו בעיית לקוח לכל מי שמחוץ ל-VPC.

בחרו את מרחב השמות לפני שמוסיפים רשומות

אם רק משפחה חדשה של שירותים פנימיים זקוקה לשמות פרטיים, תנו לה תת-דומיין פרטי ייעודי והניחו לאב הציבורי. שם כמו internal.example.net לא יכול להאפיל על www.example.net, ורדיוס ההשפעה של רשומה חסרה מוגבל לשמות שהמצאתם למטרה הזו. המחיר הוא שכתובות URL ותעודות קיימות אולי לא יתאימו לשם החדש.

כאשר משתמשים ציבוריים ופרטיים חייבים לשמור על אותו שם מארח, DNS עם תצוגה מפוצלת הוא העיצוב הנתמך והוא דורש שתחזיקו את הרשומות בכל תצוגה במפורש. אזור פרטי רחב עם רשומה אחת אינו משמר את התלויות הציבוריות תחת אותו אזור; הוא מחליף אותן באזור שיש בו רשומה אחת.

ערכו מלאי של השמות שאפליקציה באמת קוראת לפני שאתם מפנים אוכלוסיית לקוחות לתצוגה הפרטית. מארחי התחברות, מארחי נכסים סטטיים, יעדי הפניה ונקודות קצה של API הם הראשונים להישבר, והם בדרך כלל מפוזרים ברשומות של כמה צוותים.

עקבו אחר נתיב ה-resolver, ואז אחר המסלול

מחשב נייד רואה את התצוגה הפרטית רק אם השאילתות שלו מגיעות ל-resolver שיש לו השיוך. עריכת קובץ hosts בשרת ה-VPN אינה מפרסמת דבר ללקוחות מחוברים, ולקוח שמוגדר עם resolver ציבורי ימשיך לקבל תשובות ציבוריות כל עוד המנהרה פעילה. אשרו את כתובת ה-resolver שהלקוח קיבל, ואז חזרו על השאילתה מהלקוח ולא מהשרת.

לאחר שהשם נפתר, בדקו את המסלול לכתובת שהוחזרה כשלב נפרד, למשל עם ip route get מול הכתובת שהשאילתה החזירה. תשובה פרטית נכונה בלי מסלול לכתובת היא בעיית ניתוב, ותשובה על רשומה חסרה היא בעיית תצוגת DNS; התייחסות אליהן כבעיה אחת מייצרת תיקונים שלא מחזיקים. השאירו את בדיקות שם המארח של TLS והתעודה ללא שינוי, מפני שכתובת פרטית משנה לאן החיבור הולך ושום דבר לגבי איזו תעודה תקפה.

סיימו בתיעוד האזור, השיוך, ה-resolver והשמות שאימתתם בהערת השינוי. אז האדם הבא שמוסיף רשומה יידע איזה מרחב שמות הוא הסמכותי לאותה אוכלוסיית לקוחות.