שרת DNS (Bind/PowerDNS): התקנה והגדרה מלאה

שרת DNS כנקודת כשל יחידה: היכן בדיוק זה נשבר

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

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

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

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

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

השלישית — היעדר שכפול: עדכון, תחזוקה או העברה של צומת דורשים חלון השבתה, כי אין לאן לעבור. הגישה אינה תלויה במימוש — גם Bind וגם PowerDNS מתמודדים באותה מידה רע עם צומת יחיד ועריכת אזורים ידנית.

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

מה נותן שרת DNS מנוהל: מהירות, עמידות, שליטה

שרת DNS מנוהל — זה לא סיפור של «התקנו ושכחנו». את הבסיס אנו בוחרים לפי המשימה: BIND נוח כאשר האזורים חיים בצורת טקסט ונערכים לעתים רחוקות, לעומתו PowerDNS — כאשר הרשומות נשמרות במסד נתונים ומשתנות אוטומטית. בהמשך — שלושה אפקטים שנראים במטריקות.

הפחתת זמן התגובה של רזולוציית שמות

רזולבר מטמון מחזיר שאילתות חוזרות מהמטמון המקומי בלי לצאת לרשת החיצונית: במטמון מחומם שיעור הפגיעות נשמר ברמה של 90–95%, וה-TTL של אזורים פנימיים נבחר לפי תדירות השינויים בפועל. פניות ישירות לשרתים סמכותיים במקום שרשרת ארוכה של רזולברים זרים מסירות שלבים מיותרים ברזולוציה. זמן התגובה מתקצר פי כמה, ונעלם סוג הכשלים «האפליקציה ממתינה לתשובה של רזולבר זר».

עמידות בפני כשל צומת

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

רזולוציית שמות נשמרת בטווח הזמינות היעד של 99.99%, וסוג הכשלים «האתר חי, אבל הדומיין לא נפתר» נעלם לגמרי.

שליטה בתעבורה

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

סמכותי, מטמון ומצב העברה: מה לבחור

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

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

הפרדת אזורים והאצלה

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

הגנה על המטמון מפני זיוף תשובות

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

שלבי יישום: ממלאי אזורים ועד מסירה לתמיכה

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

מלאי ותרשים אזורים

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

בדיקה בסביבה מבודדת לפני העלאה

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

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

תצורות, תרשימי אזורים ונהלי עדכון רשומות

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

תרשימי אזורים ותפקידי גישה

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

נהלי עדכון ושחזור

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

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

מקרה בוחן: כיצד הסרנו נקודת כשל יחידה וצמצמנו השבתות

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

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

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

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

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

במה שונה מצב מטמון ממצב סמכותי?

שרת סמכותי — מקור האמת עבור האזור שלו: רשומות (A, AAAA, MX, TXT, SOA, NS) הוא שומר אצלו ומחזיר בדיוק בצורה שבה הוזנו. אחרי תשובה הוא אינו הולך לשום מקום: אין רשומה — כלומר NXDOMAIN, ולא שאילתה לשכנים. שינויים נכנסים לתשובה רק דרך עריכת האזור וטעינתו מחדש עם התראה לשרתים משניים.

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

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

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

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

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

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

ספקות נפוצים: עומס, שכפול, אזורים וגישה

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

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

כיצד שכפול אזורים מביא שינויים לכל הצמתים?

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

מה יקרה עם אזורים שכבר פעילים בעת העברה?

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

כיצד מופרדות הרשאות הגישה לאזורים?

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

האם אתם מגנים מפני זיוף תשובות?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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