Defaults.Exposed › תיקונים › DNSSEC
כיצד לתקן DNSSEC
DNSSEC הוא חותמת דיגיטלית על ספר כתובות הדומיין שלך. הוא מאפשר לאינטרנט להוכיח שהתשובה ל'היכן חי הדומיין הזה?' הגיעה ממך באמת ולא נחבלה בדרך. ללא זה, התשובה יכולה להיות מזויפת — והמבקרים שלך נשלחים בשקט למקום אחר.
השורה התחתונה לעסק שלכם: ללא DNSSEC, תוקף שיכול להרעיל תשובת DNS יכול להפנות לקוחותיך אל עותק מושלם של האתר שלך בזמן שהדפדפן שלהם עדיין מציג את שם הדומיין האמיתי שלך. כניסות, מספרי כרטיסים ומידע אישי נקצרים, ואתה גלה זאת רק מהחיובים החוזרים והתלונות. הגדרת DNSSEC למחצה שבורה גרועה אפילו יותר: היא יכולה להפוך את האתר שלך לבלתי מגיע עבור פרוסה גדלה של מבקרים ללא שגיאה שתרגיש אי פעם.
מה זה יכול לעלות לכם
- מבקרים שמקלידים את הדומיין האמיתי שלך מופנים בשקט לדמוי שמלכד את הסיסמה ופרטי הכרטיס שלהם — וכי שורת הכתובת מציגה את הדומיין שלך כל הזמן, אף אחד לא חושד בכלום עד שדיווחי ההונאה מגיעים.
- האימייל שלך מנותב מחדש בשקט: תוקף מזייף את התשובה לשרתי הדואר שלך, קורא או מיירט הודעות, ומאפס סיסמאות בחשבונות שמאיילים אליך קוד — הכל מבלי לגעת בתיבת הדואר שלך.
- הגדרת DNSSEC שנעשתה למחצה (החותמת הציבורית קיימת אבל המפתח המתאים חסר) גורמת לאתר ולאימייל שלך להיכשל אקראית עבור לקוחות ב-ISPs גדולים ורשתות ארגוניות — דיווחים לסירוגין על 'האתר שלך מושבת אצלי' שאינך יכול לשחזר.
- צוות האבטחה של לקוח פוטנציאלי מריץ בדיקה לפני חוזה, רואה שאין DNSSEC, ומסמן אותך כחלש ביסודות — מסכן עסקה בגלל הגדרה חינמית.
- קונים ממגזר ציבורי ו-B2B גדולים יותר מצפים יותר ויותר ל-DNSSEC כהיגיינת בסיס (הוא מוזכר בתקנות כמו NIS2); היעדרו פוסל אותך בשקט מהזמנות מכרז לפני שמשוחח בכלל.
מדוע זה חשוב. DNS הוא ספר הכתובות של האינטרנט, וכברירת מחדל תשובותיו נוסעות ללא חתימה — כל אחד שיכול להחדיר תשובה מזויפת יכול לשלוח לקוחותיך והאימייל שלך לכל מקום שירצה, עם הדומיין האמיתי שלך עדיין מוצג בדפדפן. DNSSEC שם חותמת עמידה לפני חבלה על תשובות אלה כדי שניתן יהיה לאמת שהן שלך באמת. התיקון חינמי ברוב הספקים; העלות האמיתית היחידה היא לעשות זאת לא נכון, ולכן אנחנו עוברים בזהירות על שני החצאים.
DNSSEC, בשפה פשוטה
בכל פעם שמישהו מבקר באתר שלך או שולח לך אימייל, המחשב שלהם שואל תחילה את האינטרנט שאלה פשוטה: “היכן הדומיין הזה חי בפועל?” התשובה — קבוצת הכתובות לאתר שלך ולשרתי הדואר שלך — חוזרת מה-DNS, ספר כתובות האינטרנט.
הנה החלק המטריד: כברירת מחדל, תשובות אלה נוסעות ללא חתימה. לא מצורף לרשומות שום דבר להוכיח שהתשובה אמיתית. אם מישהו יכול להחדיר תשובה מזויפת לשיחה הזו — וישנן דרכים ידועות ומוכחות לעשות בדיוק זאת — המחשב של המבקר ישמח לקבל אותה. מאותו רגע, המבקר יכול לדבר עם שרת של תוקף בזמן שהדפדפן שלהם עדיין מציג את שם הדומיין שלך בשורת הכתובת.
DNSSEC הוא התיקון. הוא מוסיף חותמת דיגיטלית עמידה לפני חבלה על תשובות ה-DNS שלך. כש-DNSSEC מופעל, האינטרנט יכול לאמת מתמטית שתשובה הגיעה ממך באמת ולא שונתה בדרך. תשובה מזויפת נכשלת בבדיקה ונזרקת. זוהי ההבדל בין ספר כתובות שכל אחד יכול לרשום בו לבין אחד שכל ערך בו חתום ומאושר.
דף זה מכסה שני חלקים שהבדיקה שלנו מסתכלת עליהם יחד: האם החותמת מפורסמת (רשומת DS) והאם המפתח התואם מאחוריה קיים בפועל (רשומת DNSKEY). תראה למה שניהם חשובים בקרוב — כיוון שיש אחד בלי האחר זה צרות מסוג משלו.
מה זה יכול לעלות לך
אלה דפוסים ריאליים ומצטברים — לא עסק בשמו שניתן.
- ההפניה הבלתי נראית. תוקף מרעיל את תשובת ה-DNS לדומיין שלך. לקוחות מקלידים את כתובת האינטרנט האמיתית שלך, רואים את הדומיין האמיתי שלך בשורה, ונוחתים על עותק מושלם של דף הכניסה או הקופה שלך שמתארח ע”י התוקף. כל סיסמה ומספר כרטיס שהם מזינים הולכים ישירות לפושע. אתה שומע על זה רק כשמתחילים החיובים החוזרים ושיחות “נפרצתי דרך האתר שלך” — והעקבה מובילה למותג שלך, לא למותג התוקף.
- יירוט אימייל שקט. DNS לא מצביע רק לאתר שלך; הוא מצביע לשרתי הדואר שלך. זייף את התשובה הזו ואימייל נכנס יכול להיות מנותב מחדש דרך תוקף תחילה. הם קוראים הודעות רגישות, קוצרים את הקודים החד-פעמיים שהשירותים מאיילים כדי “לאמת שזה אתה”, ומאפסים סיסמאות בחשבונות שקשורים לדומיין שלך — הכל מבלי להתחבר לתיבת הדואר שלך.
- ההפסקה שלא ניתן לשחזר. מקרה זה מגיע מהגדרת DNSSEC שנעשתה למחצה. החותמת הציבורית (DS) יושבת ברשם שלך, אבל המפתח התואם (DNSKEY) חסר או שגוי. מבקרים ב-ISPs ורשתות ארגוניות שבודקות DNSSEC — ויש יותר כאלה כל שנה — פשוט לא יכולים לפתור את הדומיין שלך בכלל. האתר והאימייל שלך עובדים מצוין בשבילך ובשביל הטכנאים שלך, אבל פרוסה של לקוחות אמיתיים מקבלים “לא ניתן להגיע לאתר” ללא שגיאה שאתה יכול לראות. זוהי אחת הבעיות הקשות ביותר לאבחן בדיוק כיוון שהיא בלתי נראית מבפנים.
- העסקה שאבדה. צוות האבטחה או הרכש של לקוח פוטנציאלי מריץ סריקה שגרתית לפני חוזה של הדומיין שלך. “אין DNSSEC” מופיעה כסימון אדום ב”יסודות אבטחת DNS”. עבור בקרה חינמית ומובנת היטב, היעדרה קוראת כרשלנות — ויכולה בשקט לעלות לך חוזה שמעולם לא ידעת שהיה בסכנה.
- ההזמנה שאינך מתאים לה בכלל. תקנות ורשימות בדיקה של קונים מציינים יותר ויותר DNSSEC כהיגיינת בסיס צפויה (הוא מוזכר תחת הוראות אבטחת DNS של NIS2). קונים גדולים יותר מ-B2B וממגזר ציבורי עשויים לסנן אותך לפני שמשוחח מכירות מתחיל, פשוט כיוון שתיבת הסימון לא מסומנת.
מה זה בעצם
DNSSEC פועל כשרשרת אמון, ויש לו שני חלקים נעים שחייבים להסכים אחד עם השני. זה לב ליבו של מדוע הבדיקה שלנו מסתכלת על שני דברים.
ה-DNSKEY — המפתח שלך. ספק ה-DNS שלך מחזיק מפתח קריפטוגרפי ומשתמש בו לחתום על רשומות ה-DNS שלך. מחצית הציבורי של אותו מפתח מפורסמת כרשומת DNSKEY. חשוב על זה כחותמת-חתימה שמוחזקת בצידך.
רשומת DS — טביעת האצבע שמעידה על המפתח. טביעת אצבע קצרה של אותו מפתח, הנקראת רשומת DS (Delegation Signer), מפורסמת רמה אחת למעלה — ברישום הדומיין שלך, דרך הרשם שלך. זה מה שמאפשר לשאר האינטרנט לסמוך על המפתח שלך: כל רמה מעידה על זו שמתחתיה, עד לשורש האינטרנט. ה-DS הוא החותמת שנרשמת רשמית כדי שכולם יכולים לזהות אותה.
כדי ש-DNSSEC יגן עליך בפועל, שניהם חייבים להיות קיימים וחייבים להתאים:
- DS קיים + DNSKEY קיים ותואם → טוב. שרשרת האמון שלמה. תשובות מזויפות נדחות; לגיטימיות מאומתות. זהו מצב ה”מעבר”.
- אין DS (ואין DNSKEY) → DNSSEC פשוט לא מופעל. אין לך הגנה, אבל לא שום דבר שבור. זהו המצב הנפוץ ביותר “טרם נעשה”. (בניקוד שלנו כאן בדיקת ה-DS סופרת נגדך; בדיקת המפתח המשולב מתייחסת למצב נקי “כבוי לחלוטין” כאינפורמטיבית ולא ככשל קשיח, כיוון שלא שום דבר שובר פעילות.)
- DS קיים, אבל DNSKEY חסר או לא תואם → שבור, וגרוע יותר מכבוי. האינטרנט רואה חותמת מפורסמת שמצביעה למפתח שאינו שם. Resolvers מאמתים מסיקים שהדומיין שלך חובל ומסרבים לפתור אותו — גורם להפסקות לסירוגין המתוארות למעלה. זהו המצב הדחוף ביותר לתיקון, והבדיקה שלנו מסמנת אותו כחומרה גבוהה.
- DNSKEY קיים, אבל אין DS ברשם → מופעל אבל לא מופעל. הרשומות שלך חתומות, אבל כיוון שטביעת האצבע מעולם לא נרשמה רמה אחת למעלה, לשאר האינטרנט אין דרך לסמוך עליהן. אתה מקבל את העבודה ללא ההגנה. התיקון הוא להוסיף את רשומת DS ברשם שלך.
מה נראה “טוב”, בשורה אחת: רשומת DS ברשם שלך שטביעת האצבע שלה תואמת DNSKEY חי אצל ספק ה-DNS שלך, שניהם מאושרים עם בדיקה מהירה.
כיצד לתקן (חינם, ~10–30 דקות)
מסור חלק זה למי שמנהל את הדומיין שלך או האתר. התיקון עצמו חינמי ברוב הספקים — העלות היחידה היא לעשות אותו בזהירות כך ששני החצאים יישארו בסנכרון. אנחנו גובים תשלום רק אם תרצה שננטר שהוא נשאר מופעל נכון.
הכלל הזהוב: הפעל חתימה תחילה (שיוצר את ה-DNSKEY), ואז פרסם את רשומת ה-DS ברשם — לעולם לא הפוך, ולעולם לא אחד בלי האחר. פרסום DS לפני שהמפתח קיים הוא בדיוק מה שגורם להפסקות.
הנתיב הפשוט (מומלץ — Cloudflare):
- ב-Cloudflare, ודא ש-Cloudflare מריץ בפועל את ה-DNS שלך (שרתי השמות שלך מצביעים ל-Cloudflare).
- עבור אל DNS → Settings → DNSSEC → Enable DNSSEC. Cloudflare מייצר ומנהל את המפתחות עבורך (זה יוצר את צד ה-DNSKEY אוטומטית).
- Cloudflare מראה לך את פרטי רשומת ה-DS לפרסום ברשם שלך.
- התחבר לרשם הדומיין שלך (כמו GoDaddy, Namecheap, OVH) ומצא את חלק DNSSEC. הדבק את ערכי ה-DS ש-Cloudflare נתן לך.
- המתן 24–48 שעות להתפשטות מלאה. האתר והאימייל שלך ממשיכים לעבוד לאורך כל התהליך.
ספקי DNS אחרים (AWS Route 53, מארח האינטרנט שלך וכו’):
- בלוח הבקרה של ספק ה-DNS שלך, הפעל DNSSEC / “חתום אזור זה.” זה מייצר מפתחות חתימה ומפרסם רשומות DNSKEY.
- העתק את רשומת ה-DS שהספק מייצר.
- הוסף את רשומת ה-DS הזו ברשם שלך תחת הגדרות DNSSEC שלו.
- אשר שהרשם קיבל אותה וחכה להתפשטות.
הערות פלטפורמה:
- Cloudflare — הפעלה בלחיצה אחת, ואז הדבקת DS אחת ברשם. הנתיב הקל ביותר בהרבה.
- AWS Route 53 — הפעל חתימת DNSSEC על האזור המתארח, ואז הוסף את רשומת ה-DS ברשם הדומיין שלך (אם הדומיין רשום ב-Route 53, AWS יכול לקשר אותו עבורך).
- Microsoft 365 / Google Workspace — אלה מריצים את האימייל שלך, לא בדרך כלל את אזור ה-DNS שלך. DNSSEC מופעל היכן שרשומות ה-DNS שלך חיות בפועל (לעתים קרובות הרשם, המארח, או Cloudflare שלך), לא במרכז הניהול של 365/Workspace.
- ספק ה-DNS שלך לא תומך ב-DNSSEC בכלל? זה נפוץ עם מארחים ישנים יותר או זולים יותר. התיקון הנקי הוא לעבור את ניהול ה-DNS לספק שתומך (Cloudflare חינמי), ואז לעקוב אחר הנתיב הפשוט למעלה. העברת DNS לא דורשת העברת האתר שלך או האימייל.
אמת שזה עבד:
- הרץ
dig DS yourdomain.comו-dig DNSKEY yourdomain.com— שניהם צריכים להחזיר רשומות. - או השתמש בכל בודק DNSSEC מקוון חינמי ואשר שרשרת אמון ירוקה/חוקית.
- אל תחשוב שסיימת עד שגם שניהם מחזירים רשומות תואמות. DS ללא DNSKEY הוא המצב השבור — תקן או הסר אותו מיד.
טעויות נפוצות
- פרסום ה-DS לפני שהמפתח קיים. הטעות ה הרסנית ביותר: הוספת רשומת ה-DS ברשם לפני שהחתימה חיה בפועל אצל ספק ה-DNS. זה יוצר את מצב “חותמת מפורסמת, מפתח חסר” שהופך את הדומיין שלך לבלתי ניתן לפתרון למבקרים שבודקים DNSSEC. תמיד הפעל חתימה תחילה, ואז פרסם DS.
- השארת DS ישן מאחור לאחר מעבר ספקים. אם אתה עובר ספקי DNS (או מבטל חתימה) אבל שוכח להסיר או לעדכן את רשומת ה-DS הישנה ברשם, אתה נשאר מצביע למפתח שכבר לא קיים — אותה תוצאה שבורה. כש-DNSSEC כבוי או עובר, עדכן את ה-DS ברשם באותו שינוי.
- עצירה לאחר שלב ראשון. הפעלת חתימה אצל ספק ה-DNS (יצירת ה-DNSKEY) אבל מעולם לא הוספת ה-DS ברשם. הכל נראה “מופעל” בלוח ה-DNS, אבל ללא DS ההגנה לא מופעלת לעולם. עשית את העבודה ולא קיבלת שום תועלת.
- הנחה ש-HTTPS או אימות אימייל כבר מכסים את זה. המנעול ואימות אימייל (SPF / DKIM / DMARC) יקרי ערך אבל פותרים בעיות שונות. אף אחד מהם לא עוצר תשובת DNS מזויפת מלשלוח מבקרים למקום הלא נכון מלכתחילה.
- אי-ניטור לאחר הפעלה. מפתחות מתגלגלים, ספקים משתנים, רשומות נערכות. הגדרה מושלמת היום יכולה להישבר בשקט חודשים מאוחר יותר. אם DNSSEC חשוב מספיק להפעיל, שווה בדיקה תקופתית שהוא עדיין חוקי.
היכן זה ממוקם בציון שלך
שתי הבדיקות האלה תורמות לציון אבטחת ה-DNS שלך. בדיקת רשומת ה-DS נחשבת לבעלת עדיפות גבוהה יותר משתיהן: DS חסר הוא פרצה אמיתית ומנוקד ככשל. בדיקת ה-DNSKEY מאשרת שהשאר של השרשרת שלם — היא עוברת רק כש-DS תואם וגם DNSKEY שניהם קיימים, והיא מסמנת את מצב “DS-ללא-מפתח” השבור כחומרה גבוהה. תוצאת “DNSSEC פשוט לא מופעל עדיין” נקייה היא נקודת ההתחלה הנפוצה לעסקים רבים; מעבר משם לזוג DS + DNSKEY מלא ותואם הוא שדרוג חינמי ומובן היטב שמשפר את עמדת אבטחת ה-DNS שלך ומסיר נתיב אמיתי להתחזות ויירוט.
הגדירו זאת אצל ספק האחסון שלכם
שלב אחר שלב עבור ספקים פופולריים:
- הגדירו DNSSEC ב-GoDaddy
- הגדירו DNSSEC ב-Namecheap
- הגדירו DNSSEC ב-Cloudflare
- הגדירו DNSSEC ב-AWS Route 53
שאלות נפוצות
אני לא טכני — האם זה משהו שאני חייב לטפל בו אישית?
לא. אתה צריך להבין למה זה חשוב (דף זה מכסה זאת), אבל השינוי בפועל חי בהגדרות ה-DNS והרשם של הדומיין שלך, אז הוא שייך למי שמנהל את הדומיין שלך או האתר. מסור להם את חלק 'כיצד לתקן' — זה חינמי ובדרך כלל לוקח פחות מחצי שעה. אנחנו גובים תשלום רק אם תרצה שנמשיך לצפות שהוא מופעל נכון.
אם לאתר שלי כבר יש את המנעול (HTTPS), האם לא כבר מוגן?
הם מגינים על דברים שונים. המנעול מאבטח את החיבור ברגע שמבקר הגיע לשרת הנכון. DNSSEC מגן על השלב לפני כן — לוודא שהם מגיעים לשרת הנכון מלכתחילה. תוקף שמזייף את ה-DNS שלך יכול לשלוח מבקרים לשרת שלו, שיכול להיות לו מנעול חוקי משלו על דומיין דמוי או אפילו על עותק של שלך. אתה צריך את שניהם; אחד לא מחליף את האחר.
האם הפעלת DNSSEC יכולה לשבור את האתר שלי או האימייל?
כשנעשה במקום אחד ע
אנחנו מתארחים ב-Cloudflare / Google Workspace / Microsoft 365 — האם זה מכסה את זה?
לא אוטומטית, אבל זה הופך לקל. מה שחשוב הוא היכן ה-DNS שלך מנוהל. אם Cloudflare מריץ את ה-DNS שלך, זה לחיצה אחת להפעלה בנוסף להדבקת רשומה אחת ברשם שלך. Microsoft 365 ו-Google Workspace מנהלים אימייל, לא בדרך כלל את אזור ה-DNS שלך — DNSSEC מופעל היכן שרשומות ה-DNS של הדומיין שלך חיות בפועל (לעתים קרובות Cloudflare, הרשם שלך, או המארח שלך). השלבים למטה מכסים את המקרים הנפוצים.
מה בדיוק הם 'DS' ו-'DNSKEY' — ולמה דף זה מזכיר את שניהם?
הם שני חצאי מנעול אחד. DNSKEY הוא המפתח שספק ה-DNS שלך מחזיק ומשתמש בו לחתום על הרשומות שלך. DS הוא טביעת אצבע של אותו מפתח, שמפורסמת רמה אחת למעלה ברשם שלך כדי שהשאר של האינטרנט יוכל לאשר שהמפתח הוא שלך באמת. שניהם חייבים להיות קיימים וחייבים להתאים. אנחנו בודקים את שניהם: DS חסר אומר ש-DNSSEC לא מופעל; DS ללא DNSKEY תואם אומר שהוא מופעל אבל שבור.
כמה זמן עד שזה עובד, וכיצד אאמת אותו?
אפשר 24–48 שעות עד שהשינוי יתפשט לחלוטין על פני האינטרנט; האתר הקיים והאימייל שלך ממשיכים לעבוד לאורך כל התהליך אם נעשה נכון. לאישור, איש ה-IT שלך יכול להריץ 'dig DS yourdomain' ו-'dig DNSKEY yourdomain' ולראות רשומות שמוחזרות לשניהם, או להשתמש בכל בודק DNSSEC מקוון חינמי. אנחנו גם יכולים לנטר זאת ברציפות כך ששבירה עתידית תתפס ביום שהיא קורית, לא ביום שלקוח מתלונן.