החזירו אותם הביתה עכשיו

    הרשמה לניוזלטר

    כל השדות הם חובה למילוי

    אימות שאילתות DNS – מדריך DNSSEC

    הגדרת מדיניות

    DNSSEC פועל לפי מדיניות. לכל מוצר יש מדיניות דיפולטיבית, "ישר מהקופסא" אולם נכון לערוך אותה בהתאם לפרמטרים תפעוליים רצויים והסטנדרטים של הארגון.
    מדיניות DNSSEC  נקראת Key And Signing Policy – KASP.
    בתוכנת  OpenDNSsec זהו קובץ XML ואילו ב- BIND זהו חלק מה-config (החל מגרסא 9.16).

    ניתן להגדיר מדיניות אחת או יותר (אם יש הבדלים בין zones שונים, ניתן לייצר לכל אחד מדיניות משלו).  במדיניות KASP מוגדרים הפרמטרים שעל פיהם ממומש DNSSEC על השרת.

    להלן דוגמא לחלק מהגדרות KASP של תוכנת OpenDNSsec:

    1. באיזה אלגוריתם לחולל מפתחות? עדיף כמובן ECDSA, שהוא בעל מפתחות חזקים וקטנים בהרבה לעומת RSA.
    2. אילו סוגי מפתחות לייצר? האם ZSK + KSK או שמא מפתח משולב מסוג CSK?
      בעידן שלפני ECDSA, אפשר היה לחולל רק מפתחות RSA גדולים. כיוון שאת ה- KSK נרצה להחליף בתדירות נמוכה ככל שאפשר (כי המשמעות של החלפת KSK  היא גם החלפת ה- DS שמצביע עליו מהרמה שמעל), היה נהוג לייצר KSK גדול (באורך של לפחות 2048), ואותו להחליף פעם בשנה. לעומתו ה- ZSK קטן יותר, בגודל – 1024, ואותו התוכנה מחליפה אוטומטית כל 4 חודשים (כזכור חוזק המפתח תלוי במידה רבה באורכו). המוטיבציה של שימוש ב- ZSK קטן היא הרצון לא "לנפח" את גודל התשובה המוחזרת ע"י שרת ה- DNS, תוך החלפתו בתדירות גבוהה יותר.
      בעידן ה- ECDSA ניתן לחולל מפתחות קטנים בהרבה: P-256, שקול ל- RSA בגודל 3072.
      לכן, ניתן לחולל מפתח אחד -CSK שמשמש גם כ- ZSK וגם KSK  ואותו להחליף פעם בשנה.
    3. האם גלגול (החלפת) מפתחות מתבצע ידנית או אוטומטית ע"י התוכנה?
      גלגול ידני: נדרש פיזית להקיש את הפקודה המורה על גלגול מפתח. האחריות לתזמן ולבצע החלפת מפתח היא על מנהל המערכת. לחילופין, אם במדיניות מוגדרת החלפה אוטומטית, אזי תוכנת החתימה תגלגל את המפתחות לפי התזמון שנקבע במדיניות ( בכל מקרה, תמיד יש לזכור כי אחרי גלגול KSK יש לעדכן DS ברמה מעל!). מקובל לתת את התזמונים הבאים:
      • מפתח מסוג RSA באורך 1024 כל רבעון (פעם ב- 3 חודשים).
      • מפתח RSA באורך 2048 פעם בשנה. עדיף לא לחולל מפתחות ארוכים מזה, ולהקפיד שרק ה- KSK הוא באורך 2048.
      • מפתח ECDSA P-256 ניתן לגלגל פעם בשנה.
    1. כמה זמן לאחר גלגול מפתחות יש להמשיך ולפרסם גם את המפתח הישן (במקביל לחדש)? עקרונית התשובה היא ה- TTL של החתימה. כל זמן שיש סיכוי שחתימה עם המפתח הישן עדיין קיימת, חובה לפרסם את המפתח המתאים לה. לכן, אם למשל ה- TTL הוא יום, אזי יש להמשיך ולפרסם את המפתח הישן יום נוסף. נהוג להשאיר מפתח ישן יום נוסף לאחר החלפתו גם אם ה- TTL נמוך יותר. כאשר מדובר ב- KSK, יש לזכור את ה- DS:
      כל זמן ש- KSK נמצא ב-zone יש להמשיך ולפרסם את ה- DS שמתאים לו. אחרי החלפה, כאשר ה- KSK הישן כבר לא מתפרסם, יש לזכור להסיר את ה- DS שמתייחס אליו.
    2. מאגר המפתחות שאליו פונים (שם לוגי של המחיצה ב- HSM שבה נמצאים המפתחות).
    3. מה אורך החיים של המפתחות (כמה זמן מפתח פעיל עד שהוא מוחלף)?
    4. תוקף של חתימה. ניתן כאמור, להגביל את הזמן שבו חתימה היא ולידית, כך שרק בפרק הזמן הזה היא ניתנת לאימות. תוקף של חתימה נדרש במקרים שבהם המידע המקורי משתנה. במקרים כאלה לא נרצה שאפשר יהיה לאמת מידע ישן מדי. זהו בדיוק המצב בחתימה על רשומות DNS. מהו אם כן התוקף הרצוי? תוקף ארוך עלול לאפשר אימות מידע ישן ולא רלוונטי, ואילו תוקף חתימה קצר מדי עלול להוות בעיה במקרה שלא ניתן לפרסם zone מסיבה כלשהי במשך התקופה שהוגדרה (למשל במקרה של כשל כללי במערכת, כזה שמחייב הקמת התשתית מחדש). כאשר לא ניתן להפיץ או לחתום DNSSEC, עלול להיווצר מצב שרשומות ה-DNS הקיימות בעולם (בסלייבים) עברו את התוקף ואינן ניתנות לאימות. זהו מצב חמור שמשמעותו היא הפסקת שירות ה- DNS. מקובל להגדיר תוקף של חודש.
    5. מתי לחדש חתימה? (בהמשך לסעיף הקודם) כמה זמן לפני שפג תוקפה של חתימה קיימת, יש לייצר חתימה חדשה? (גם כאשר לא בוצעו שינויים ב- zone  שאז מן הסתם הוא חייב להיחתם מחדש). ניתן להגדיר לתוכנה לחתום מחדש גם יום לפני התוקף אבל זהו סיכון. אם לעומת זאת התוקף הוא 30 יום, ומוגדר לחדש אותה  29 יום לפני כן, אזי החתימה תתחדש כל יום, ובכך נאפשר תוקף מלא של החתימה כל יום מחדש. לחילופין אפשר גם להגדיר ערך סתמי כלשהו, ולדרוס אותו ע"י כך שכל יום חותמים ידנית ע"י הרצת פקודה או בסקריפט מתוזמן. גם כאן יתקבלו כל יום חתימות חדשות שתקפות ל- 30 יום הבאים. לכל גישה יש השלכות לכאן ולכאן. הנוהג הוא לחדש חתימה כל יום גם אם התוכן לא השתנה, ובכך לקיים חתימות עם תוקף מלא כל יום מחדש.
    6. כל כמה זמן מנוע החתימה "מתעורר" ובודק האם יש zone מעודכן לחתימה. גם ערך זה ניתן למניפולציות. ניתן לתזמן את  מנוע החתימה לבדוק כל קבוע זמן, או בדומה לקודם, לבצע ידנית ע"י פקודת חתימה כשידוע שמגיע לשרת  zone מעודכן.
    7. הגדרה של "הוכחת אי קיום" – "Proof of non-existence". כזכור, DNSSEC חותם על תשובה שלילית באמצעות NSEC או NSEC3. יש להגדיר במדיניות במי מבין השניים ייעשה שימוש. מקובל כיום שעדיף NSEC, אם אין ברירה ובכל זאת נבחר להשתמש ב- NSEC3, אז במדיניות יוגדרו הפרמטרים של NSEC3: (שיפורסמו ברשומת NSEC3PARAM)
      • כמה פעמים להריץ hash  על כל שם דומיין?
      • האם להוסיף SALT לחישוב?
      • האם לעשות opt-out לדלגציות לא חתומות

    ההגדרה המומלצת לפרמטרים אלה היא ללא איטרציות, ללא SALT ואם אפשר ללא opt-out.

    הנקודות שהוצגו לעיל הן חלק מההגדרות האפשריות במדיניות של OpenDNSsec.

    המדיניות של BIND שונה, גם במבנה וגם בתוכן, אולם המהות דומה.

    תיעוד מדיניות OpenDNSsec  כאן: https://wiki.opendnssec.org/display/DOCS20/kasp.xml

    וכאן: https://github.com/opendnssec/odslab/blob/master/opendnssec-lab.md

    תיעוד מדיניות BIND ניתן למצוא כאן: https://kb.isc.org/docs/dnssec-key-and-signing-policy

    וכאן: https://www.sidn.nl/en/modern-internet-standards/dnssec-signatures-in-bind-named

    מדריך DNSSEC של BIND:

    https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html#dnssec-guide

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

    מפאת חוסר מקום הדוגמא מחולקת, אולם מדובר כמובן בקובץ XML אחד.

    1. שם המדיניות
    2. הגדרות חתימה:
      • תג Resign = כל כמה זמן השירות מתעורר ובודק אם יש zone לחתימה
      • תג Refresh = כמה זמן לפני התוקף יש לחתום מחדש (גם אם ה-zone לא השתנה)
      • תג validity = תוקף חתימה (31 יום = P31D)

      הערה: resign ו- refresh הם ערכים משמעותיים כאשר התהליך הוא אוטומטי. המנוע של OpenDNSSec "יתעורר" לפי קבועי הזמן המוגדרים בערכים הללו. בשורה התחתונה, אם יש קובץ zone על השרת , אזי התוכנה תתנהג לפי הערכים הללו. לחילופין, אם החתימה על ה- zone נעשית  בצורה ידנית ע"י הרצת פקודת חתימה (דוגמא בהמשך), או ע"י סקריפט חיצוני,  אז ערכים אלה חסרי משמעות (כמו בדוגמא).

    3. תצורת NSEC. כאן מוגדר: NSEC3 עם opt-out, ללא איטרציות נוספות וללא SALT
    4. מפתחות: כמה זמן אחרי גלגול מפתח אפשר לפרסם את המפתח החדש, וכמה זמן אחרי הגלגול להשאיר את הישן. התג "SharedKeys" מציין שניתן להשתמש באותו מפתח ע"מ לחתום על  zone-ים שונים שמנוהלים ע"י המדיניות הזו (וכך לחסוך בכמות המפתחות על ה- HSM).
    5. הגדרות KSK: אלגוריתם 13 = ECDSA, אורך מפתח 256, תוחלת- שנה (=P1Y), והיכן נשמר (המיקום הלוגי "MyHSM" , יוסבר בפרק הבא).
      התג "ManualRollover", אם היה מופעל משמעותו: לא לגלגל את המפתח בצורה אוטומטית, גם אם המועד הגיע, אלא רק ע"י פקודה ידנית מפורשת.
    6. כנ"ל הגדרות ZSK, במקרה זה מתחלף כל 120 יום.
    7. הגדרות רשומת SOA: רשומה זו מחזיקה את המספר הסיריאלי של ה-zone. כיוון שפעולת חתימה משנה את ה- zone, יש לעדכן את המספר הסידורי. בדוגמא מוצגת החלופה "keep" שמשמעותה: עדכון המספר הסיריאלי לא ייעשה ע"י OpenDNSsec. זה נעשה במקום אחר (וכמובן לפני החתימה, אחר כך אסור לשנות דבר!).

    בשרת חתימה מבוסס  BIND קובץ המדיניות שונה, אולם המהות דומה. להלן דוגמא ל-KASP שאפשר להגדיר בשרת מסוג BIND (מתוך הקישור שניתן קודם לכן): https://www.sidn.nl/en/modern-internet-standards/dnssec-signatures-in-bind-named

    כאן ניתן לראות שהמפתחות הם מסוג RSA (אלגוריתם 8), ה- KSK ענק באורך 4096, מתחלף פעם בשנה. ה-ZSK גם גדול מאוד ומתחלף כל חודש. שניהם נשמרים במחיצה מקומית על השרת. הגדרות NSEC3: ללא איטרציות נוספות, ללא SALT וללא opt-out. תוקף חתימה 14 יום. כיוון ששרת BIND מנהל את ה-zone, אזי שינוי המספר הסידורי נעשה על ידו בכל מקרה.