DNS במגדלור Nebula: מי רשאי לשאול אילו רשומות?
המאזין האופציונלי עונה מנתוני מארחים שהמגדלור מחזיק. שאילתות רשומות A ו-TXT נבדלות בנגישות ובקהל, לכן קשרו אותו בכוונה.
תפקיד המגדלור ב-Nebula עושה עבודה רבה שאנשים מניחים שהיא אוטומטית, והמענה על DNS אינו אחד מהם. שירות שמות הוא מאזין אופציונלי שמתחיל כשכבוי, ולכן מארח שמפענח היטב בתוך ה-overlay עלול שלא יהיה לו כלל במה לפענח את המחשב הנייד של עמית. לפני שמדליקים אותו, החליטו מי אמור להגיע אליו ואילו סוגי רשומות אתם מוכנים לענות, כי שתי התשובות הללו שונות.
המאזין אופציונלי וכבוי כברירת מחדל
גילוי ו-DNS הם שירותים נפרדים. המגדלור עוזר לעמיתים למצוא זה את זה ויכול בנוסף לענות על שאילתות שמות לגבי מארחים שהוא מכיר, אך החלק השני הזה חייב להיות מופעל במפורש בתצורה.
החליטו אילו ממשקים ורשתות אמורים להגיע אל המאזין לפני שאתם מפעילים משהו. שירות DNS שעונה על ממשק שלא התכוונתם אליו הופך לדליפת מידע קטנה בלי שום רשומת יומן שמישהו קורא. ההחלטה זולה בהרבה עכשיו מאשר לצמצם אותה מאוחר יותר, אחרי שמשהו תלוי בתשובה הלא נכונה. שתי שורות תצורה קלות יותר להצדקה מאשר פתק תקרית בעוד חצי שנה.
רשומות A ו-TXT אינן חולקות קהל
על שני סוגי הרשומות הללו עונים בתנאים שונים, והתייחסות אליהם כאל שירות אחד היא הטעות שהמאמר הזה נועד למנוע.
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
חוסר הסימטריה הזה מכוון ולא רשלנות. מיפוי שם לכתובת הוא בעל ערך מועט לזר, בעוד שמטא-נתוני תעודה מתארים את הזהויות ב-overlay שלכם. אל תעבירו הנחה משורה אחת לאחרת רק מפני שאותו תהליך עונה לשתיהן.
הוא עונה רק על המארחים של המגדלור עצמו
זה אינו פותר כללי למשרד, ל-VPC בענן או לאינטרנט הציבורי שלכם. המגדלור עונה ממידע על מארחים שניתן לו, וזו הסיבה שהתכונה חיה בצמתי מגדלור ולא בכל עמית.
כאשר שם נכשל ואין לכך שום קשר ל-overlay, מצאו את האזור והפותר שבאמת מחזיקים בו. ערבוב פותר overlay בתצורת ה-DNS הכללית של מארח מייצר כשלים שנראים אקראיים, כי שמות אחדים נפתרים ואחרים אין מי שעונה עליהם.
שימו לב גם אל נקודת האתחול של bootstrap. שם מארח שמשמש להגעה למגדלור הראשון חייב להיפתר בנתיב רגיל לפני שהגילוי יוכל להסתמך עליו, ולכן בעיית הביצה והתרנגולת כאן נראית בדיוק כמו overlay שבור. הוא אפילו מדווח באותה דרך: עמית שלעולם לא עולה ואין סיבה ברורה. בדקו פענוח שמות לפני שאתם נוגעים בתעודות, כי הסדר הזה תופס אנשים שהתחילו בחצי הקשה יותר.
בדקו את כתובת הכריכה ואז בדקו מבחוץ
lighthouse.dns.host ו-lighthouse.dns.port קובעים היכן השירות האופציונלי מאזין. עברו על הערכים האלה יחד עם חומת האש של המארח ומדיניות הרשת, כי כתובת כריכה היא הצהרת כוונה ולא בקרת אבטחה כשלעצמה.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortשאלו מהרשתות שאתם מתכוונים לאפשר, לא מהמגדלור עצמו. חיפוש מוצלח במגדלור מוכיח שהתהליך רץ ואינו אומר לכם דבר על מה שמארח חיצוני יכול לשאול, וזו השאלה שבאמת חשובה.
חשפו אותו בכוונה
שמות ומטא-נתוני תעודה הם מידע תפעולי שימושי, והשימושיות חותכת לשני הכיוונים. החליטו אם המאזין אמור להיות ל-overlay בלבד, אילו סוגי רשומות יורשו ומי בודק את התצורה כשהיא משתנה.
ואז כתבו זאת לצד הגדרות המגדלור. האדם הבא שינפה כשל פענוח יניח אחרת שהשירות תמיד היה שם. הוא גם יניח שהוא תמיד היה נגיש מכל מקום שבו במקרה הוא בודק. פסקה אחת שמתעדת את כתובת הכריכה, הרשתות המורשות וסוגי הרשומות חוסכת לאדם הזה אחר צהריים וחוסכת לכם הודעה ששואלת למה משהו השתנה.