Defaults.Exposed › תיקונים › הגדרת שרתי שמות (גיוון ו-SOA)

כיצד לתקן הגדרת שרתי שמות (גיוון ו-SOA)

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

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

מה זה יכול לעלות לכם

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

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

מה זה, בשפה פשוטה

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

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

1. גיוון — האם יש לך לפחות שני שרתי שמות, ואם הם יושבים על חלקים נפרדים באמת של הרשת, כך שהפסקה בודדת לא יכולה להשתיק את כולם בו-זמנית?
2. רשומת SOA — רשומת “סמכות התחלה” קטנה שמחזיקה ערכי זמן השולטים בכמה זמן שאר האינטרנט סומך על תשובות ה-DNS שלך ושומר אותן במטמון. לבלבל את הטיימרים וכל שינוי שאתה מבצע לוקח יותר זמן להגיע לעולם.

אף אחד מהם לא מרגש. שניהם יסודות. כשהם נכונים אתה לעולם לא חושב עליהם; כשהם שגויים, אתה גלה זאת ברגע הגרוע ביותר.

מה זה יכול לעלות לך

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

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

• שינויים שלא נקלטים. אתה מחליף מארחי אינטרנט, עובר ספקי אימייל, או צריך להפנות תנועה בחפזה. טיימר “רענון” או “פוג” שגוי ברשומת SOA שלך אומר לשרתי DNS אחרים להמשיך להגיש את התשובה הישנה שלך לימים. חצי מהלקוחות שלך נוחתים באתר החדש, חצי באתר המת; אימייל מסוים זורם לספק הישן, אחר לחדש. השינוי שעשית לפני שעה עדיין לא נגמר.

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

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

מה זה בעצם

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

הערה לקורא הטכני: הבדיקה שלנו סופרת את רשומות ה-NS שלך ואז מסתכלת על כמה גיוון רשתי אמיתי יושב מאחוריהן. האות הראשי הוא הפיזור של בלוקי רשת IP נבדלים שאליהם מפנים שרתי השמות (בערך טווחים /16 ל-IPv4 ו-/32 ל-IPv6), עם מספר שמות ספקים נבדלים כאמצעי גיבוי. זה מאשר בכוונה ספקי Anycast hyperscale — Cloudflare, Google, AWS Route 53, Azure DNS — שמכריזים על זהות רשת אחת מנתיבי ניתוב נפרדים רבים ברחבי העולם ולכן מספקים גיוון אמיתי אפילו ממותג בודד. פחות משני שרתי שמות מנקד אפס בבדיקה זו ומטופל כחומרה גבוהה, כיוון שזוהי נקודת כשל בודדת בלתי מוגנת לכל הדומיין.

רשומת SOA. לכל אזור DNS יש בדיוק רשומת Start of Authority אחת. היא שמה את שרת השמות הראשי ואת איש הקשר המנהלי, מכילה מספר סידורי שמגדיל עם כל שינוי, ו — החלק שחשוב לעסק שלך — מחזיקה ארבעה טיימרים:

• Refresh — כמה עתים שרתי שמות משניים בודקים מחדש את הראשי לשינויים. טווח טוב: בערך 1 עד 24 שעות (3,600–86,400 שניות).
• Retry — כמה מהר לנסות שוב אם רענון נכשל. טווח טוב: בערך 5 עד 60 דקות (300–3,600 שניות).
• Expire — כמה זמן שניוניים ממשיכים להגיש את הרשומות שלך אם הם לא מגיעים לראשי בכלל. טווח טוב: בערך 1 עד 4 שבועות (604,800–2,419,200 שניות).
• Minimum TTL — הרצפה לכמה זמן תשובות (כולל תשובות “שם זה לא קיים”) נשמרות במטמון. צריכה להיות ערך חיובי נבון; 300 שניות הוא בחירה נפוצה.

מה נראה “טוב”: SOA שקיימת, יש לה איש קשר מנהלי חוקי, ומחזיקה טיימרים בתוך טווחים אלה. ערכים מחוץ לטווחים אינם קטלניים — אבל הם מאטים את השינויים שלך (טיימרים ארוכים מדי) או טוענים את שרתי השמות שלך שלא לצורך (קצרים מדי). SOA חסרה או שבורה באמת היא המקרה החמור יותר.

כיצד לתקן (חינם, ~15 דקות)

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

שלב 1 — ודא שיש לך לפחות שני שרתי שמות על תשתית מגוונת.

1. בדוק מה יש לך היום. הרץ dig NS yourdomain.com (או השתמש בכל כלי “בדיקת DNS” מקוון) ורשום את שרתי השמות. שניים או יותר הוא המינימום.
2. אם יש לך רק אחד, או שניהם על מארח בודד קטן, עבור את ה-DNS שלך לספק שנותן לך יתירות כברירת מחדל. כמעט כל ספק רציני עושה זאת:
   • Cloudflare — מקצה שני שרתי שמות שפרושים ברשת Anycast הגלובלית שלו אוטומטית כשאתה מוסיף דומיין.
   • AWS Route 53 — כל אזור מתארח מקבל ארבעה שרתי שמות על פני רשתות Route 53 נפרדות.
   • Google Cloud DNS / Microsoft 365 / Azure DNS — גם מקצים שרתי שמות מרובים על תשתית עצמאית.
3. לעבור, הגדר את שרתי השמות של הדומיין שלך אצל הרשם שלך (איפה שקנית את הדומיין — כמו GoDaddy, Namecheap) לאלה שספק ה-DNS החדש שלך נותן לך. שינוי זה יכול לקחת 24–48 שעות להתפשט לחלוטין.
4. לחוסן חגורה-וחוגרות, עסקים גדולים יותר או בסיכון גבוה יכולים להריץ DNS משני מספק עצמאי שני (כמו Cloudflare + Route 53, או NS1 + Cloudflare). לרוב העסקים הקטנים זה אופציונלי — ספק בעל מוניטין בודד כבר נותן לך יתירות cross-network אמיתית.

שלב 2 — בדוק (ואם נדרש, תקן) את טיימרי SOA שלך.

1. הרץ dig SOA yourdomain.com ורשום את ערכי refresh, retry, expire ו-minimum-TTL.
2. השווה אותם מול הטווחים למעלה. ברוב המכריע של המקרים, ספק ה-DNS שלך כבר הגדיר ברירות מחדל נבונות ואין מה לעשות.
3. אם ערך מחוץ לטווח, תקן אותו היכן ש-DNS שלך מתארח:
   • על ספקים מנוהלים (Cloudflare, Route 53, Google, Azure) ה-SOA מטופלת ברובה עבורך; בדרך כלל מתאם אותה דרך הגדרות ה-DNS של הספק או תמיכה ולא עורך ידנית.
   • על שרת שמות מריץ-עצמי (BIND, PowerDNS) ערוך את שורת SOA בקובץ האזור ישירות וטען מחדש את האזור — תוך זכירה להגדיל את המספר הסידורי כדי שהמשניים יקלטו את השינוי.
4. לאחר כל שינוי, הרץ מחדש את הבדיקות כדי לאשר שגם רשימת שרתי השמות וגם טיימרי SOA נראים נכון.

טעויות נפוצות

• התייחסות ל”שני שמות” כ”שתי רשתות.” שני שמות שרת שמות שמתפנים לאותה קופסה או מדף הם נקודת כשל בודדת בתחפושת. מה שחשוב הוא נתיבי רשת עצמאיים, לא ספירת שמות.
• הנחה שיותר תמיד טוב, ללא גיוון. חמישה שרתי שמות כולם על מארח שברירי בודד אינם בטוחים יותר מאחד. גיוון מנצח כמות.
• הגדרת טיימרים אגרסיבית מדי. הפחתת refresh SOA או minimum-TTL ממש לאפס “כדי לעשות שינויים מיידיים” רק פוגעת בשרתי השמות שלך ועלולה להחמיר הפסקות, עם מעט תועלת אמיתית. ברירות מחדל נבונות כבר מאזנות בין מהירות לעומס.
• הגדרת expire נמוך מדי. אם משניים מפסיקים להגיש את האזור שלך מוקדם מדי במהלך הפסקת ראשי, הפוגה שניתנת לשחזור הופכת להפסקה מלאה. שמור expire בטווח השבועות.
• עריכת אזור ביד ושכחת המספר הסידורי. על שרתי שמות מריצי-עצמם, משניים קולטים שינויים רק כשה-SOA סידורי מגדיל. שנה רשומות אבל השאר את הסידורי לבד והתיקון שלך לא מתפשט אף פעם.
• השאיר DNS על ברירת המחדל הבסיסית של רשם הדומיין. ה-DNS המובנה של רשמים מסוימים הוא הגדרה בודדת מינימלית. העברת DNS לספק אמיתי בדרך כלל נותנת לך יתירות וטיימרי SOA נבונים בצעד אחד.

שורה תחתונה

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

שאלות נפוצות