מדריך להאצלת תתי דומיינים בלי לאבד שליטה

תת-דומיין אינו חייב להיות עוד רשומת DNS קטנה שמצטברת באזור הראשי. כשמעניקים לצוות, ללקוח או למערכת חיצונית אחריות מלאה על `api.example.co.il` או על `customer.example.co.il`, נדרש גבול תפעולי ברור. מדריך להאצלת תתי דומיינים נועד בדיוק למצב הזה: חלוקת אחריות בין אזורי DNS בלי לתת גישה מיותרת לדומיין הראשי ובלי לייצר תלות בצוות אחד שמחזיק הכול.

האצלה נכונה מאפשרת לצוות DevOps לנהל סביבת ייצור, לסוכנות לנהל נכס לקוח, או לספק SaaS לאמת ולהפעיל שירות - בעוד הבעלות והשליטה בדומיין ההורה נשארות במקום הנכון. זו לא פעולה קוסמטית בממשק DNS. זו החלטת ארכיטקטורה, הרשאות ואחריות.

מהי האצלת תת-דומיין בפועל?

האצלת DNS היא העברת הסמכות לתת-אזור DNS נפרד. במקום שהאזור `example.co.il` יכיל ישירות את כל הרשומות עבור `app.example.co.il`, הוא מפנה באמצעות רשומות NS לשרתי השמות שאחראים על תת-הדומיין. מאותו רגע, השרתים שהוגדרו עבור `app.example.co.il` הם המקור הסמכותי לרשומות שבתוכו: `www.app.example.co.il`, `api.app.example.co.il`, רשומות MX, TXT וכל מה שנמצא תחת אותו ענף.

חשוב להבחין בין האצלה לבין הפניה או רשומת CNAME. רשומת CNAME מפנה שם אחד לשם אחר, אך לא מעבירה אחריות על אזור DNS שלם. היא גם אינה מאפשרת לצוות אחר לנהל עצמאית רשומות מתחת לאותו שם. האצלה, לעומת זאת, יוצרת הפרדת אחריות אמיתית באמצעות NS records.

דוגמה פשוטה: הדומיין הראשי הוא `agency.co.il`. הסוכנות מפעילה פורטל נפרד לכל לקוח תחת `client1.agency.co.il`. אם הלקוח או צוות המוצר שלו צריכים לנהל אימותי דוא"ל, endpoints, רשומות אימות וסביבות שונות בלי לבקש שינוי בכל פעם, אפשר להאציל את `client1.agency.co.il` לשרתי DNS ייעודיים. הסוכנות שומרת על השליטה ב-`agency.co.il`, והלקוח מקבל אוטונומיה רק בגבול שהוגדר.

מתי האצלה היא הבחירה הנכונה?

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

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

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

מדריך להאצלת תתי דומיינים: התהליך הנכון

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

1. מגדירים גבול בעלות ברור

בחרו שם שמייצג תחום אחריות, לא רק צורך רגעי. `dev.example.co.il`, `clients.example.co.il` או `eu.example.co.il` הם גבולות שקל להבין ולתעד. לעומת זאת, האצלת `mail.example.co.il` רק כי שירות דוא"ל ביקש שינוי נקודתי עלולה לייצר בעלות לא ברורה על אזור רגיש.

קבעו מראש מי רשאי לשנות את אזור האב, מי מנהל את אזור הבן, מי מקבל התראות על כשל ומהו נוהל האישור לשינויים. DNS הוא חלק מתשתית הייצור, גם כאשר השינוי נראה כמו עוד TXT record.

2. מכינים את אזור הבן לפני שינוי באזור האב

הגדירו אצל ספק ה-DNS של אזור הבן את ה-zone המלא עבור תת-הדומיין, כולל לפחות רשומות SOA ו-NS תקינות. לאחר מכן הוסיפו את הרשומות הדרושות לשירות עצמו: A או AAAA, CNAME היכן שמתאים, TXT לאימות, MX אם יש דוא"ל, ומדיניות DMARC אם האזור שולח הודעות.

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

3. מוסיפים רשומות NS באזור האב

באזור `example.co.il`, הוסיפו רשומות NS עבור `app.example.co.il`, שמפנות לשרתי השמות הסמכותיים של אזור הבן. לדוגמה, אם אזור הבן משתמש ב-`ns1.dns-team.net` וב-`ns2.dns-team.net`, שתי הרשומות יופיעו תחת השם `app` באזור האב.

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

4. מטפלים נכון ב-glue records כשנדרש

אם שרתי השמות של אזור הבן נמצאים בתוך אותו תת-דומיין או תחת הדומיין המואצל, נוצרת תלות מעגלית. למשל, אם רוצים להאציל את `app.example.co.il` ל-`ns1.app.example.co.il`, resolver לא יכול למצוא את כתובת השרת בלי להגיע קודם לאזור שהוא מנסה לפתור.

במקרה כזה נדרשות glue records - כתובות IP שמפורסמות לצד ההפניה כדי לשבור את המעגל. זה תרחיש טכני לגיטימי, אבל ברוב המקרים עדיף לבחור שרתי שמות מחוץ לאזור המואצל. פחות תלות עצמית, פחות סיכוי לתצורה שגויה, ופחות כאב ראש בזמן incident.

5. בודקים תשובות סמכותיות לפני שמכריזים שהעבודה הסתיימה

בדיקה דרך הדפדפן אינה בדיקת DNS. השתמשו בכלי שאילתה כדי לוודא ששרתי השמות של אזור האב מחזירים delegation תקינה, וששרתי השמות של אזור הבן מחזירים תשובה סמכותית לרשומה שנדרשת. בדקו גם את שרשרת הפתרון המלאה, לא רק resolver ארגוני שכבר מחזיק cache ישן.

בדיקות שכדאי לבצע כוללות שאילתת NS עבור תת-הדומיין, שאילתת SOA מול כל שרת שמות מואצל, ובדיקה של הרשומות הקריטיות לשירות. אם מדובר בשירות דוא"ל, בדקו MX, SPF, DKIM ו-DMARC. אם מדובר ב-API, בדקו את כתובות היעד ואת תעודת ה-TLS לאחר שהפתרון מתייצב.

TTL, קאשינג וזמן מעבר

DNS לא מתעדכן אצל כל משתמש באותה שנייה. TTL נמוך לפני מעבר יכול לקצר את תקופת אי-הוודאות, אבל TTL נמוך קבוע מגדיל את תדירות השאילתות ואת התלות בתשתית ה-DNS. אין מספר קסם שמתאים לכולם.

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

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

אבטחה והרשאות: ההאצלה לא מחליפה ממשל

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

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

DNSSEC מוסיף שכבה חשובה, אך מחייב תיאום. כאשר אזור האב והבן חתומים, יש לנהל DS record באזור האב ולוודא שהמפתחות והחתימות באזור הבן תקינים. DS שגוי או חתימה שפג תוקפה אינם "בעיה חלקית" - הם יכולים למנוע פתרון DNS לחלוטין אצל resolvers מאמתים. אם אין לכם נוהל מסודר לניהול מפתחות, אל תפעילו DNSSEC על אזור מואצל כאקט חד-פעמי בלי בעלים טכני ברור.

תפעול בקנה מידה: כך נמנעים מכאוס

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

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

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

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