הגדרת DNS-Resolver: היכן נשברת רזולוציית השמות
רזולוציית שמות על השרת היא שרשרת: האפליקציה, המפענח המקומי, השרתים שמעליו ואזור השורש. בדרך כלל לא השרשרת עצמה נשברת, אלא החיבורים שבה: מטמון ריק לאחר הפעלה מחדש, כתובת upstream יחידה בהגדרה, ושאילתה ראשונה בלתי צפויה כצפוי.
בעת הפעלה מחדש של שירות רזולוציית השמות המטמון המקומי מתאפס, והשאילתה הראשונה לאחר ההפעלה מחדש עוברת במסלול מלא — מעבר רקורסיבי, אימות חתימות, ובמקרה של תשובה מקוצצת גם ניסיון חוזר בתעבורה אחרת.
באתחול האפליקציה יש עשרות שאילתות כאלה, הן נעמדות בתור, ותגובת השירות בשניות הראשונות נחלשת באופן מורגש. מטמון קבוע עם חימום בעת האתחול מבטל את האפקט: שמות נמסרים מהמסד המקומי, בעוד שהשרתים שמעלה רק נשאלים.
נקודת הכשל השנייה — הצמדות לכתובת upstream אחת: היא נכנסת ל-timeout או עונה לאט, וכל האפליקציה ממתינה, ולא רק שירות העזר.
השלישית — קובץ הגדרת רזולוציית השמות נדרס על ידי מנהל הרשת בהעלאה הבאה של הממשק, והמפענח המובנה תופס את הכתובת המקומית ומתנגש עם אזורים משלו ועם ספריות משותפות.
הבחירה בין מנגנון מובנה לבין שירות נפרד — systemd-resolved או Unbound — היא בחירה בין "עובד מהקופסה" ל"ניתן לניהול והגדרה": שירות נפרד נותן מטמון שלילי, כמה שרתי upstream עם בדיקת זמינות, הפרדת אזורים לפי דומיינים וסטטיסטיקת שאילתות. כיצד נסגרת כל אחת מנקודות הכשל הללו בעת הגדרת DNS-Resolver — בהמשך.
מטמון מקומי, עמידות בכשלים ופרטיות השאילתות
מטמון שמות מקומי משנה את פרופיל העומס של השירות כולו. במקום פנייה ברשת בכל קריאה, האפליקציה מקבלת תשובה מהזיכרון של המפענח, ופתרונות חוזרים של אותם שמות מפסיקים להיות תלויים ברשת החיצונית.
זמן התגובה של האפליקציה בפרופיל טיפוסי נקבע על ידי העיבוד, ולא על ידי המתנה לרזולוציה, ונשאר באותה רמה גם בעת עומס יתר על השרתים החיצוניים. מטמון שלילי עובד באותו אופן: שם שלא קיים אינו נשאל מחדש בכל קריאה.
עמידות בכשלים נבנית על שרתי רזולוציה חלופיים, ולא על תקווה שהספק לא ייפול. בהגדרה נרשמות כמה כתובות חיצוניות עם עדיפות ו-timeout: אי-זמינות של אחת מעבירה את השאילתה לבאה בתור, ולא מפילה את הרזולוציה כולה.
עמידות בפני אי-זמינות של הספק נותן גם המטמון עצמו — שמות ידועים ממשיכים להיענות כל עוד הערוץ החיצוני מושבת, והשירות אינו מאבד קישוריות עם מי שכבר החליף איתו תעבורה.
פרטיות היא תוצאה של אותו מטמון. החוצה יוצאת רק חלק מהשאילתות, והשאר נחסמות מקומית, ולכן צופה חיצוני רואה לא את התמונה המלאה של פניות השירות, אלא שבר ממנה. התעבורה אל השרתים החיצוניים נסגרת בהצפנה, כדי ששאילתות לא ייקראו בדרך.
מה בדיוק להתקין — שאלה של תרחיש. Unbound כמפענח רקורסיבי מלא נותן שליטה על אזורים, מגבלות וגודל המטמון, אך דורש תפעול עצמאי; systemd-resolved קרוב יותר לתפקיד של stub מקומי, זול יותר בתחזוקה ונשען כברירת מחדל על רוב השרתים.
שתי האפשרויות סוגרות מטמון, שרתי גיבוי ויציאת תעבורה החוצה — ההבדל הוא למי אתם מוסרים את השליטה על הרזולוציה.
אפשרויות לארגון רזולוציית שמות: השוואת מצבים
רזולוציית שמות על השרת כמעט אף פעם לא מסתכמת ב"להתקין מפענח ולשכוח": יש משמעות למי מחזיק בהגדרת הצומת וכיצד תתנהג הרזולוציה כששרת upstream יפסיק לענות.
שירות רזולוציה מובנה חי לצד תת-מערכת הרשת ומנוהל באותם אמצעים, בעוד ששרת מטמון נפרד הוא תהליך עצמאי עם קונפיג, מטמון וכללי העברה משלו.
בפועל בוחרים בין שלוש סכמות, וההבדל מתגלה לא במהירות של תשובה אחת, אלא באופן שבו את הסכמה מתחזקים, מנטרים ומאתרים תקלות. להלן — חלופות אמיתיות, שביניהן עומדת לרוב הבחירה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שירות רזולוציה מובנה | צומת בודד או מתחם קטן, שבו הרשת כבר מנוהלת על ידי מנהל המערכת | המטמון והסטטיסטיקה מוגבלים, אין מדיניות מדויקת לפי אזורים, וההתנהגות תלויה בבניית ההפצה |
| שרת מטמון נפרד | כמה צמתים, נדרש מטמון משותף ואזור מקומי משלו לשמות פנימיים | דורש קונפיג, ניטור ועדכון משלו — זהו שירות נוסף שצריך לעקוב אחריו |
| סכמה משולבת עם הפניית שאילתות | אזורים פנימיים מטופלים מקומית, חיצוניים עוברים לרזולוורים מהימנים שמעלה | מסלול השאילתה עובר שתי חוליות, איתור תקלות והפרדת אזורים מורכבים יותר |
קריטריון המפתח אינו "איזו אפשרות מודרנית יותר", אלא כמה צמתים יש לכם, האם נדרש אזור מקומי לשמות פנימיים, וכמה קל יהיה לכם למצוא את הסיבה כששם מסוים אינו נפתר. תארו את המתחם שלכם — נחזור עם הערכה ותוכנית מעבר.
שלבי היישום: מביקורת ההגדרות הנוכחיות ועד למסירה
סדר העבודות נבנה כך ששינוי המפענח לא יהפוך לתקלה: תחילה מתעדים את התמונה הנוכחית, אחר כך משנים. כל שלב מסתיים בארטיפקט — קונפיג, תרשים או דוח בדיקה, ולכן הפתרון נשאר משוחזר.
- ביקורת הגדרות השרת. אוספים מי וכיצד פותר שמות: ממשקים ומצבם, רשומות סטטיות, הפניות מותנות לאזורים פנימיים, דריסות, אילו שירותים פונים למטפל המקומי ישירות. בנפרד בודקים מארחים שבהם רשומה כתובת של צד שלישי — בדרך כלל דווקא הם יוצרים אי-התאמות לאחר המיתוג.
- תכנון הסכמה. משווים בין systemd-resolved ל-Unbound לפי המשימה: האם נדרש אימות חתימות, אזורים משלו, הפרדת שמות פנימיים וחיצוניים, מטמון נפרד לשירותים. מתעדים היכן תהיה נקודת הכשל וכיצד היא שורדת אי-זמינות של שרת upstream.
- סטנד. פורסים את ההגדרה בסביבה מבודדת ומשווים תשובות לסכמה הנוכחית לפי שמות קריטיים: אותן כתובות, אותם זמני חיים של רשומה, התנהגות צפויה בעת אי-זמינות המקור.
- תוכנית נסיגה. קבצי המקור ופרמטרי ההרצה נשמרים לפני העריכה, וסדר החזרה מתואר שורה-שורה. מעבירים צומת אחד בכל פעם, ולא את כל הצי בבת אחת — בעת חריגה החזרה אורכת דקות.
- מיתוג. מחליפים את מטפלי השמות המערכתיים, מפעילים מחדש את השירות ועוקבים אחרי שיעור הכשלים וזמן התגובה. עלייה בפניות לשרתים חיצוניים — סימן ראשון שהמטמון לא התחמם.
- בדיקה לאחר המיתוג. שאילתות בקרה באזורים פנימיים וחיצוניים, התנהגות המטמון, תגובה להפעלה מחדש של השירות ולהינתקות מהקשר עם שרת upstream. התוצאות מתועדות בדוח.
- מסירה. הקונפיגים עוברים לריפוזיטורי, ולצידם — תרשים, מדיניות עדכון אזורים והוראה קצרה לתורן: מה לבדוק ומה להחזיר לאחור.
תארו את סכמת רזולוציית השמות הנוכחית — נחזור עם הערכה ותוכנית עבודה.
הגדרות, תרשימי אזורים ותקנות: מה נשאר אצלכם
המפענח מפסיק להיות קופסה שחורה כשכל ההגדרה שלו נמצאת בריפוזיטורי ומתוארת במילים. אנחנו מוסרים לא אוסף של קבצים "קסומים", אלא מערכת עבודה: לפיה המהנדס שלכם ירִים צומת כזהה מאפס, יחזור על ההגדרה בסטנד ויחזיר לאחור שינוי, בלי להתמצא בהערות של אחרים.
- קבצי הגדרה — ההגדרה הראשית וקבצי דריסה נוספים במערכת בקרת גרסאות, עם היסטוריית עריכות ותיאור משמעותי לכל שינוי.
- תרשים אזורים והפניות — אילו דומיינים נפתרים מקומית, אילו עוברים לרזולוורים שמעלה, היכן מוצבות הפניות מותנות לאזורים פנימיים וכיצד זה קשור לדומיין החיפוש.
- כללי גישה — מאילו תת-רשתות מותרות שאילתות לפורטים של השירות, למי פתוח מעבר רקורסיבי, מה סגור החוצה ומדוע.
- תקנון תחזוקה — תדירות בדיקת האזורים, עדכון רמזי השורש, רוטציה של רשומות השירות והפעלה מחדש של השירות בלי השבתה.
- סדר פעולות בעת תקלה — מהיכן מתחילים אבחון, כיצד עוברים למפענח חלופי, באיזו פקודה מחזירים את ההגדרה לגרסה התקינה האחרונה.
- תיעוד התשתית — כתובות ותפקידי הצמתים, נקודות ניטור, אחראים, קישורי המפענח לשאר השירותים.
- מערך בדיקות לאחר עריכה — זמן תגובה, שיעור כשלים, זמינות אזורים פנימיים; ההתראות מקושרות בדיוק למדדים הללו. החבילה נשארת אצלכם יחד עם הסבר בשיחת וידאו: מה לבדוק לאחר כל עריכה ולפי אילו סימנים ניכרת ירידת ביצועים. התפעול לא צריך להיות תלוי באדם אחד.
דוגמה ליישום: רזולוציית שמות הפסיקה להיות תלויה בספק
צי השרתים של הלקוח — כ-60 מכונות בשני אתרים — פנה לשמות ישירות לרזולוורים של הספק, ובחלק מהמארחים פעל מטמון מקומי מהפצה, וההגדרות התפצלו עם הזמן. שיעור השאילתות הכושלות בשיא עמד על כ-4%, ושירות האפליקציה, שבאתחול מפענח עשרות שמות פנימיים, הגיב כפול מהרגיל.
מה שינינו
הרמנו מפענח רקורסיבי על Unbound והצבנו שני צמתים בלתי תלויים באתרים שונים — כשל של כל אחד מהם כבר לא עוצר את רזולוציית השמות. מטמונים מקומיים במארחים כובו, המכונות הועברו לשתי כתובות דרך פרמטר מנוהל, והאזורים הפנימיים תוארו בנפרד מהחיצוניים. זמינות הצמתים, זמן התגובה ושיעור השגיאות הועברו לניטור עם בדיקות אוטומטיות.
מדדים לפני ואחרי
- שיעור שאילתות כושלות: כ-4% בשיא → יציב מתחת ל-0.2%, כשל בודד נסגר בניסיון חוזר בצומת השני.
- זמן התגובה של שירות האפליקציה באתחול הצטמצם בחצי — בזכות המטמון ומסלול שאילתות צפוי.
- פניות בגין אירועים עם רזולוציית שמות: 8–10 בחודש → אחת לרבעון, וגם זו באזור פנימי.
נקודת כשל יחידה נעלמה: רזולוורים חיצוניים נותרו מסלול גיבוי, אך חדלו להיות מקור התשובות היחיד. בהמשך מפתחים את הסכמה — מוסיפים הפרדת אזורים לפי אתרים ובדיקות שלוכדות אי-התאמה בהגדרות לפני שהמשתמשים מבחינים בה.
מפענח מובנה או נפרד: מתי נדרש השני?
תשובה קצרה: שירות מובנה סוגר שרת בודד, ומופע נפרד נדרש כשמופיע צי מכונות, מתחם מבודד או דרישה לראות כל שאילתה. מפענח מובנה עולה יחד עם המערכת ומגיש מטמון לכל התהליכים המקומיים — זה מספיק כל עוד הגדרות הרשת אינן משתנות מתחתיו.
מפענח מובנה קורא פרמטרים ממנהל הרשת ודורס את שרתי ה-upstream בכל עדכון של כתובות. תיעוד השאילתות שלו משותף עם יומן המערכת, בלי פילוח לפי לקוחות, ואין במה להגביל את גודל המטמון — במארח עמוס זה הדבר הראשון שרוצים להעביר החוצה.
Unbound נפרד נותן אזורים מפורשים, דריסות מקומיות, מטמון עם חימום שמות פופולריים ויומן נפרד: רואים מי, מה ומתי שאל. העומס על השרת נעשה צפוי — התהליך חי תחת מגבלת משאבים משלו, ובצי מכונות מעבירים אותו לצומת ייעודי עם גישה לפי רשימת תת-רשתות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שירות מובנה | שרת בודד, רשת פשוטה | הגדרות נדרסות על ידי מנהל הרשת, אין יומן לפי לקוחות |
| מופע נפרד על אותו מארח | נדרשים אזורים מקומיים וניתוח שאילתות | מארח אחד — נקודת כשל אחת, חולק משאבים עם האפליקציות |
| צומת נפרד לצי מכונות | מטמון משותף לעשרות שרתים | נדרשים הגבלת גישה ובקרת זמינות |
| מפענח במתחם מבודד | שמות פנימיים לא אמורים לצאת החוצה | רק מקורות משלו ו-forwarder של ההיקף |
במתחם מבודד המפענח בכלל לא יוצא החוצה: אזורים פנימיים נמסרים על ידי מקור מהימן, חיצוניים — על ידי forwarder בהיקף. תשובות עוברות רק במסלולים מורשים, ודליפה של שמות פנימיים דרך רזולוורים ציבוריים נמנעת.
ספקות של מהנדס: מטמון, הצפנה, החזרת הגדרות לאחור
לפני תחילת העבודות מהנדסים שואלים את אותה קבוצת שאלות: מה יקרה למטמון שכבר נצבר, האם שאילתות יוצאות החוצה בטקסט גלוי, האם רזולוציית השמות תישבר בשירותים שכבר פרוסים, וכיצד לחזור לסכמה הקודמת אם משהו ישתבש. להלן — תשובות קצרות לכל סעיף.
מה לעשות עם רשומות מיושנות במטמון?
המטמון חי לפי זמן החיים של הרשומה, ולכן אזור ישן לאחר מעבר שירות — עניין שבשגרה. יש לנו איפוס מפורש של המטמון, ולפני שינויים אנחנו מנמיכים את זמן החיים של הרשומות ומחזירים את הערך הקודם לאחר הבדיקה.
האם שאילתות מועברות החוצה בהצפנה?
ניתן לעטוף שאילתות יוצאות בתעבורה מוצפנת, כדי שהספק וצמתי הביניים לא יראו שמות. בתוך ההיקף המפענח עונה בפורט רגיל — אחרת קונטיינרים ושירותים ישנים יפסיקו לפתור שמות.
תאימות עם שירותים שכבר עובדים?
לפני ההחלפה מרכיבים רשימה של מי וכיצד שואל DNS: שירותי מערכת, קונטיינרים, VPN, דומיינים. הפרדת אזורים — פנימיים מקומית, חיצוניים החוצה — מוגדרת לפני המיתוג, ולכן השירותים רואים שמות מוכרים.
כיצד מתבצעת החזרת ההגדרות לאחור?
ההגדרות נמצאות במערכת בקרת גרסאות, היישום וההחזרה לאחור — במיתוג למערך הקבצים הקודם. המפענח הישן לא נמחק כל עוד הסכמה החדשה לא עבדה תחת עומס; החזרה אורכת דקות ואינה דורשת אתחול של השרת.
נדון במשימה: כיצד אנחנו מגיעים לתוכנית יישום
כדי שההערכה תישען על עובדות ולא על השערות, נדרש מינימום של נתוני קלט: כיצד בנויים המתחמים, מי וכיצד פותר שמות כעת, ואילו דרישות מוצבות כלפי בידוד השאילתות. בדיוק זה קובע את הבחירה בין מפענח מטמון מקומי לבין Unbound עם אזורים משלו והעברה למתחמים סגורים.
מה אנחנו מבקשים בקלט:
- תרשים המתחמים: מקטעי הרשת, היכן נמצאים הצרכנים, כיצד התעבורה עוברת ביניהם.
- רשימת השרתים והתפקידים: היכן מפענח מקומי, היכן מטמון, היכן forwarder.
- דרישות לבידוד: אילו אזורים לא אמורים לצאת לרזולוורים חיצוניים, האם נדרש DNSSEC וכיצד לטפל בתשובות עם שגיאת חתימה.
- מצב נוכחי: הגדרות עבודה, אופן הפצת resolv.conf, ניהול דרך מנהל הגדרות.
- חלון מיתוג, זמן אי-זמינות מותר לרזולוציית שמות, הרשאות גישה ואחראים על הקבלה.
בתמורה אתם מקבלים תוכנית יישום לפי שלבים עם קריטריוני מוכנות לכל אחד, היקף עבודה עם הפרדת אחריות, והרכב ארטיפקטים: הגדרות, קבצי unit, מדיניות מטמון והעברה, ותרשים החזרה לאחור למפענח הקודם.
בנפרד נתאם את סדר מיתוג הצרכנים והבדיקות שאחריו, וכן תקנון מסירה לתפעול — מדדים, התראות, הוראה לתורן. תארו את המשימה — נחזור עם הערכה, תוכנית והיקף עבודה.