תפעול מעשי
השכבות שמעל השרת שלך: דומיין, CDN, תעבורה
המארח שלך הוא רק שכבה אחת מתוך שלוש. המרשם שמעליך יכול להוציא את השם שלך מקובץ האזור בצו שיפוטי אחד, הפרוקסי שבחזית מעביר כל תלונה למארח שלך בצירוף כתובת המקור שלך, ואף אחד מהשניים אינו נמצא בסמכות השיפוט של המארח שלך.
16 דקות קריאה פורסם 28 באוגוסט 2026 נבדק היום
הבחירה היכן ישכון השרת היא החלטה אחת מתוך שלוש, ולעיתים רחוקות היא זו שקובעת את התוצאה. מעל השרת יושב שם, המופעל בידי מישהו אחר. בחזית השרת יושב, ברוב האתרים, פרוקסי הפוך המופעל בידי מישהו אחר לגמרי. אף אחד מהשניים אינו כפוף למדיניות המארח שלך, אף אחד מהם אינו נמצא בסמכות השיפוט של המארח שלך, ושניהם עשויים לקבל צו לפעול מבית משפט שאין לו כל השפעה על המארח שלך. זהו החלק במערך שאחסון offshore אינו מכסה, וכדאי לדעת בדיוק היכן הוא נעצר.
שלוש שכבות, שלושה בעלים שונים
אתר שניתן בכלל להגיע אליו תלוי בלפחות שלושה עסקים נפרדים, והם נכשלים באופן בלתי תלוי זה בזה.
השם. רשם מכר לך אותו; מרשם מפעיל את הסיומת שתחתיה הוא חי. שתי חברות, בדרך כלל שתי מדינות, והשנייה מעולם לא שמעה עליך.
החזית. אם משהו עונה בשמך — CDN, פרוקסי הפוך, קצה anycast — הוא מסיים את החיבורים של המבקרים שלך לפני שהשרת שלך רואה אותם בכלל. משום כך הוא מכיר את כתובת המקור שלך מעצם בנייתו, והוא זה שמקבל את התלונות.
התיל והמכונה. המארח שלך, ספקי התעבורה שלו, המתקן, וטווח הכתובות שהשרת שלך יושב בתוכו. זו השכבה שאנשים קונים בפועל, וזו היחידה מבין השלוש שסמכות השיפוט של האחסון אכן שולטת בה.
ההרגל שכדאי לשבור הוא לחשוב על שלוש אלה כרכישה אחת. הן שלוש, והפקדת כל השלוש ביד אחת — או במערכת משפטית אחת — היא הדרך שבה צו יחיד מפיל הכול בבת אחת.
הדין האירופי כבר שרטט את המפה הזו, וזו מפה שימושית. ה-DSA ממיין מתווכים לשלושה סוגים: mere conduit, caching ו-hosting. סעיף ההנמקה 29 מגדיר מרשמי דומיינים עליונים, רשמים, פותרי DNS ורשויות אישור כ-mere conduit, ורשתות הפצת תוכן ופרוקסי הפוך כ-caching. שלושת הסוגים עשויים לקבל צו לפי סעיף 9 לפעול נגד תוכן בלתי חוקי, וצו לפי סעיף 10 למסור מידע. פטור מאחריות אינו פטור מצווים.
הדומיין: הרשם, והמרשם שמעליו
הרשם שלך הוא החנות. המרשם הוא הסיטונאי שמפעיל את הסיומת, וזו השכבה שכמעט אף אחד לא בודק לפני הקנייה.
מה מניע רשם לפעול
החל מ-5 באפריל 2024 חלה על רשמים מוסמכים חובה חוזית לפעול במה ש-ICANN מכנה DNS Abuse: כאשר בידיהם ראיות שניתן לפעול לפיהן, עליהם לנקוט ללא שיהוי אמצעי צמצום סבירים ונחוצים כדי לשבש את פעילות השם. המחצית השימושית של הכלל הזה היא ההגדרה שלו. DNS Abuse משמעה נוזקה, רשתות בוטים, פישינג, פארמינג וספאם — כאשר ספאם הוא ערוץ ההפצה של אחד מהאחרים. תוכן האתר אינו בגדר הדבר, וזכויות יוצרים אינן בגדר הדבר — במפורש.
כדאי לקרוא בכך סף ולא נחמה. הכלל אומר לך אילו מאפיינים על תלונה לשאת לפני שהרשם שלך מחויב לפעול; הוא גם אומר לך שכל דבר מחוץ לרשימה הזו חייב להגיע כצו מבית משפט או מרשות, איטי יותר, ניתן לבדיקה וניתן לערעור. שתי המחציות שוות ידיעה לפני שתטפל בתלונה שאתה עומד לקבל.
מה המרשם יכול לעשות, והיכן הוא נמצא
למרשם יש מנוף אחד ומוחלט: הוא יכול להציב על השם שלך סטטוס שמסיר אותו מהאזור. מאותו רגע השם אינו נפתר לאיש, בשום מקום, בלי קשר למה שהרשם שלך חושב ובלי קשר להיכן נמצא השרת שלך. שום דבר בשכבת האחסון אינו מקהה זאת, משום ששום דבר בשכבת האחסון אינו מעורב.
זה לא תיאורטי. ביוני 2026 הוציא בית משפט מחוזי בטקסס צו עיקול המורה ל-Verisign, המפעילה את .com, להעמיד את motherless.com על registry hold. המפעילה הייתה חברה לוקסמבורגית שהתעלמה מפסק דין טקסני לפי חוק אימות הגיל של המדינה; הצו קבע ערבות של 9.14 מיליון דולר כתנאי להחזרת השם. האתר לא אוחסן בטקסס והחברה לא הייתה בטקסס. השם היה תחת .com, ו-.com מופעלת בידי חברה אמריקאית תחת סמכות שיפוט אמריקאית. זה הספיק.
הלקח הכללי אינו נוגע לאותו מקרה עצמו. הוא נוגע לכך שהסיומת שאתה בוחר היא בחירת סמכות שיפוט, בדיוק כמו המדינה שבה יושב השרת שלך, ורוב האנשים בוחרים אותה מתוך הרגל. שאל מי מפעיל את הסיומת, תחת איזה דין, והאם למערכת המשפטית הזו יש נוהג להוציא צווים למרשמים. ואז החלט אם אתה רוצה שהשם היחיד שלך יישב שם.
פרטיות על השם היא עניין של פרסום, לא של ידיעה
הסתרת WHOIS ו-RDAP עוצרת את הגירוד ההמוני ואת החיפוש המזדמן. היא אינה הופכת את הרשם שלך לבור: ההסמכה מחייבת אותו להחזיק נתוני רישום, והוא מוסר אותם לפי הליך משפטי כמו כל אחד אחר. שירות פרטיות שמונח מול הרשומה הוא הגדרת פרסום, לא מגן — ורשם שמעולם לא ביקש ממך דבר אינו יכול למסור מה שאין לו, וזו תכונה שונה לגמרי, והיחידה ששווה לשלם עבורה.
הדומיין הוא החלק היחיד במערך שצו אחד יכול לכבות בכל מקום בבת אחת. שרתים מוחלפים, כתובות מתחלפות, פרוקסי מוחלף תוך אחר הצהריים. שם שמוחזק ברמת המרשם פשוט מפסיק להיפתר, וכל קישור שמישהו אי פעם פרסם אליך נשבר באותה שנייה.
הפרוקסי בחזית: מה הוא מסיר, מה הוא מעביר
CDN הוא מתווך caching. הוא אינו שומר את האתר שלך באופן קבוע, כך ש"הורדת הקובץ" היא בדרך כלל לא דבר שהוא יכול לעשות. מה שהוא כן יכול לעשות הוא להפסיק לתווך אותך — וזה, עבור אתר שתלוי בפרוקסי כדי להישאר נגיש ולשמור על שקט לגבי כתובת המקור שלו, הוא הסרה וחשיפה בתנועה אחת.
ההתנהגות המעניינת יותר היא זו היומיומית, והספק הגדול ביותר מפרסם אותה בגלוי. עם קבלת דיווח על ניצול לרעה לגבי אתר שהוא רק מתווך עבורו, הוא מעביר את התלונה שלך למפעיל האתר ולספק האחסון, והוא מוסר לספק האחסון את כתובת ה-IP של מקור התוכן נושא הדיווח. שני אלה מצוטטים ישירות ממדיניות ניצול לרעה משלו, והם ההפך הגמור ממה שקונים מניחים שהם משלמים עבורו.
כך שהפרוקסי אינו חוצץ בינך לבין מוקד הדיווחים של המארח שלך. הוא שליח. הוא נושא את התלונה למארח שלך, והוא אומר למארח שלך בדיוק על איזו מכונה להסתכל. אם בחרת את המארח שלך בגלל האופן שבו הוא מטפל בתלונות, זה בסדר — התלונה מגיעה בדיוק לאן שרצית שתגיע. אם בחרת פרוקסי בתקווה שהתלונה תיעצר שם, היא לא נעצרת.
התיעוד של אותו ספק עצמו מטיל גם עליך חובה: להחזיק כתובת יצירת קשר לדיווחי ניצול לרעה שמנוהלת ומנוטרת באופן פעיל, ולהגיב לכל הודעת דיווח כזו בתוך עשרים וארבע שעות. אי-מענה בזמן עלול לגרום להסרה או לחסימה של התוכן המדווח, ולהשעיה או לביטול החשבון. המתווך שאינו יכול להסיר את התוכן שלך כתב לעצמו, בכל זאת, סעיף הסרה — ושעון.
יש חריג אחד שחשוב לדעת. במקומות שבהם אותה חברה גם מארחת — שירות אחסון האובייקטים שלה, פלטפורמת ה-serverless שלה, מוצרי המדיה והדפים שלה — היא ספקית אחסון לגבי אותו תוכן, היא אומרת זאת בעצמה, והיא מסירה תוכן לפי הליך notice-and-takedown עם אפשרות התנגדות, בצורה שהדין האמריקאי מורה. שני מוצרים של אותו ספק, שתי תשובות שונות לחלוטין. כדאי לדעת באיזה מהם אתה משתמש בפועל.
פרוקסי בחזית מארח offshore אינו הופך את הסידור ליותר offshore. הוא מוסיף חברה במדינה אחרת, הכפופה למערכת משפטית אחרת, המחויבת חוזית להעביר למארח שלך את מה שהיא מקבלת — בצירוף כתובת המקור שלך.
מה CDN לא מסתיר, ואיך מוצאים כתובות מקור
הרבה אנשים מציבים פרוקסי בחזית שרת מסיבה אחת: כדי לשמור על כתובת המקור מחוץ לאינטרנט הציבורי. כדאי לדעת עד כמה זה עובד בפועל, והתשובה הכנה היא שזה עובד עד שאחת מחמש טעויות שגרתיות מבטלת את זה. אף אחת מהן אינה אקזוטית; ספקי הפרוקסי עצמם מתעדים אותן.
הרשומות שפרסמת לפני שעברת. DNS הוא ציבורי והוא נשמר בארכיון. כמעט כל אתר שעבר מאחורי פרוקסי משאיר את הכתובת שמלפני המעבר יושבת, לצמיתות, במאגר היסטורי של מישהו. ההנחיה של הספק עצמו היא לסובב את כתובת המקור אחרי ההצטרפות — אם לא עשית זאת, המעבר היה קוסמטי בלבד.
הרשומות שהשארת בלי פרוקסי. תת-דומיין אחד שמצביע ישירות על המכונה מספיק: mail, ftp, cpanel, dev, staging, vpn, מארח הניטור שהקמת פעם אחת. בדוק כל רשומה באזור, לא רק את אלה שאתה זוכר שיצרת.
דואר שיוצא מהמכונה. אם המקור שולח דואר, הכתובת שלו נוסעת בכותרות. שלח הודעה לכתובת שלא קיימת, וההודעה החוזרת תגיע כשהכתובת בתוכה. מקומו של הדואר הוא על מכונה שונה מזו שאתה מנסה לשמור עליה בשקט.
שקיפות אישורים. כל אישור אמון ציבורי נרשם ביומן יחד עם השמות שהוא מכסה. היומנים אינם מוסרים כתובת, אבל הם מוסרים את הרשימה המלאה של תתי-הדומיינים שכדאי לנסות, כולל אלה שחשבת שהם פרטיים.
סריקה סיטונאית. כל מרחב הכתובות נסרק ברציפות ומאונדקס לפי מה שהוא עונה. דף מזוהה שמוגש מכתובת חשופה הוא חיפוש במסד נתונים, לא חקירה.
הפתרונות ידועים היטב, וכדאי ליישם אותם לפי סדר החוזק ולא לפי סדר הנוחות.
- מנהרה outbound-only. המקור פותח חיבור אל הקצה ואינו מאזין לדבר. אין פורט למצוא, כך שהכתובת מפסיקה להיות מעניינת גם אם היא דולפת. זו האפשרות היחידה ברשימה שאינה תלויה בכתיבה נכונה של כלל.
- mTLS מהקצה. המקור משרת רק לקוח שמציג את האישור של הפרוקסי. הכתובת עשויה לדלוף; היא לא תענה. פתרון חזק, ששורד גם אחרי שהכתובת נעשית פומבית.
- חומת אש לטווחים המפורסמים של הפרוקסי. עדיף מכלום וקל לפריסה, אבל הטווחים משתנים, וההשוואה של הספק עצמו מסמנת את הגישה הזו כפגיעה להתחזות. יש להתייחס אליה כרצפה, לא כפתרון.
- תחזוקת בית. סובב את כתובת המקור ברגע שאתה מאחורי הקצה, העבר את הדואר למכונה אחרת, ובדוק רשומות בלי פרוקסי אחרי כל שינוי. רוב החשיפות הן אחת משלוש אלה, לא מתקפה מתוחכמת.
פרוקסי מסתיר את המקור מזר עם דפדפן. הוא אינו מסתיר את המקור מהפרוקסי עצמו — שמכיר אותו מעצם הגדרתו, ושמחויב, עם קבלת תלונה, לספר לספק האחסון שלך מהי הכתובת.
מתחת למכונה: תעבורה, טווח כתובות, מתקן
מתחת לשרת שלך יש עוד קבוצת גורמים, וזו הקבוצה שמארח בדרך כלל הכי פחות מעוניין לדבר עליה.
ספקי תעבורה. המארח שלך קונה קישוריות ממישהו. לספקי התעבורה האלה יש מוקדי דיווח, חוזים ורמת סיכון משלהם, וספק תעבורה שמחליט שאתה בעיה יכול לקבל את ההחלטה במקום המארח שלך. שאל כמה ספקי תעבורה יש — אחד הוא גם נקודת מדיניות יחידה וגם נקודת כשל יחידה — ושאל את השאלה החדה יותר: האם המארח שלך מקבל, בשקט, רשימות חסימה בצד ספק התעבורה על התעבורה שלך?
טווח הכתובות שאתה חולק. מערכות מוניטין פועלות לפי טווחי כתובות, לא לפי לקוחות. אתה יורש את השכנים שלך, ואתה יורש אותם בלי שמישהו יגיד לך מי הם. זהו המחיר הממשי של ספק שמפרסם את עצמו כמקלט לכל דבר בלי יוצא מן הכלל: רשימות החסימה מגיעות אל הטווח, והדואר שלך וקריאות ה-API שלך נמצאים בתוכו.
המתקן והחומרה. ארונות שכורים משמעם בעל נכס עם מדיניות ניצול לרעה משלו, שיושב מעל המארח שלך באופן בלתי נראה, וכל שכבה מעל המארח שלך היא עוד גורם שיכול לסיים את השירות שלך מסיבות שלעולם לא תראה.
מכיוון שמטרת המדריך הזה היא לחייב כל שכבה בדין וחשבון, הנה השכבה הזו באותם מונחים. שני ספקי תעבורה, מאוזנים ב-BGP, עשרים ג'יגה-ביט מעורבים, אל קישינב. סינון בשכבה 3 ובשכבה 4 במעלה הזרם של כל פורט, לכולם, בלי שום דבר לקנות. רשימות חסימה בצד ספק התעבורה אינן מתקבלות על תעבורת לקוחות: אם משהו חייב להיחסם, בית משפט אומר זאת ואנחנו מודיעים לך. החומרה בבעלות ולא בשכירות, במדינה אחת, בידי החברה שממנה אתה קונה — הפרטים נמצאים בעמוד הרשת ובעמוד המתקן.
והפער, נאמר בפשטות: אנחנו לא מוכרים דומיינים, ואנחנו לא מפעילים את הפרוקסי שאתה מציב בחזית השרת שלך. שתי השכבות האלה הן שלך. כל מה שנאמר למעלה על מרשמים ועל תלונות מועברות חל עליך בדיוק כפי שנכתב, ואף סמכות שיפוט של אחסון — כולל שלנו — אינה משנה בו מילה.
להפקיד את שלוש השכבות בשלוש ידיים שונות
כל המדריך מצטמצם לכמה החלטות, ואף אחת מהן לא עולה כסף.
- שלוש שכבות, שלושה ספקים, שלוש משפחות משפטיות. שם, קצה ושרת בידי חברה אחת הם צו אחד מריק. בשלוש ידיים, צו נגד אחד מהם משאיר את השניים האחרים פועלים ומשאיר לך זמן.
- שאל כל שכבה את אותן שלוש שאלות. מה אפשר לאלץ אותך להעביר, מה אפשר לאלץ אותך להסיר, ומה אפשר לאלץ אותך למסור? הם נכשלים באופן בלתי תלוי זה בזה, וספק שעונה על שלושתן במשפט אחד לא הבין את השאלה.
- הגדר את המערכת כאילו הפרוקסי מעביר, כי הוא אכן מעביר. הנח שכל תלונה מגיעה למארח שלך בצירוף כתובת המקור שלך. אם התוצאה הזו בעייתית, הפתרון נמצא בשכבת האחסון או במה שאתה מפרסם — לא בהוספת מתווך נוסף.
- סגור את המקור כראוי. מנהרה outbound-only או mTLS; דואר על מכונה אחרת; סיבוב הכתובת אחרי ההצטרפות; בדיקת רשומות בלי פרוקסי. ארבעה סעיפים, כולם משעממים, והם מכסים כמעט כל חשיפה אמיתית.
- התייחס לשם כאל נקודת הכשל היחידה שלך, והיערך בהתאם. דע איזה מרשם מפעיל את הסיומת שלך ותחת איזה דין. החזק שם שני, בסיומת אחרת, אצל רשם אחר, ודע מראש איך תגיד לאנשים להשתמש בו.
שום דבר כאן אינו טוען נגד הצבת פרוקסי בחזית השרת שלך, ושום דבר כאן אינו טוען נגד אחסון offshore — היינו מקור מוזר לכל אחת מהטענות האלה. הטענה היא ששלוש השכבות הן שלוש רכישות נפרדות עם שלושה אופני כשל נפרדים, וזו שרוב האנשים בודקים הכי בקפדנות אינה זו שהכי סביר שתסיים אותם. אם אתה רוצה שהשכבה שאנחנו כן מפעילים תעמוד באותו סטנדרט, הנתונים הרבעוניים ועמוד אכיפת החוק הם המקום לבדוק בו.
נכתב על ידי המהנדסים שמפעילים את הפלטפורמה, ונקרא מחדש לאחרונה היום. אם משהו כאן שגוי או מיושן, ניתן לציין זאת דרך הפאנל — משם הגיע כמחצית מהתיקונים האלה.