מתי נדרש EPP בהעברת דומיין ובניהול פורטפוליו?

דומיין לא עובר בין רשמים רק כי מישהו לחץ על כפתור. ברוב סיומות הדומיינים הגלובליות, השאלה מתי נדרש EPP היא נקודת הבקרה שמפרידה בין העברה מסודרת לבין אירוע תפעולי: קוד חסר, נעילת העברה פעילה, אישור שנשלח לאיש קשר לא מעודכן, או DNS שנשאר מאחור.

EPP הוא קיצור של Extensible Provisioning Protocol, פרוטוקול המשמש לתקשורת מול מרשמי דומיינים. בפועל, כשאנשי מקצוע אומרים "קוד EPP", הם בדרך כלל מתכוונים לקוד הרשאה ייחודי - Auth Code או Transfer Code - שנדרש כדי לאשר העברה של דומיין מרשם אחד לאחר. זה אינו פרט טכני שולי. בפורטפוליו של סוכנות, חברה או צוות DevOps, הוא חלק משרשרת אבטחה, הרשאות ותיעוד שצריכה לעבוד בלי ניחושים.

מתי נדרש EPP בפועל?

קוד EPP נדרש בדרך כלל כאשר מעבירים דומיין מסיומת גנרית, כגון ‎.com, ‎.net, ‎.org או סיומות גנריות חדשות, בין שני רשמים. הרשם הקולט מבקש את הקוד, והרשם הנוכחי מאפשר להפיק אותו לאחר שהדומיין עומד בתנאי ההעברה. הקוד מוכיח שלמבקש יש גישה מורשית לניהול הדומיין, אך הוא אינו מחליף אימותי אבטחה נוספים או אישורי העברה שנדרשים בתהליך.

חשוב להפריד בין שלושה מצבים שנוטים להתערבב:

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

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

לא כל סיומת עובדת עם EPP

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

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

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

תנאים שמונעים העברה גם כשיש קוד

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

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

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

ה-DNS לא עובר אוטומטית בכל תרחיש

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

לפני העברה, תעדו את אזור ה-DNS המלא: רשומות A ו-AAAA, רשומות CNAME, MX, TXT עבור SPF, DKIM ו-DMARC, רשומות אימות שירותים, SRV, וכל הגדרת DNSSEC פעילה. אל תסתפקו בצילום מסך חלקי. רשומת TXT נשכחת יכולה לשבור אימות דוא"ל; רשומת CNAME חסרה יכולה להפיל שירות; ו-DNSSEC שלא מנוהל בתיאום יכול לגרום לכשל בפתרון הדומיין.

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

תהליך נכון להעברת דומיין עם EPP

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

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

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

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

טעויות נפוצות בפורטפוליו של סוכנויות וצוותים

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

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

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

מתי לא צריך למהר להעביר

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

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

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