הגדרת DNS של Windows Server: AD, אזורים, הפניה

הגדרת DNS Windows Server: היכן לרוב נשבר תרגום השמות

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

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

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

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

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

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

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

מה נותן DNS מנוהל: מהירות, יציבות, שליטה

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

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

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

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

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

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

אפשרויות פריסה של שירות השמות: השוואת גישות

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

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

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

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

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

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

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

1. ביקורת אזורים ורשומות. מייצאים אזורי forward ו-reverse, מוצאים כפילויות ורשומות A/CNAME מתנגשות, רשומות בלי בעלים, רשומות סטטיות שמתנגשות עם הקצאת כתובות דינמית.
2. סכמת תרגום שמות. קובעים אילו אזורים ראשיים, מה מואצל, לאן הולכות בקשות לדומיינים חיצוניים, היכן דרוש forwarding. הסכמה מתעדת מי שואל את מי.
3. הגדרה. מאחדים את אחסון האזורים והשכפול לצורה אחידה, מפעילים עדכון מאובטח של רשומות, קובעים זמני חיים וניקוי רשומות מיושנות.
4. בדיקה בתקלות. מכבים בתור את בקר הדומיין ושרת ה-forwarding, בודקים אם שמות מתורגמים מה-cache וכמה מהר חוזרת הגישה. בנפרד בודקים אתחול לקוחות.
5. נוהל שינויים. מתארים מי מוסיף רשומות, עם איזה זמן חיים, כיצד מבוטל שינוי שגוי והיכן זה מתועד ביומן.
6. מסירה לתמיכה. מוסרים סכמת אזורים, מפת שרתים, הוראות לפעולות טיפוסיות ונקודות הסלמה, ובנוסף מגדירים ניטור תגובה.

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

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

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

• ייצוא תצורת אזורים: קבצי אזורי forward ו-reverse, פרמטרי SOA עם זמני עדכון, רשימות רשומות — בצורה שמתאימה להעברה לשרת אחר בלי שחזור ידני.
• מפת תרגום שמות: סכמה של הקשר בין האזורים לדומיין Active Directory, סדר הפנייה של לקוחות לשרתים, forwarding לשמות דומיין חיצוניים ואזור stub עבור אזור השורש.
• מדיניות גישה לרשומות: אילו מנהלים ומחלקות יכולים לשנות רשומות, היכן מותר עדכון דינמי והיכן רק ידני.
• סכמת שכפול ועמידות: אילו שרתים מחזיקים עותקים של אזורים, כיצד לקוחות מתחלפים כשהשרת הראשי אינו זמין.
• נוהל שינויים: סדר עריכת רשומות, חלונות עבודה, מי מאשר, כיצד מתועדת גרסת תצורה וכיצד מבוצע rollback.
• הוראות לצוות התמיכה: פניות טיפוסיות בנושא שמות ודומיין, רצף האבחון וסימנים שבהם השאלה מועברת לצוות התשתיות.
• פרוטוקול קבלה: סט בדיקות לאחר שינויים — תרגום שמות מרשתות משנה שונות, זמינות כתובות חיצוניות, תקינות אזורי reverse.

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

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

הלקוח — רשת מבוזרת מכמה אתרים: בקרי דומיין ושרתי DNS תחת Windows Server, אזורים המשולבים ב-Active Directory, וכן דומיינים חיצוניים שתורגמו דרך forwarding. העברות מותנות ואזורים בכל אתר נוהלו ידנית, ולכן כשהקשר לאתר המרכזי נקטע, בקשות נכנסו ל-timeout במקום לעבור לשרת גיבוי.

מה הראו המדדים לפני

שיעור הבקשות הכושלות בשעות שיא הגיע ל-6–9%: משתמשים לא הצליחו לפתוח ספריות משותפות ופורטלים פנימיים. השחזור לאחר כשל אתר ארך 40–60 דקות של עבודה ידנית, ומספר עריכות האזורים והרשומות הצטבר ל-12–18 בחודש — מחציתן בוצעו כבר לאחר התקלה.

מה שינינו

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

לאחר השינויים שיעור הבקשות הכושלות נשמר בטווח 0.2–0.5%, וזמן השחזור לאחר כשל אתר התקצר לכמה דקות — המעבר לשרת גיבוי מתבצע בלי התערבות מהנדס. עריכות ידניות של אזורים נותרו 1–2 בחודש, וגם הן מתוכננות.

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

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

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

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

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

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

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

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

ספקות טכניים: שכפול, אמון, rollback שינויים

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

מה עם אמון בין דומיינים ו-forwarding?

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

אילו פורטים לפתוח בין האתרים?

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

כיצד מבוטל שינוי?

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

נדון במשימה שלכם: במה נתחיל ומה להכין

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

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

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