חתימה על המידע – מימוש DNSSEC בצד האוטוריטטיבי

בניגוד לרזולבר המתשאל, שרת אוטוריטטיבי לא מבצע ולידציה. הוא רק מחזיר תשובה לפי המידע שיש לו. למעשה, שרת DNS אוטוריטטיבי הוא גם לא זה שחותם על הרשומות, אלא רק מציג אותן. עבורו- zone חתום כן או לא, לא משנה מבחינת משאבים נדרשים.
כפי שנאמר, המפתחות והחתימות הן רשומות DNS רגילות ולכן מבחינת שרת ה-DNS שמפרסם אותן, אין שום הבדל בהנגשת Zone "רגיל" או Zone חתום. מימוש DNSSEC – הגדרות מדיניות, ניהול מפתחות וביצוע החתימות עצמן כולם נעשים מאחורי הקלעים (בשרת מאסטר אחורי או בשרת חתימות ייעודי שמשתלב בתהליך הפצת ה- zone). ניתן להגדיר תהליך חתימה מתוזמן, שמופעל בקבועי זמן, או לחילופין אוטומטית בכל פעם שה- zone משתנה. יש מגוון גדול של אפשרויות וארכיטקטורות כולן כראות עיניו של ארכיטקט הרשת. לבסוף, התוצר הוא zone חתום, אשר מופץ לסלייבים כמו כל DNS zone רגיל.

1. 1. הדרך הפשוטה ביותר היא הפעלת שירות DNS מנוהל ע"י ספק דוגמת Cloudflare, Akamai, או ספק ענן. היתרונות ברורים, שירות מנוהל מעביר את הבעיה למישהו אחר. אולם, יש מקרים שבהם היתרון הוא בעצם חיסרון: העברת בעלות על ה- DNS הארגוני לידיים של צד ג' הוא לא נכון לכל ארגון, כיוון שזה מחייב כי גם המאסטר נמצא בשליטתו של נותן השירות. השיקולים בעד ונגד הם כמובן בהתאם לנסיבות כל מקרה לגופו.
   2. מוצרים ייעודיים ל-DNSSEC דוגמת infoblox או secure64. אלו appliances אשר מיועדים ספציפית למימוש DNSSEC ופרסום zone חתום. מוצרים אלה מגיעים בד"כ עם תקינה ו- HSM מובנה (הרכיב השומר על המפתחות). יש להם ממשק משתמש נוח, וכל פעולות ניהול ה- zone, החתימה וההפצה נעשות באמצעותו. בנוסף יש ליווי ותמיכה של נותן השירות. החיסרון של appliances  כאלה הוא המחיר, ולעיתים גם חוסר גמישות.
   3. בדומה לסעיף הקודם, מוצרים שאינם ייעודיים אבל ניתן להשתמש בהם ע"מ לחתום על zone. דוגמת Big-Ip של F5.
   4. מימוש DNSSEC באמצעות תוכנת ה- DNS:
      תוכנת ה- DNS הנפוצה ביותר – BIND של ISC היא חינמית, תומכת בצורה מלאה ב-DNSSEC (כמו גם תוכנות DNS של יצרנים אחרים דוגמת "KNOT" הידועה בחדשנות והביצועים שלה). יש הרבה מאוד מידע ברשת בכלל ובאתר של ISC בפרט, על הגדרת התצורה של BIND, והפעלת יכולת DNSSEC. תיעוד של גרסת BIND האחרונה – 9.18.14 ניתן למצוא כאן: https://bind9.readthedocs.io/en/v9.18.14/index.html
      התיעוד כולל גם פרק על DNSSEC, כאן:  https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html#
      ניתן להפעיל DNSSEC עם BIND במגוון אופנים. נתמקד בשניים המוכרים:
      1. ישירות על שרת המאסטר. כל שינוי שמתבצע ב- zone, נחתם אוטומטית, ומופץ לשרתי ה- slave מיד אחרי טעינת השינויים (פקודת rndc reload).
         
      2. מאסטר חבוי. כלל האצבע הוא שעדיף לא לחשוף את המאסטר לעולם. לאחר ביצוע שינוי של zone על המאסטר, הוא מועבר ב- zone transfer לשרת חתימה (שהוא למעשה סלייב, שגם עליו רץ שרת DNS מסוג BIND). עם קבלת הודעת "notify" מהמאסטר, שרת החתימה טוען את ה-zone המעודכן, חותם עליו ומפיץ לסלייבים. ארכיטקטורה זו נקראת "Bump in the wire". ניתן ורצוי כמובן, לשלב FW בין כל רמה בתהליך.
         
      3. תצורה של Bump in the wire ללא חשיפה של השרת החותם לעולם:
         הערה: תוכנת BIND מאפשרת לממש DNSSEC גם עם  HSM.
         לפי היצרן,  BIND תומך ב- API הסטנדרטי ל- HSM, הקרוי PKCS#11, אולם יש לוודא תאימות.
         קריאה נוספת כאן: https://kb.isc.org/docs/bind-9-pkcs11
         
   5. שימוש בתוכנת חתימה ייעודית. לדוגמא OpenDNSsec.  זוהי תוכנה חינמית של שרת חתימות DNSSEC, ללא תלות בסוג שרתי ה- DNS בסביבה. התוכנה מיועדת לפעול מול HSM. בהיעדר HSM אמיתי, ניתן להשתמש באמולציה הנקראת "SoftHSM" (זוהי תוכנה חינמית המדמה HSM אמיתי, כולל גישה דרך  api  תקני של HSM הקרוי PKCS11. המפתחות נשמרים  מוצפנים על הדיסק).

      תוכנת OpenDNSsec מאפשרת גמישות מלאה בארכיטקטורה: הפרדה מלאה בין סביבת החתימה לסביבת ה- DNS, ולמעשה מאפשרת לייצר כל ארכיטקטורה העולה על הדעת.
      לדוגמא, ניתן לשמור ולערוך את קובץ ה- zone טקסטואלית, על שרת קבצים אחורי
      (zone המכיל אלפי רשומות ניתן אפילו לבנות מתוך DB טבלאי רגיל), ואת התוצר להעביר לשרת החתימה בכל דרך העולה על הדעת:  ftp,ssh/scp,  באמצעי אוף-לייני נייד או ע"י zone transfer של DNS. לאחר החתימה ניתן להעביר את ה- zone החתום שוב, בכל דרך רצויה. תוך כדי התהליך ניתן ורצוי להוסיף בדיקות מותאמות באמצעות סקריפטים.