יש להכין את השרת והאישור עבור שם המארח המיועד, לבדוק את האפליקציה לפני שינוי DNS הציבורי, ולהשאיר את הסביבה הישנה זמינה במהלך המעבר. יש לאמת רשומות סמכותיות, תשובות במטמון ו-TLS בנפרד. עדכון DNS לבדו לא מבסס שהאפליקציה והאישור הנכונים מוגשים.
יש למפות את השמות והתלויות
יש לרשום כל שם מארח שהאתר משתמש בו, כולל הדומיין הראשי, כינויים, נקודות קצה של API וקריאות חוזרות של האפליקציה. יש לתעד מי שולט ברישום וב-DNS הסמכותי. אירוח אפליקציה לא רושם את הדומיין שלה באופן אוטומטי ולא נותן למפעיל השרת שליטה ברשומות שלה. יש לשמור גישה לסביבה הקיימת עד שהחדשה אומתה.
יש גם לזהות רשומות דואר ואימות של צד שלישי שהמעבר צריך לשמר. מעבר אתר לא צריך להחליף באקראיות אזור DNS שלם. יש להכין תוכנית שינוי ברמת הרשומה עם הכתובות המיועדות וערך חזרה לאחור. יש לאחסן אישורים באופן פרטי; המדריך צריך בעלים ונהלים ולא סיסמאות בפועל או אסימוני API.
יש להכין ניתוב לפי שם מארח בשרת החדש
מכונה שמקבלת חיבור חייבת להגיש את האפליקציה המיועדת עבור שם המארח שלה. יש להגדיר את שרת האינטרנט או לוח האחסון בהתאם, כאשר שורש המסמכים הציבורי מופרד מתצורה פרטית ומאישורים. יש לבדוק את כל השמות וההפניות הנדרשים, ולא רק עמוד ברוכים הבאים גנרי שנגיש דרך כתובת השרת.
יש להשתמש בשיטת בדיקה מבוקרת ששולחת את שם המארח המיועד לנקודת הקצה החדשה לפני השינוי הציבורי. יש לבדוק התחברות, העלאות וקישורים שנוצרים על ידי האפליקציה היכן שרלוונטי. יש להשבית משימות שעלולות לשכפל פעולות ייצור במהלך הבדיקה. הבדיקה צריכה להוכיח התנהגות אפליקציה בלי לשלוח דואר אמיתי, לגבות תשלומים או לשנות את מסד הנתונים החי הישן שלא בכוונה.
יש לבחור שיטת אימות אישור
הנפקת אישור דורשת הוכחת שליטה בשמות המבוקשים. Let's Encrypt מתעד HTTP-01 ו-DNS-01 בין שיטות האימות שלו. אימות HTTP תלוי בהגשת האתגר הנדרש כראוי; אימות DNS משתמש ברשומת DNS מוגדרת ויכול לתמוך בהנפקת wildcard. יש לבחור שיטה שמתאימה לפריסה בפועל וניתנת לתחזוקה בטוחה.
יש לשמור על אישורי אימות בהיקף מצומצם היכן שאפשר. אוטומציה של DNS רגישה במיוחד מפני שאישורי DNS רחבים יכולים להשפיע על יותר מאתר אחד. יש לתכנן חידוש אישור וכיצד הקבצים המחודשים מגיעים לתהליך ההגשה. הנפקה ראשונה מוצלחת שימושית, אבל אתר זקוק גם לתהליך חידוש עובד ולניטור של האישור שהוא באמת מציג.
יש לתכנן את חלון המטמון לפני שינוי DNS
רשומות DNS נושאות time-to-live שבו משתמשים פותרים בעת שמירה במטמון של תשובות. שינוי רשומה לא מחליף באופן מיידי כל תוצאה שנשמרה במטמון. אם מעבר נהנה מ-TTL קצר יותר, יש לתכנן את ההתאמה מוקדם מספיק כדי שתשובות שנשמרו קודם במטמון יפוגו. יש להשאיר גם את הסביבה הישנה וגם את החדשה מסוגלות להתמודד עם המעבר שתיכננת.
הרצף הממחיש הזה מפריד בין הכנה למעבר הציבורי. יש להתאים את התזמון שלו לדומיין, להתנהגות הפותר ולאפליקציה. זה לא לוח זמנים אוניברסלי להתפשטות. מעבר שכולל כתיבות חיות דורש גם מעבר נתונים ייעודי לאפליקציה, מפני ששני שרתי אינטרנט פעילים יכולים אחרת לקבל שינויים למערכי נתונים שונים.
| שלב | פעולה | תנאי לפני המשך |
|---|---|---|
| הכנה | מיפוי רשומות והגדרת נקודת קצה חדשה | האפליקציה עובדת עבור השמות המיועדים |
| אישור | הנפק והתקן אישור | שרשרת נכונה ושם מארח מאומתים |
| מעבר | עדכן רק רשומות DNS מתוכננות | מעבר נתונים וחזרה לאחור מוגדרים |
| תצפית | בדוק תוצאות סמכותיות ותוצאות לקוח | מסלולי משתמש מצליחים דרך נקודת הקצה החדשה |
| השלמה | הוצא משירות את השירות הישן לאחר אימות | תעבורה שיורית וצורכי שחזור נסקרו |
יש לאמת DNS ו-TLS בנפרד
יש לבדוק תחילה את הרשומה הסמכותית, ואז להשוות תשובות מלקוחות או פותרים המעורבים במעבר. ערך סמכותי נכון וערך ישן במטמון יכולים להתקיים במקביל. יש לבדוק את נקודת הקצה שאליה מגיע הדפדפן במקום להניח שכל חיבור כבר משתמש בכתובת החדשה. יש לשמור תצפיות עם חותמות זמן כך שהמעבר יהיה מובן.
עבור TLS, יש לאמת את שם המארח המיועד, תוקף האישור והשרשרת דרך חיבור לקוח בפועל. יש לבדוק כל כינוי ונתיב הפניה נדרשים. התיעוד של Mozilla TLS מסביר אימות שרת וחששות תוכן מעורב: העמוד ותת-המשאבים שלו צריכים להיות מוגשים באופן מאובטח. אישור על שם מארח אחד לא מכסה באופן אוטומטי נקודת קצה אחרת של אפליקציה.
יש להפוך את החזרה לאחור גם להחלטת נתונים
חזרה לאחור של DNS יכולה להפנות תעבורה, אבל היא לא הופכת כתיבות שנעשו באפליקציה החדשה. יש להגדיר כיצד תטפל בנתונים האלה לפני המעבר. עבור פרסום סטטי, חזרה לאחור עשויה להיות פשוטה; עבור שירות שמקבל העלאות או הזמנות, מצב האפליקציה צריך בעלים ברור ונוהל התאמה.
תאר לעצמך מעבר של אתר פרסום קטן עם תגובות. אפשר להכין חלון תחזוקה או מעבר מבוקר לקריאה בלבד בזמן העתקת הנתונים הסופיים. יש לבדוק את נוהל הפתיחה מחדש ולהשאיר את הפריסה הישנה מוכנה. יש לבחור את הגישה שמתאימה לאפליקציה במקום להשתמש בשינוי DNS כתחליף לתכנון עקביות.
יש לצפות באתר לאחר ההחלפה
יש לאמת מסלולי משתמש אמיתיים, שיעורי שגיאה, הצגת אישור ומשימות רקע לאחר שנקודת הקצה החדשה מקבלת תעבורה. יש לאשר שהגיבויים מכסים כעת את האפליקציה והנתונים המיועדים. יש לסקור גישה לשרת הישן לפני הוצאתו משירות ולהסיר אישורים מיושנים לאחר שצורכי השחזור והחזרה לאחור נפתרו. יש לתעד את תצורת DNS והאישור הסופית.
בעת בחירת אחסון אתרים או מחשוב של SwissOctet, יש לאשר את האחריות בפועל לדומיין, לאישור ולניהול עבור התצורה. הקטלוג מספק יעד אחסון ומשאבים; הוא לא מבסס שהדומיין שלך כבר חובר או שחידוש אישור הוגדר. יש לשמור על השלבים האלה קונקרטיים וניתנים לאימות בתוכנית הפריסה.
רשימת הבדיקה המעשית שלך.
- יש למפות כל שם מארח ולשמר רשומות DNS לא קשורות.
- יש לבדוק ניתוב לפי שם מארח לפני המעבר הציבורי.
- יש לבחור ולהפוך לאוטומטי אתגר אישור מתאים.
- יש לתכנן שינויי TTL ואת מעבר הנתונים.
- יש לאמת DNS ו-TLS דרך בדיקות נפרדות.
- יש לשמור גישת חזרה לאחור ולפתור כתיבות חדשות לפני החזרה.
הפרטים שחשובים.
האם שינוי רשומת A מפעיל את HTTPS?+
לא. DNS בוחר נקודת קצה; נקודת הקצה הזו עדיין צריכה ניתוב נכון לפי שם מארח ואישור תקף ומותקן.
האם אני יכול להחזיר רק את רשומת DNS אם משהו נשבר?+
ניתן להפנות תעבורה, אבל כתיבות אפליקציה דורשות טיפול נפרד. יש להגדיר תוכנית חזרה לאחור או התאמה של נתונים לפני המעבר.
האם אישור wildcard תמיד נחוץ?+
לא. יש לבחור שמות אישור ואימות בהתאם לשמות המארח בפועל. ל-wildcard יש כיסוי ודרישות אימות ספציפיים; הוא לא קיצור דרך אוניברסלי למעבר.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- Let's Encrypt: סוגי אתגרים letsencrypt.org
- IETF RFC 1034: מושגים ומתקנים של DNS datatracker.ietf.org
- Mozilla MDN: Transport Layer Security developer.mozilla.org
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.