רשומות DNSKEY ו-DS: יסודות DNSSEC

DNS נבנה על אמון עיוור.

כשאתה שואל "איפה נמצא example.com?" המחשב שלך שולח את השאלה לרשת ומאמין לכל תשובה שחוזרת. ללא אימות. ללא הוכחת אמינות. רק אמון — כמו לשאול זר לכיוון וללכת אחריו ללא שאלות.

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

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

שרשרת האמון

ה-DNS של האינטרנט בנוי בצורה היררכית. בראש יושב אזור השורש. מתחתיו נמצאים דומיינים ברמה עליונה כמו .com, .org ו-.net. ומתחתם — הדומיינים שבהם אתה משתמש בפועל: example.com, google.com, הדומיין של החברה שלך.

DNSSEC יוצר שרשרת של הוכחה קריפטוגרפית שעוקבת אחר היררכיה זו. אזור השורש חותם על הצהרה לגבי .com. אזור ה-.com חותם על הצהרה לגבי example.com. ו-example.com חותם על הצהרות לגבי הרשומות שלו — כתובות ה-IP שאתה מחפש.

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

זהו עיצוב כשל-בטוח. DNSSEC מעדיף לא לתת לך כלום על פני לתת לך משהו מזויף.

רשומות DNSKEY: המפתחות הציבוריים

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

example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==

הרכיבים:

• 257 — דגלים המציינים שזהו מפתח חתימת מפתח (Key Signing Key, יפורט בהמשך)
• 3 — שדה הפרוטוקול, תמיד 3 עבור DNSSEC
• 13 — מספר האלגוריתם (ECDSA P-256 עם SHA-256)
• המחרוזת הארוכה — המפתח הציבורי עצמו, מקודד ב-base64

כשמאתר מקבל רשומת DNS יחד עם החתימה שלה (המאוחסנת ברשומת RRSIG), הוא משתמש ב-DNSKEY לאימות אותה חתימה. אם החישוב מסתדר, הרשומה אמיתית.

שני מפתחות, שתי משימות

DNSSEC משתמש בשני סוגי מפתחות, והסיבה מעשית לחלוטין.

מפתח חתימת האזור (ZSK) חותם על רשומות ה-DNS בפועל — רשומות A, רשומות MX, כל מה שמצוי באזור. הוא משמש ללא הפסקה, בכל פעם שהאזור נחתם מחדש. מכיוון שהוא בשימוש כה תכוף, הנוהג המקצועי הוא לסובב אותו באופן קבוע — בדרך כלל כל כמה חודשים.

מפתח חתימת המפתח (KSK) מבצע משימה אחת בלבד: חתימה על קבוצת רשומות ה-DNSKEY עצמה. ה-KSK ערב לשני המפתחות (כולל לעצמו), ומכיוון שהוא בשימוש פחות תכוף, הוא מוחלף לעיתים רחוקות יותר — אולי פעם בשנה.

למה להתעסק עם שני מפתחות? בגלל מה שקורה כשצריך להחליפם.

כשמחליפים ZSK, מייצרים מפתח חדש, חותמים מחדש על האזור, ומעדכנים את רשומות ה-DNSKEY. שאר העולם לא צריך לדעת. ה-KSK — המפתח שבו אזור ההורה סומך — לא השתנה.

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

רשומות DS: חוליות השרשרת

הנה השאלה הקריטית: מדוע בכלל לסמוך על DNSKEY של example.com? כל אחד יכול לפרסם רשומת DNSKEY שטוענת להיות סמכותית עבור example.com.

התשובה היא רשומות DS. רשומת DS היא גיבוב של ה-KSK של אזור-בן, המאוחסנת באזור ההורה. אזור ה-.com מחזיק רשומת DS המכילה גיבוב של ה-KSK של example.com. זה יוצר את החוליה בשרשרת האמון.

example.com. 3600 IN DS 12345 13 2 1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF

השדות:

• 12345 — תג מפתח, מזהה מהיר לאיזה DNSKEY זה מתייחס
• 13 — מספר האלגוריתם, תואם ל-DNSKEY
• 2 — סוג הגיבוב (SHA-256)
• מחרוזת ה-hex — הגיבוב של ה-DNSKEY של אזור-הבן

כשמאתר רוצה לאמת את example.com, הוא קודם מביא את רשומת ה-DS מ-.com (שאותה הוא יכול לאמת באמצעות DNSKEY של .com). לאחר מכן הוא מביא את DNSKEY של example.com ובודק: האם גיבוב של מפתח זה מניב את ה-digest המופיע ברשומת ה-DS? אם כן, המפתח לגיטימי. אזור ההורה ערב לו.

מעקב אחר השרשרת

נעקוב אחר תהליך אימות אמיתי. אתה רוצה לאמת את www.example.com.

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

עם מפתח השורש כעוגן מהימן:

1. שורש → .com: המאתר שואל את השורש לגבי רשומת ה-DS של .com. השורש חותם על התגובה. המאתר מאמת את החתימה באמצעות DNSKEY של השורש. כעת יש בידיו גיבוב מהימן של ה-KSK של .com.

2. .com → example.com: המאתר שואל את .com לגבי ה-DNSKEY שלו, מאמת שהוא תואם לרשומת ה-DS מהשורש, ואז שואל לגבי רשומת ה-DS של example.com. אזור ה-.com חותם על התגובה. כעת בידי המאתר גיבוב מהימן של ה-KSK של example.com.

3. example.com → www: המאתר שואל את example.com לגבי ה-DNSKEY שלו, מאמת שהוא תואם לרשומת ה-DS מ-.com, ואז שואל לגבי רשומת ה-A של www.example.com יחד עם החתימה שלה. הוא מאמת את החתימה באמצעות ה-ZSK של example.com (שה-KSK ערב לו, וה-KSK עצמו מאושר על ידי רשומת ה-DS).

כל שלב תלוי בקודם לו. שבור חוליה אחת — והאימות קורס.

כשמפתחות חייבים להשתנות

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

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

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

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

ארכיטקטורת ההוכחה

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

מערכת שני המפתחות קיימת כדי להפוך את הרוטציה לניתנת לניהול. החלף את ה-ZSK שלך בכל עת שתרצה. החלף את ה-KSK — ותצטרך לתאם עם אזור ההורה.

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

שאלות נפוצות על רשומות DNSKEY ו-DS

מה קורה אם רשומת ה-DS שלי לא תואמת ל-DNSKEY שלי?

אימות DNSSEC נכשל עבור הדומיין כולו. מאתרים המבצעים אימות יחזירו שגיאות SERVFAIL במקום רשומות ה-DNS שלך. זה קורה לרוב לאחר רוטציית KSK כשרשומת ה-DS החדשה לא הוגשה לאזור ההורה, או כשההורה טרם פרסם עדכון שהגשת.

למה אני צריך גם ZSK וגם KSK? לא יכול להסתפק במפתח אחד?

אפשר — חלק ממפעילים משתמשים במפתח חתימה משולב (CSK) המשמש בשני התפקידים. אך גישת שני המפתחות קיימת מפני ששינוי KSK מחייב עדכון רשומת ה-DS באזור ההורה, מה שדורש זמן ותיאום. הפרדת המפתחות מאפשרת לסובב את ה-ZSK לעיתים קרובות מבלי לגעת כלל באזור ההורה.

כיצד מאתרים מקבלים את המפתח הציבורי של אזור השורש?

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

מה ההבדל בין סוגי digest 1, 2 ו-4 ברשומות DS?

סוג 1 הוא SHA-1 (מיושן, יש להימנע ממנו). סוג 2 הוא SHA-256 (הסטנדרט הנוכחי). סוג 4 הוא SHA-384 (חזק יותר, פחות נפוץ). בעת יצירת רשומות DS, השתמש לפחות ב-SHA-256. מפעילים רבים מפרסמים גם רשומות DS של SHA-256 וגם של SHA-384 כשכבת הגנה נוספת.

כמה זמן כדאי להמתין בין שלבים במהלך רוטציית מפתחות?

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

מקורות