📘 תיעוד 36

אודות

עודכן לאחרונה: 16 באפריל 2026

Multi-signer DNSSEC מורכב משני מודלים שמאפשרים לספקי DNS סמכותיים שונים לשרת את אותו אזור ולהפעיל DNSSEC באותו זמן.

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

אפשר להגדיר multi-signer DNSSEC באמצעות אחד מהמודלים שמתוארים ב-RFC 8901 ↗︎.

#איך זה עובד

הערה

זה הסבר מפושט שנועד לתת הקשר ולהבהיר מה מעורב ב-הגדרת multi-signer DNSSEC. לפרטים טכניים פנו אל RFC 8901 ↗︎. לקריאה נוספת על DNSSEC, פנו אל How DNSSEC works ↗︎.

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

דוגמה למקרה שבו האימות היה אחרת בעיה היא אם resolver שמר במטמון קבוצת רשומות DNSKEY ↗︎ מספק אחד, אבל מקבל תשובה שנחתמה על ידי ספק אחר.

כדי להימנע מבעיות במקרה הזה, כשמגדירים multi-signer DNSSEC, מתאימים:

1. את מפתחות חתימת האזור (ZSK) שיש לספקי ה-DNS בקבוצות רשומות ה-DNSKEY שלהם.
2. מי אחראי על נקודת הכניסה המאובטחת (SEP), על מפתחות חתימת המפתח (KSK), ועל רשומת Delegation Signer (DS).

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

#מודל 1

בעוד שבשני המודלים לכל הספקים נוספו מפתחות חתימת האזור (ZSK) זה של זה לקבוצת רשומות ה-DNSKEY שלהם, במודל 1 משתמשים רק במפתח חתימת מפתח (KSK) אחד כדי לחתום על קבוצות רשומות DNSKEY כאלה. הניהול של KSK זה, וההפניה אליו על ידי רשומת ה-DS (כלומר, נקודת הכניסה המאובטחת), הם באחריות בעל האזור או ספק אחד בלבד (שמיועד על ידי בעל האזור).

#מודל 2

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

#מה קורה כש-multi-signer DNSSEC פועל

כשמפעילים multi-signer DNSSEC ב-Cloudflare, מתרחשים השינויים הבאים:

1. דגל פנימי: Cloudflare מגדיר דגל פנימי שמאפשר להוסיף רשומות DNSKEY לאזור.
2. ZSK חיצוניים כלולים: כשמוסיפים רשומות DNSKEY מהספק המשני, Cloudflare כולל אותן ב-DNSKEY RRset.
3. חתימה עם ה-KSK של Cloudflare: Cloudflare חותם על ה-ZSK החיצוניים עם ה-KSK של Cloudflare, ויוצר Multi-signer DNSSEC Model 2 RRset.
4. יצירת CDS/CDNSKEY: אם מוסיפים את ה-KSK של הספק האחר (לא חובה אבל מומלץ), Cloudflare מייצר קבוצות רשומות CDS/CDNSKEY לתאימות עם כלי אימות.

ההגדרה הזו מבטיחה ש-resolvers יכולים לאמת תשובות מכל אחד מהספקים, כי כל ה-ZSK DNSKEY חתומים על ידי ה-KSK המתאימים שמופנים ברשומות ה-DS.

#שיטות עבודה מומלצות

בהגדרת multi-signer DNSSEC, פעלו לפי שיטות העבודה המומלצות שלהלן כדי לסייע בהשגת פריסה חלקה.

#השתמשו במודל 2

Cloudflare ממליץ על מודל 2 להגדרות multi-signer. במודל הזה, לכל ספק יש DNSKEY מסוג KSK משלו, וכך מתקבלות שתי רשומות DS (אחת לכל ספק). זה מספק עצמאות וגמישות טובות יותר.

#הבינו את דגלי DNSKEY

• ZSK (Zone Signing Keys): דגל 256
• KSK (Key Signing Keys): דגל 257

בחילופי מפתחות בין ספקים, ודאו שמוסיפים את סוג המפתח הנכון (בדרך כלל ZSK) ל-DNSKEY RRset.

#הקפידו על TTL

תמיד המתינו למשך ה-TTL אחרי שינויים ב-DNSKEY וברשומות DS לפני שממשיכים לשלב הבא. כך רשומות שנשמרו במטמון פגות לפני שהרשומות החדשות נכנסות לתוקף, ומונעים כשלי אימות.

#אמתו תאימות של הספק

לא כל ספקי ה-DNS תומכים בהוספת DNSKEY חיצוניים ל-DNSKEY RRset שלהם. לפני שמתחילים העברת multi-signer:

• אמתו שהספק האחר תומך ב-multi-signer DNSSEC.
• אשרו שהם יכולים להוסיף את ה-ZSK של Cloudflare לרשומות ה-DNSKEY שלהם.
• בדקו את ההגדרה בסביבה שאינה ייצור, אם אפשר.

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

#בדקו ביסודיות

Multi-signer DNSSEC כולל תיאום של מפתחות קריפטוגרפיים בין כמה ספקים. לפני פריסה לייצור:

1. אמתו שלשני הספקים יש את ה-ZSK זה של זה ב-DNSKEY RRset שלהם.
2. אשרו ששתי רשומות ה-DS נמצאות אצל הרשם.
3. השתמשו בכלי אימות DNSSEC כדי לבדוק פתרון משני הספקים.
4. עקבו אחרי שגיאות אימות במהלך תקופת המעבר.