העברה או מיגרציה של אזורים שמופעל בהם DNSSEC

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

סקירה כללית של DNSSEC זמינה במאמר סקירה כללית של DNSSEC.

לפני שמתחילים

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

תיאום עם מפעילי DNS ורשם הדומיין

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

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

המתנה עד שתוקף המטמון של מפענחי ה-DNS יפוג

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

מגבלות

ההגבלות הבאות חלות על העברה של אזור DNSSEC:

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

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

  • צריכה להיות לכם אפשרות לייבא רשומות DNSKEY מ-Cloud DNS לתחום של המפעיל השני, ולחתום על הרשומות האלה באמצעות המפתחות של המפעיל. ב-Cloud DNS אפשר להוסיף רשומות DNSKEY לאזורים במצב Transfer.

  • צריך להיות לכם אפשרות להוסיף רשומת DS שנייה מ-Cloud DNS לאזור האב. רשם הדומיינים או אזור ההורה חייבים לאפשר רשומות DS שתואמות למפתחות ציבוריים שלא חותמים על רשומות באזור הצאצא.

  • צריך להיות אפשר להפסיק את רוטציית המפתחות האוטומטית על ידי המפעיל הישן או החדש של האזור עד להשלמת ההעברה. ‫Cloud DNS מפסיק באופן אוטומטי את רוטציית המפתחות לאזורים במצב Transfer.

אם המפעיל החדש לא תומך בהעברה, אפשר לפעול באופן הבא:

  1. משביתים את DNSSEC אצל הרשם.
  2. מבצעים את ההעברה.
  3. הפעלת DNSSEC.
  4. מפעילים DNSSEC אצל הרשם.

למידע נוסף על DNSSEC, העברות דומיינים ובעיות פוטנציאליות, אפשר לעיין במאמר DNS/DNSSEC and Domain Transfers: Are they compatible?‎.

מעבר בין אופרטורים

הגישה הטכנית שבה נעשה שימוש ב-Cloud DNS להעברות DNSSEC היא וריאציה של החלפת מפתח חתימה (KSK) עם Double-DS, שמתוארת בנספח D של RFC 6781: גישה חלופית להחלפת מפתח למפעילים משתפים.

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

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

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

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

העברת אזורים עם חתימת DNSSEC ל-Cloud DNS

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

כדי לבצע את ההעברה, פועלים לפי השלבים הבאים:

  1. מפסיקים את כל רוטציית המפתחות באזור בשרת השמות הישן.

  2. יצירת אזור חדש עם חתימת DNSSEC במצב DNSSEC Transfer. המצב Transfer מפסיק את רוטציית המפתחות ומאפשר ייבוא של DNSKEY.

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

  3. מייצאים את קובצי האזור הלא חתומים ומייבאים אותם לאזור החדש.

    פועלים לפי ההוראות של הספק לייצוא נתוני אזורים.

    אפשר לכלול רשומות DNSKEY בשלב הזה, אבל לא לכלול סוגים אחרים של רשומות DNSSEC מהאזור הקיים (סוגי CDS,‏ CDNSKEY,‏ NSEC,‏ NSEC3,‏ NSEC3PARAM או RRSIG).

    אפשר לייבא אזורים באמצעות הפקודה gcloud dns record-sets import.

  4. מאחזרים את רשומות ה-DNSKEY הקודמות משרת השמות הישן.

    אפשר גם להשתמש ב-dig או ב-delv כדי לשלוח שאילתה לגבי רשומות DNSKEY, אבל צריך לוודא שהמפתחות הציבוריים שמוחזרים נכונים ותקפים לאזור שלכם.

  5. מאחזרים את רשומות ה-DNSKEY החדשות מ-Cloud DNS. במצב Transfer, רשומות DNSKEY מופיעות כמו רשומות רגילות באזור.

  6. מוסיפים לאזור Cloud DNS את רשומות ה-DNSKEY הקיימות, בנוסף לרשומות ה-DNSKEY שנוצרו אוטומטית.

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

  7. מוסיפים את רשומות ה-DNSKEY החדשות מ-Cloud DNS לאזור באופרטור הקיים. אם צריך, חותמים מחדש על האזור.

  8. מוסיפים את רשומת ה-DS לאזור Cloud DNS לרשם הדומיינים, בנוסף לרשומת ה-DS הקיימת.

  9. מחכים עד שהרשומות החדשות יתעדכנו ושהתוקף של הרשומות הישנות יפוג בכל מטמון של מפענחי DNS. אחרת, נתונים לא עדכניים עלולים לגרום לכשלים באימות.

    מחכים עד שכל התנאים הבאים מתקיימים:

    • הרשומות מועברות לכל שרתי השמות שבהם נעשה שימוש על ידי המפעיל הקודם.

    • תוקף ה-TTL של קבוצת רשומות ה-NS באזור האב פג.

    • תוקף ה-TTL של קבוצת רשומות ה-DS באזור ההורה פג.

    • תוקף ה-TTL של קבוצת רשומות ה-NS באזור הצאצא של המפעיל הישן פג.

    • תוקף ה-TTL של קבוצת רשומות ה-DNSKEY של אזור הצאצא אצל הספק הקודם פג.

  10. כדי לוודא שהאזור מוכן, בודקים שהמפעיל הישן מציג את כל רשומות DNSKEY, ושאזור האב מציג את שתי רשומות DS.

  11. משנים את ההפניות של שרתי השמות כך שיצביעו על Cloud DNS.

    מעדכנים את רשומות שרתי השמות אצל הרשם לשרתי השמות של Cloud DNS עבור האזור החדש.

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

    מחכים עד שכל התנאים הבאים מתקיימים:

    • תוקף ה-TTL של קבוצת רשומות ה-NS באזור האב פג.

    • תוקף ה-TTL של קבוצת רשומות ה-NS באזור הצאצא של המפעיל הישן פג.

    אחרי השלב הזה, אפשר להפסיק את הצגת המודעות באזור אצל הספק הישן.

  13. מסירים את רשומות ה-DNSKEY של תחום ה-DNS הישן שנוספו לתחום Cloud DNS.

  14. שינוי סטטוס ה-DNSSEC של האזור מTransfer לOn.

    יציאה ממצב העברה מאפשרת רוטציית מפתחות אוטומטית לאזור. אחרי שבוע, האזורים שלכם יכולים לצאת בבטחה ממצב העברה של DNSSEC, ואסור להם להישאר במצב הזה יותר מחודש או חודשיים.

  15. מסירים את רשומת ה-DS של האזור של האופרטור הישן מרשם הדומיינים.

העברת אזורים עם חתימת DNSSEC מ-Cloud DNS

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

כדי לבצע את ההעברה, פועלים לפי השלבים הבאים:

  1. משנים את מצב ה-DNSSEC מOn לTransfer. הפעולה הזו תפסיק את רוטציית המפתחות.

  2. מייצאים את קובץ האזור ומייבאים אותו אל המפעיל החדש.

    אפשר להשתמש ב-gcloud dns record-sets export כדי לייצא אזור.

    ייצוא של אזור במצב Transfer מייצא גם רשומות DNSKEY מ-Cloud DNS. אם הספק מקבל DNSKEY בשלב הזה, אפשר לכלול אותם עכשיו ולדלג על השלבים הבאים שבהם מעבירים מפתחות ציבוריים מ-Cloud DNS לספק החדש.

  3. חותמים על האזור אצל הספק החדש.

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

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

  4. מאחזרים את רשומות ה-DNSKEY מ-Cloud DNS. במצב Transfer רשומות DNSKEY מופיעות כמו רשומות רגילות באזור.

    אפשר גם להשתמש ב-dig או ב-delv כדי לשלוח שאילתה לשרתי השמות של Cloud DNS לגבי רשומות DNSKEY, אבל צריך לוודא שהמפתחות הציבוריים שמוחזרים נכונים ותקפים לאזור שלכם.

  5. מאחזרים את רשומות ה-DNSKEY החדשות מהמפעיל החדש.

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

  6. מוסיפים את רשומות ה-DNSKEY של Cloud DNS לאזור של האופרטור החדש בנוסף לרשומות ה-DNSKEY של האזור החדש.

  7. מוסיפים את רשומות ה-DNSKEY מהמפעיל החדש ל-Cloud DNS.

  8. מוסיפים את רשומת ה-DS של האזור של האופרטור החדש לרשם הדומיין, בנוסף לרשומת ה-DS הקיימת מ-Cloud DNS.

  9. מחכים עד שהרשומות החדשות יתעדכנו ושהתוקף של הרשומות הישנות יפוג בכל מטמון של מפענחי DNS. אחרת, נתונים לא עדכניים עלולים לגרום לכשלים באימות.

    מחכים עד שכל התנאים הבאים מתקיימים:

    • תוקף ה-TTL של קבוצת רשומות ה-NS באזור האב פג.

    • תוקף ה-TTL של קבוצת רשומות ה-DS באזור ההורה פג.

    • תוקף ה-TTL של קבוצת רשומות ה-NS של תחום DNS ב-Cloud פג.

    • תוקף ה-TTL של קבוצת רשומות ה-DNSKEY של תחום ה-DNS ב-Cloud DNS פג.

    כדי לוודא שהתחום מוכן, בודקים ש-Cloud DNS מציג את כל רשומות ה-DNSKEY, ושהתחום הראשי מציג את שתי רשומות ה-DS.

  10. מעבירים את ההרשאות של שרת השמות כך שיצביעו על האופרטור החדש.

    מעדכנים את רשומות שרתי השמות אצל הרשם לשרתי השמות של המפעיל החדש באזור.

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

    צריך להמתין עד שתוקף הפסילות הבאות יפוג:

    • ה-TTL של קבוצת רשומות ה-NS באזור ההורה.

    • ה-TTL של קבוצת רשומות ה-NS של תחום ה-DNS ב-Cloud DNS.

    אחרי השלב הזה, אפשר למחוק את האזור מ-Cloud DNS.

  12. מסירים את רשומות ה-DNSKEY של Cloud DNS שנוספו לאזור החדש.

  13. מסירים את רשומת ה-DS של Cloud DNS מהרשם.

  14. במידת הצורך, מסיימים את המיגרציה אצל הספק החדש.

אם למפעיל ה-DNS השני יש תהליך להעברת אזור עם חתימת DNSSEC, צריך לבצע את השלבים שלו במקביל לתהליך הזה, אחרי שלב 1.

המאמרים הבאים