הגדרת DNSSEC: היכן נשברת שרשרת האמון
DNSSEC עונה על שאלה צרה אחת: האם התשובה הגיעה מהאזור עצמו או מתווך. בלעדיו, resolver מאגר בולע תשובה מוחלפת, הלקוח מגיע לכתובת זרה, ומבחוץ אין כל הבדל מעבודה תקינה של השירות — עד לרגע שבו יתחילו לאסוף הרשאות גישה בכתובת הזו.
אימות האותנטיות של תשובות DNS נשען על שרשרת האמון של האזור. האב מחזיק רשומת DS עם טביעת האצבע של מפתח החתימה של אזור הבן, ה-resolver משווה לפיה את החתימה שהתקבלה ומגריר את האמון מטה בהיררכיה עד הדומיין עצמו. קרע בכל חוליה — והתשובה נחשבת לא מאומתת, גם אם כל הנתונים נמצאים.
הניתוק הנפוץ ביותר — אי-התאמה בין מפתחות החתימה אצל הרשם ובאזור. מחליפים מפתחות, אך את רשומת ה-DS מפרסמים באיחור או עם טביעת האצבע הקודמת, וצריך להמתין לעדכון בדיוק כל עוד רשומה חיה במטמון של האב.
סיבה נפרדת — חתימה שפג תוקפה: האזור נחתם מראש עם מרווח, ואם החתימה מחדש נעצרה, הוולידציה נשברת בלי שום שינוי בקונפיגורציה.
האבחון מסתבך מכך שלא כולם רואים את כשל פתרון השמות. resolvers מאמתים משיבים בסירוב ואינם מחזירים את האזור כלל, בעוד שאלה שאינם מאמתים ממשיכים להחזיר אותו מהמטמון — חלק מהלקוחות וחלק מהניטור נשארים ירוקים. resolvers ציבוריים בודקים בקפדנות רבה יותר מאלה הביתיים, ולכן הבעיות מתגלות אצלם תחילה.
בהמשך נבחן כיצד זה נסגר: מסדר פרסום ה-DS בעת החלפת מפתחות ועד לבדיקות שתופסות את קרע השרשרת לפני שהמשתמש יראה אותו.
מה נותן אזור חתום: אפקט בגדלים מדידים
אזור חתום מעביר את אימות האותנטיות של התשובה לרגע הוולידציה: ה-resolver משווה את חתימת הרשומה עם שרשרת האמון ובמקום נתונים מזויפים מחזיר סירוב. שיעור התשובות הכוזבות שמגיעות למשתמש יורד לאפס — החלפה בדרך בין המטמון לאזור השורש כבר אינה מניבה תוצאה. את אזור השורש חותמת ICANN, ולכן שרשרת האמון אינה נשברת באף רמה של הדומיין.
זמן חקירת האירועים מתקצר פי כמה, כיוון שעובדת ההחלפה מפסיקה להיות נושא להשערות.
בעבר היה צריך להשוות תשובות מנקודות שונות ומספקים שונים כדי להוכיח את העובדה עצמה; כעת מספיק לראות אי-התאמה בחתימה — ומיד ברור היכן הסיבה: חתימה שפג תוקפה, אי-סנכרון מפתחות אצל הרשם או עותק מיושן של האזור. הניתוח מתבצע בדקות, ולא בשעות של התכתבות עם כמה גורמים.
בנפרד נעלם סוג של כשלים בסגנון "האתר נפתח, לפעמים לא": רשומה מורעלת במטמון ביניים אינה יכולה להיות מוחזרת כתקפה. נותרות סירובי ולידציה מפורשים — הם נראים בלוגים ומנותחים לפי קוד, במקום הפניה שקטה לכתובת זרה או רשומת דואר מוחלפת.
יציבות פתרון השמות עוברת מקטגוריית התלונות למטריקה: שיעור הוולידציות המוצלחות נשמר יציב ואינו צונח בשעות עומס.
המדידות נלקחות לפני ואחרי הפעלת החתימה באותן נקודות: שיעור התשובות שנדחו בידי המאמת, מספר הפניות "לא נפתח", הזמן מהאות הראשון ועד סגירת האירוע. זהו אפקט שנראה בדוח, ולא רק בתיאור התקן.
אפשרויות חיבור ההגנה: השוואת מצבים
תוכניות הפעלת DNSSEC נבדלות זו מזו במקום שבו נמצאים המפתחות ובמי מפרסם את רשומת ה-DS באזור האב. מכך תלויים גם עומס העבודה וגם אילו תקלות נשארות מחוץ לשליטתנו.
| תוכנית | מתי מתאימה | מגבלות |
|---|---|---|
| חתימה אצל הרשם | הדומיין כבר מנוהל בפאנל שלו, רשומות משתנות לעיתים רחוקות | זמינים רק הפרמטרים המוצעים: האלגוריתם, תוקף המפתחות וסדר ההחלפה נקבעים בידי הפלטפורמה; ה-DS מפורסם באמצעים שלה |
| חתימה מקומית של האזור | שרתים משלכם, הנפקת רשומות אוטומטית, דרישות לאחסון מפתחות | המפתחות, הגיבויים שלהם והניטור מוטלים עלינו; רשומת DS שגויה אצל הרשם הופכת את האזור לבלתי פתיר |
| הפעלה מדורגת לפי תת-דומיינים | אזורים גדולים ושירותים רבים, מעבר בלי לעצור את העבודה | חתימת אזור האב אינה מגנה על אזורי הבן עד שהם עצמם חתומים; תקופת המעבר מתארכת |
החלפת מפתחות — נהל נפרד בכל אחת מהתוכניות: המפתח החדש מפורסם מראש, ממתינים לתום תוקף הרשומות, לאחר מכן מחליפים את ההצמדה אצל הרשם, ורק אחרי כן מוציאים את המפתח הישן משימוש. אם מחליפים את סדר השלבים, חלק מה-resolvers ימשיכו לדרוש את המפתח הקודם ויפסיקו לראות את האזור.
עבור אזור בלי מערך DNS משלו, חתימה אצל הרשם היא בחירה הגיונית. אם יש רשומות רבות והן מונפקות אוטומטית, חתימה מקומית עם הפעלה מדורגת לפי תת-דומיינים נותנת שליטה על המפתחות ומעבר צפוי מראש.
סדר היישום: מביקורת האזור ועד למסירה
DNSSEC אינו הגדרה אחת, אלא שרשרת: אם טועים בסדר, האזור מפסיק להיות נפתר אצל חלק מהלקוחות, וזה לא מורגש מיד. לכן העבודה מתבצעת בשלבים, שבהם כל צעד מאומת בבדיקה, והפעלת חתימת האזור ופרסום המפתח אצל האב מופרדים בזמן. המעבר לשלב הבא — רק לאחר שהשלב הקודם מחזיר תשובות נכונות באופן יציב.
שלבים
- ביקורת אזור ה-DNS. עורכים מלאי של כל הרשומות ואזורי המשנה המואצלים, משווים עותקים של האזור בשרתים שונים, ומוצאים התנגשויות שבגללן החתימה תהפוך ללא תקפה.
- תוכנית ההאצלה ושרשרת האמון. קובעים מי מעביר את האזור לאב, היכן מפורסמים המפתחות וכיצד מאומת הקשר ביניהם — בלי זה, resolvers חיצוניים לא יקבלו את החתימה.
- הפעלת חתימת האזור. יוצרים מפתחות חתימה, קובעים את זמני הרוטציה שלהם ואת זמן החיים של החתימות במטמון, ומסנכרנים את האזור בין כל השרתים.
- מצב בדיקה. האזור כבר מוחזר עם חתימות, אך המפתח לא הועבר לאב: רואים שהתשובות נוצרות כראוי, ובמקביל הלקוחות אינם מושפעים.
- פרסום אצל האב. לאחר אימות הבדיקה מפרסמים את המפתח — מרגע זה האזור נחשב חתום, וחזרה לאחור אפשרית רק בפעולה מתואמת.
- בדיקה מ-resolvers שונים. מריצים שאילתות ל-resolvers ציבוריים, מקומיים ומבוזרים: התשובות מאומתות, אין סירובים, וההתנהגות זהה בכולם.
- מסירת הנהלים. מוסרים מסמך עם סדר רוטציית המפתחות, הפעולות בעת כשל בחתימה ונקודות הניטור, ומכשירים את הצוות על תרחישים אמיתיים.
מדיניות, מפתחות ותיעוד: מה נשאר אצלכם
איננו משאירים את DNSSEC קופסה שחורה: ההיגיון של חתימת אזורים, החלפת מפתחות ובדיקות מתועד בארטיפקטים, שלפיהם הצוות שלכם או קבלן אחר ימשיכו את העבודה בלי לפענח קונפיגורציה זרה. לאחר העלייה לאוויר נשאר אצלכם סט שמספיק לתחזוקה עצמאית.
- מפת האזורים ותת-הדומיינים — רשימת האזורים, נקודות ההאצלה שלהם וההתאמה לרשומות אצל הרשם: רואים היכן נגמרת האחריות שלכם ומתחיל האזור של הספק.
- תרשים שרשרת האמון — מאזור השורש ועד לרשומות החתומות, בציון היכן נשמרים מפתחות האב והבן וכיצד הם קשורים.
- מדיניות החלפת מפתחות — תוקף מפתחות החתימה ומפתחות חתימת המפתחות, סדר פרסום רשומה חדשה אצל הרשם, מי יוזם החלפה מתוכננת ומה לעשות בעת פגיעה באבטחה.
- הפרדת תפקידי גישה לאזור — מי מחליף מפתחות, מי רק רשומות, למי יש גישת קריאה; חשבון נפרד לעבודות חירום.
- נוהל בדיקות — מה ובאיזו תדירות משווים: תקפות החתימה, תוקף המפתחות, התאמת הנתונים אצל הרשם ובאזור עצמו.
- תיעוד תשתית ה-DNS — כתובות השרתים, תרשים הגיבוי, מקומות אחסון המפתחות וסדר השחזור מגיבוי.
- הוראות למקרה של אירוע — הסרת החתימה מהאזור שלב אחר שלב בעת תקלה וחזרה למצב עבודה בלי השבתת הדומיין.
כל סעיף מכסה סוג מסוים של כשלים: בלי מפת האזורים, החלפת מפתחות מתוכננת הופכת להשבתה שלא שמו לב אליה, ובלי נוהל בדיקות, חתימה שפג תוקפה מתגלה רק מתלונות הלקוחות.
מקרה בוחן: העברת אזור לחתימה בלי אובדן תעבורה
מצב התחלתי
לעבודה הגיע אזור פעיל: דומיין ראשי, כמה עשרות תת-דומיינים עבור דואר, API ושירותים פנימיים, תוקף הרשומות — מכמה דקות ועד יממה. האזור לא היה חתום, ולכן כל resolver ביניים יכול היה להחליף את התשובה, ומצד הבעלים הדבר לא התגלה כלל.
סיכון נפרד — ה-DS הראשון של הדומיין באזור האב: טעות בשרשרת האמון מכבה את כל הדומיין, ולא רשומה אחת. לכן לפני הפרסום נלקחו מדידות בסיס: זמן התגובה של השרתים המוסמכים, התפלגות השאילתות לפי סוגים ושיעור התעבורה מ-resolvers מאמתים.
מדידות ובדיקות ב-resolvers
הגרסה החתומה של האזור נבנתה על סביבת בדיקה נפרדת והועברה דרך בדיקות חיצוניות של השרשרת, כולל Google Public DNS. את ה-DS אצל הרשם פרסמנו רק לאחר מעבר נקי — הצעד אינו הפיך למשך זמן השווה לתוקף ההאצלה.
לאחר ההפעלה, שיעור התשובות עם שגיאת בדיקה נשאר אפס, העלייה בזמן התגובה הסתכמה באחוזים בודדים, ומספר הפניות "לא נפתח אצל כולם" לא עלה. החלפת המפתחות מוגדרת עם פרסום מוקדם: המפתח החדש מופיע באזור לפני שהוא מתחיל לחתום, ולכן הרוטציה והחזרה לאחור עוברות בלי השבתה.
סבב בקרה של resolvers ובדיקת השרשרת חוזרים על עצמם לפי לוח זמנים: האמון נשבר בשקט, ובלי בדיקה סדירה נודע על כך מהלקוחות.
הגדרת DNSSEC בעת החלפת רשם: מה לקחת בחשבון
כן, החלפת רשם כשמופעל DNSSEC עוברת בלי השבתה — בתנאי שסדר הפעולות נשמר בקפדנות. רשומת ה-DS חיה באזור האב ומצביעה על מפתח חתימה מסוים, ולכן כל עוד היא מפנה למפתח הישן והשרתים מחזירים את החדש, resolvers מאמתים מחזירים SERVFAIL — מבחינת הלקוחות זה נראה כמו כשל מוחלט של הדומיין.
הסדר הוא כזה: להפחית מראש את ה-TTL ולהמתין לאינטרוול הישן, להעביר את האזור יחד עם החלק הפרטי של המפתחות KSK/ZSK (או ליצור חדשים במודע), להעלות פלטפורמה חדשה ולוודא שהיא מחזירה DNSKEY ו-RRSIG, לאחר מכן להחליף את ה-DS דרך הרשם החדש, ורק אחרי עדכון אזור האב לכבות את הישנה.
את ממשק הרישום שדרכו מפורסם ה-DS קובעת ICANN, אך זמני החלת השינויים שונים בכל מרשם — ומבררים אותם לפני תחילת העבודה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| העברת מפתחות קיימים | האלגוריתם ואורך המפתח זהים בשתי הפלטפורמות | המפתח הפרטי מועבר בערוץ מאובטח ונשמר עם גישה מוגבלת |
| יצירת מפתחות חדשים | האלגוריתם משתנה או שהספק אינו מקבל מפתחות זרים | ה-DS אצל המרשם מתעדכן מחדש, וחלון אי-הסנכרון נשמר מינימלי |
| השבתה זמנית של DNSSEC | כשהמהירות של המעבר חשובה יותר | ההגנה מפני החלפה מוסרת לכל התקופה, וההפעלה עוברת את כל השלבים מחדש |
טעויות אופייניות במעבר — להסיר את ה-DS לפני פרסום המפתח החדש, להעביר רק את החלק הציבורי, לא לגעת ב-TTL ובזמן החיים של החתימה, לשכוח להסיר את ה-NS הישנים מההאצלה: חלק מה-resolvers ימשיכו לפנות לפלטפורמה בלי חתימה.
ספקות טכניים: ניתוח מצבים נפוצים
ספקות בדרך כלל צצים לא ברגע חתימת האזור, אלא אחרי שבוע של תפעול: חלק מהשאילתות מפסיקות לעבור בדיקה, מישהו מהשכנים מאציל תת-דומיין, הדואר מתחיל להתנהג מוזר. להלן ניתוח של המצבים שהמהנדסים שלנו נתקלים בהם לרוב בעת הגדרת DNSSEC.
חלק מהשאילתות לא עוברות בדיקה, והשאר עובדות — מדוע?
כשל חלקי כמעט תמיד מעיד על אי-התאמה בשרשרת האמון, ולא על בעיה באזור עצמו. סיבות אופייניות: תקציר ה-DS אצל הרשם אינו תואם ל-KSK הנוכחי, חתימה ישנה נשארה במטמון של resolver ביניים, או שהאזור מחזיר תשובה גדולה מדי וחלק מה-resolvers אינם עוברים ל-TCP.
את האבחון מבצעים מלמעלה למטה: בודקים את ה-DS בצד האב, שולחים שאילתה עם דרישת אימות, בוחנים את תוקף החתימות ואת נוכחות NSEC/NSEC3, ורק אחר כך מנתחים את קונפיגורציית השרת. ברוב המקרים תיקון של רשומת DS אחת מסיר את הסימפטום.
תת-דומיין הואצל לצוות אחר — מה יקרה עם הבדיקה?
בעת האצלה, החתימה של אזור הבן חיה בנפרד: זוג מפתחות משלו ו-DS משלו בצד האב. אם איש לא חתם את אזור הבן, הבדיקה עבור שמותיו פשוט אינה מתבצעת — שאר האזור ממשיך לעבוד כתקנתו, ולא יהיה סירוב.
לכן, בשלב ההתחלה, אנחנו אוספים מפת האצלות ולגבי כל תת-דומיין מחליטים: חותמים בעצמנו, מתאמים עם הבעלים או משאירים כפי שהוא. זה מתועד בתיעוד, כדי שהחלפת האחראי כעבור חצי שנה לא תהפוך לתקלה.
תאימות עם דואר ושירותי צד שלישי
רשומות הדואר נחתמות יחד עם האזור, וזה אינו משפיע על עבודת ה-MX — מה שנשבר בדרך כלל אינו הדואר, אלא resolvers שאינם יודעים לפרסר תשובות שהתפחו.
סדר הפעולות: מפעילים NSEC3 עם מספר מינימלי של איטרציות hash, עוקבים אחר גודל התשובות בעת מניית שמות, בודקים את ההחזרה דרך TCP, ובנפרד בודקים שירותים חיצוניים שמושכים את האזור כולו.
אם שירות הקבלן אינו תומך באימות חתימות, הבעיה נפתרת באמצעות אזור ביניים חתום, ולא בוויתור על DNSSEC.
כיצד לבדוק את שרשרת האמון לפני העלייה לאוויר?
אנחנו מריצים תרחיש בקרה על עותק בדיקה של האזור: שורש — אזור האב — האזור שלנו, ומשווים בכל שלב את תקציר ה-DS עם המפתח ואת תוקף החתימות. לאחר מכן אוספים דגימה מ-resolvers חיצוניים ומשרתים פנימיים של הארגון — לעיתים קרובות הם מוגדרים באופן שונה.
בנוסף, מגדירים ניטור על תוקף החתימות ועל שיעור התשובות בלי אישור בדיקה, כדי שפג תוקפו של מפתח לא יהיה הפתעה.
נדון באזור שלכם ונחזור עם הערכה ותוכנית
הערכה ל-DNSSEC תלויה כמעט כולה בשני דברים: כמה אזורים יש לכם וכמה סבוכה ההאצלה בין הרשם לשרתי השמות שלכם. אם תשלחו זאת מראש, הניתוח הראשון יתפוס שיחה אחת ויסתיים בתוכנית, ולא ברשימת שאלות הבהרה. הנה מה שכדאי להכין.
- רשימה מלאה של האזורים ותת-הדומיינים, כולל אלה שהואצלו לשרתים אחרים או שמטופלים אצל קבלנים: אזור שהוחמץ יישאר בלי חתימה, והתעבורה שלו תמשיך לזרום בלי הגנה.
- תרשים ההאצלה: מי מחזיק את אזור האב, היכן מפורסמות הרשומות על המפתחות, האם יש חוליות ביניים ואזורי דמה בצד הרשם.
- הרשאות גישה שיידרשו בעבודה: הפאנל של הרשם לפרסום רשומות על המפתחות, שרתים עם שירות DNS, מאגר קונפיגורציות, מערכת ניטור.
- המצב הנוכחי: האם DNSSEC מופעל על חלק מהאזורים, כיצד נשמרים המפתחות, באיזו תדירות מוחלפים, מי אחראי על ההארכה.
- רשימה של שירותים חיצוניים ו-resolvers שתלויים בדומיינים שלכם — חלקם עשויים שלא לתמוך באימות חתימה, וזה מתברר לפני ההפעלה, ולא אחריה.
בניתוח אנחנו עוברים על האזורים מלמעלה למטה: מסמנים היכן ההפעלה נוגעת באזור האב, היכן נדרשת פעולה ידנית בפאנל הרשם, והיכן יש סיכון להפסקה קצרה בפתרון השמות. בסיום תקבלו תרשים האצלה עם נקודות בקרה מסומנות, סדר הפעלה ונקודת חזרה לאחור בכל שלב.
תארו את המשימה שלכם וצרפו את מה שכבר יש בהישג יד — נחזור עם הערכה ותוכנית עבודה.