עודכן לפני חודש
כאשר תגובת DNS מגיעה לרזולבר שלך, כיצד הוא יודע שהתשובה אמיתית? כל אחד בנתיב הרשת יכול היה ליירט את השאילתה ולשלוח בחזרה תגובה מזויפת. הדומיין יכול להפנות לשרת של תוקף במקום לשרת הלגיטימי.
DNSSEC הופך את השאלה שאין לה תשובה — "מי שלח את זה?" — לשאלה שניתן לאמת: מי ערב לך?
שרשרת האמון
אזור השורש של DNS נמצא בראש כל שם דומיין. הרזולבר שלך סומך עליו מראש — אמון זה מוגדר ישירות בתוך התוכנה. מנקודת עיגון יחידה זו, האמון זורם כלפי מטה דרך חתימות.
השורש חותם על אישורו של .com. .com חותם על אישורו של example.com. ו-example.com חותם על הרשומות שלו עצמו. כל אישור הוא חתימה קריפטוגרפית שאי אפשר לזייף אותה ללא המפתח הפרטי.
כאשר אתה שולח שאילתה עבור example.com, הרזולבר שלך לא פשוט מקבל את התשובה. הוא עוקב אחר השרשרת: האם השורש ערב ל-.com? האם .com ערב ל-example.com? האם החתימה של example.com עומדת בבדיקה? אם כל חוליה מחזיקה, התשובה אמיתית.
כיצד עובדות החתימות
כל אזור שחתום על ידי DNSSEC מפרסם שני דברים: מפתחות ציבוריים (ברשומות DNSKEY) וחתימות (ברשומות RRSIG).
בעל האזור משתמש במפתח הפרטי שלו כדי לחתום על כל קבוצת רשומות. חתימה זו — המאוחסנת ברשומת RRSIG — נשלחת יחד עם נתוני ה-DNS. לצורך אימות, הרזולבר מאחזר את המפתח הציבורי של האזור, משתמש בו כדי לפענח את החתימה, ומחשב את ה-hash שלו עצמו על בסיס הרשומות שהתקבלו. אם ערכי ה-hash תואמים, מוכח כי מישהו עם המפתח הפרטי יצר את החתימה, והרשומות לא שונו מאז.
אבל כיצד אתה סומך על המפתח הציבורי עצמו? תוקף חכם יכול לזייף הן את הרשומות והן מפתח מזויף כדי לחתום עליהן.
רשומות DS: החוליה בין אזורים
כאן השרשרת נוצרת. כל אזור הורה מפרסם רשומת DS (Delegation Signer) המכילה hash של מפתח האזור הבן. ההורה חותם על רשומת DS זו במפתח שלו עצמו.
אימות example.com עובד כך:
- בדוק את החתימה של
example.comבאמצעות המפתח הציבורי שלexample.com - אמת את המפתח הזה על ידי בדיקת ה-hash שלו מול רשומת ה-DS ב-
.com - אמת את המפתח של
.comעל ידי בדיקת ה-hash שלו מול רשומת ה-DS בשורש - אמת את מפתח השורש מול עוגן האמון — המפתח שהרזולבר שלך הוגדר לסמוך עליו
כל חוליה מאומתת קריפטוגרפית. שבור חוליה אחת — ואימות נכשל.
מה עושים הרזולברים בפועל
רזולברים המאמתים DNSSEC מתחילים עם אחד או יותר עוגני אמון — מפתחות ציבוריים שהם סומכים עליהם מטבעם, בדרך כלל רק המפתח של אזור השורש. כל השאר חייב להיות מאומת.
כאשר מגיעה שאילתה, הרזולבר עובד מלמעלה למטה. הוא מאמת את המפתח של כל אזור לפני שהוא ממשיך לאזור הבן. רק לאחר שכל השרשרת עוברת בדיקה הוא מקבל את התשובה הסופית.
רזולברים שומרים במטמון מצבי אימות לצד הרשומות. לאחר שהמפתח של .com מאומת, שאילתות עוקבות לכל דומיין .com מדלגות על שלב זה עד שפג תוקף המפתח השמור במטמון. כך נמנע מ-DNSSEC להוסיף השהיה מורגשת לרוב השאילתות.
כאשר האימות נכשל
האימות יכול להיכשל מסיבות רבות: חתימות שפג תוקפן, רשומות חסרות, שרשראות שנשברו, או התקפות ממשיות.
רזולבר המאמת DNSSEC מחזיר SERVFAIL במקום נתונים שלא אומתו. הוא מעדיף לא לתת לך כלום מאשר לתת לך שקר. אם לא ניתן לאמת אזור חתום, משהו לא תקין — והרזולבר לא יעמיד פנים אחרת.
המשמעות היא שתצורות שגויות יכולות לגרום לדומיינים להיות בלתי נגישים. אם מפעיל אזור שוכח לרענן חתימות לפני שפג תוקפן, האימות נכשל והדומיין הופך לבלתי נגיש עד שהבעיה תתוקן. הפרוטוקול מתייחס ל"לא ניתן לאמת" בדיוק כמו ל"אימות נכשל" — שניהם מסתיימים ללא תשובה.
מודע ל-DNSSEC מול מאמת DNSSEC
לא כל הרזולברים מאמתים. ההבחנה חשובה.
רזולברים המודעים ל-DNSSEC מבינים את סוגי הרשומות של DNSSEC ויכולים להעבירם הלאה, אך אינם מאמתים חתימות. הם מסוגלים לטפל ב-DNSSEC אך אינם אוכפים אותו. תוקף יכול לשלוח תגובות מזויפות ורזולברים אלה יאחסנו ויגישו אותן ללא תלונה.
רזולברים המאמתים DNSSEC מאמתים באופן פעיל כל חתימה ושרשרת אמון. הם מסרבים להגיש נתונים שנכשלים באימות. רזולברים ציבוריים מרכזיים כמו Google (8.8.8.8) ו-Cloudflare (1.1.1.1) הם רזולברים מאמתים — הם מגינים על כל מי שמשתמש בהם, בין אם הלקוח מבין DNSSEC ובין אם לאו.
ערובת האבטחה מגיעה רק מרזולברים מאמתים. להיות מודע ל-DNSSEC מבלי לאמת זה כמו מנעול על הדלת שלעולם לא נועלים.
שאלות נפוצות על אימות DNSSEC
מדוע DNSSEC משתמש בשני סוגי מפתחות (ZSK ו-KSK)?
מפתחות חתימת האזור (ZSK) חותמים על הרשומות של האזור וניתן לסובב אותם לעתים קרובות. מפתחות חתימת המפתח (KSK) חותמים על רשומות DNSKEY עצמן. הפרדה זו מאפשרת לשנות את ה-ZSK מבלי לתאם עם אזור ההורה — רק שינויי KSK מחייבים עדכון רשומת ה-DS במעלה הזרם.
מה קורה אם אני שולח שאילתה לדומיין שאינו חתום על ידי DNSSEC?
הרזולבר מחזיר את התשובה ללא אימות. DNSSEC הוא אופציונלי — אזורים לא חתומים עובדים בדיוק כפי שתמיד עבדו. הרזולבר אוכף אימות רק לאזורים שבהם DNSSEC מופעל.
האם DNSSEC יכול להגן מפני כל התקפות ה-DNS?
DNSSEC מגן מפני חבלה וזיוף של תגובות DNS. הוא אינו מצפין שאילתות — זה תפקידם של DNS-over-HTTPS ו-DNS-over-TLS — ואינו מונע התקפות על השרתים הסמכותיים עצמם. זוהי שכבת הגנה אחת, לא פתרון מלא.
מדוע חלק מהדומיינים הופכים לבלתי נגישים בגלל DNSSEC?
בדרך כלל מפני שחתימות פגו תוקפן או שרשרת האמון נשברה. DNSSEC דורש תחזוקה שוטפת — חתימות חייבות להתרענן לפני שפג תוקפן, ושינויי מפתחות חייבים להיות מתואמים עם אזורי ההורה. כאשר מפעילים מזניחים זאת, האימות נכשל והדומיין הופך לבלתי נגיש לרזולברים מאמתים.
האם דף זה היה מועיל?