אימות המידע – DNSSEC בצד המשתמש

בסעיף "עקרונות DNSSEC" הוזכר תהליך האימות. שם צוין כי הוא מתבצע ב"צד הלקוח".

DNS בצד הלקוח הוא ה- DNS של ספק האינטרנט, או ה- DNS הארגוני שדרכו הלקוח גולש. נפוצים מאוד גם שירותי DNS ציבוריים דוגמת 8.8.8.8 של גוגל,  1.1.1.1 של Cloudflare וכו',
כל אלה נקראים שרתי DNS "רקורסיביים" או "רזולברים".

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

דוגמא: משתמש מעוניין לגלוש לאתר כלשהו, למשל ל- www.example.com

• הוא מקיש את השם הנ"ל בדפדפן. מערכת ההפעלה אצלו במחשב מנסה לברר מה כתובת ה- IP של הדומיין הנ"ל. אם אין לה את המידע, היא פונה לשרת ה- DNS שמוגדר לה (ה"רזולבר").
• הרזולבר מקבל את השאילתה: מהי כתובת ה- IP של example.com? אם אין לו את המידע ב- cache, הוא מנסה לאתר DNS אוטוריטטיבי שיענה על השאילתה הזו.
• אם הרזולבר תומך ב- DNSSEC הוא מסמן לשרת ה- DNS האוטוריטטיבי שאותו הוא מתשאל, על יכולתו לאמת חתימות. הוא עושה זאת בכל שאילתה, ע"י הפעלת flag ב- DNS header שנקרא DNSSEC OK = DO.
• שרת DNS אוטוריטטיבי שמקבל שאילתה עם דגל DO: אם הדומיין המבוקש לא חתום, מתעלם מהדגל הנ"ל ומחזיר תשובה "רגילה" (רשומה עם כתובת IP של הדומיין). אם לעומת זאת הדומיין כן חתום DNSSEC, אזי פרט לתשובה הרגילה, הוא יספק גם את החתימה של הרשומה הנ"ל.
• לצורך אימות החתימה, הרזולבר יבקש גם את המפתח.
• כעת הרזולבר מנסה לפענח את החתימה עם המפתח. אם היא תקינה והתוצר זהה לרשומה הגלויה, הוא יבדוק את מהימנות המפתחות (בדיקת שרשרת אמון): הוא ישווה את ה- KSK אל מול ה- DS שנמצא ברמה מעל, שוב יבצע תהליך אימות (כיוון שגם ה- DS חתום), וחוזר חלילה.
• מכיוון שכל חתימה וכל מפתח הן רשומות, הכל נכנס ל- cache של הרזולבר. לכן, בשאילתה הבאה לאותו דומיין, תהליך האימות יהיה מיידי, ללא צורך בתשאולים או בדיקות  נוספות.
• רק אם האימות הצליח, הרזולבר מעביר את התשובה ללקוח.

להלן תרשים המתאר תהליך אימות DNSSEC. תחילת התהליך הוא איתור שרת ה- DNS האוטוריטטיבי המפרסם את הדומיין המבוקש (זהו תהליך סטנדרטי ולכן אינו מוצג בתרשים).
כאשר השרת האוטוריטטיבי אותר,  הרזולבר שואל אותו: "מהו ה- A record (כתובת IP) של www.example.com", ומוסיף דגל "do" כדי לסמן שהוא תומך DNSSEC (סעיף 1 בתרשים).

השרת האוטוריטטיבי מחזיר בתשובה את הכתובת, ובנוסף את את החתימה (2). כעת הרזולבר מבקש מפתח ציבורי (ZSK) ע"מ לאמת את החתימה (3). הוא מקבל אותו בצירוף החתימה עליו (4). כעת יש לאמת את ה- KSK שחתם על ה- ZSK מסעיף 2. לכן הוא פונה לרמה מעל  (לדומיין com.) ומבקש שם את ה- DS שמתייחס לדומיין המבוקש (5) בתשובה הוא מקבל את ה- DS בצירוף חתימה (6). שוב, הרזולבר מבקש מפתח כדי לאמת (7) ושוב מקבל אותו בצירוף חתימה (8). התהליך חוזר על עצמו  9,10,11,12 עד לרמת ה-root.

הערות:

1. בתרשים הנ"ל מתואר תהליך מלא, כאשר אין שום מידע ב- cache של הרזולבר.
   כזכור, המפתחות, החתימות ה- DS, הכל נכנס ל- cache של הרזולבר (כמו כל רשומה). לכן, שאילתה נוספת לדומיין הזה לא תצריך ביצוע התהליך מחדש. הן התשובה והן האימות יתקבלו מיידית.
2. ניתן לראות שתהליך האימות מתבצע מלמטה למעלה, החל מהדומיין החתום, כלפי מעלה, עד ה- root העולמי, כל הרמות משתתפות. כך באה לידי ביטוי שרשרת האמון של DNSSEC המבוססת על המבנה ההיררכי של עץ ה- DNS.
3. בהמשך לסעיף הקודם, כדי שניתן יהיה לחתום על דומיין כלשהו ב- DNSSEC, חובה שכל הרמות שמעליו יהיו חתומות לפני כן.
4. מרחב IL כמו גם המרחבים שתחתיו co.il, org.il, net il, ac.il, gov.il, k12.il, muni.il כולם חתומים ולכן מאפשרים לשמות מתחם אשר מוכלים בהם לממש DNSSEC.

הפעלת ולידציה ב- DNS בצד הלקוח (ברזולבר)

 הפעלת ולידציה ברזולבר היא פעולה פשוטה.

בדרך כלל שרת BIND עדכני מותקן עם אימות DNSSEC מופעל כברירת מחדל.
אם לא, תמיד ניתן לוודא כי בקובץ named.conf בתוך "options" יש את הערך הבא:

dnssec-validation auto;

לאחר עדכון קובץ conf יש לטעון את השינוי ע"י הרצת:

rndc reconfig

כמתואר כאן: https://kb.isc.org/docs/aa-01182

ולידציה בשרת DNS של מיקרוסופט מתוארת כאן: https://learn.microsoft.com/en-us/windows-server/networking/dns/validate-dnssec-responses