הגדרת תת-דומיין

תת-דומיין הוא רק רשומת DNS. זהו.

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

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

יצירת תת-דומיין

יוצרים תת-דומיין על ידי הוספת רשומת DNS. שני סוגים חשובים:

רשומת A — מצביעה על תת-הדומיין ישירות לכתובת IP.

blog.example.com  →  A  →  192.0.2.45

השתמש ברשומות A כשאתה יודע את כתובת ה-IP של השרת שלך. תת-הדומיין נפתר ישירות לאותה כתובת, ללא מתווכים.

רשומת CNAME — מצביעה על תת-הדומיין לשם דומיין אחר.

blog.example.com  →  CNAME  →  example.hosting-provider.com

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

ההבדל המעשי: רשומות A ישירות אך שבירות (שינוי IP מחייב עדכוני DNS). רשומות CNAME עקיפות אך גמישות (היעד מטפל בפתרון ה-IP).

דפוסי תתי-דומיינים נפוצים

‎www.‎ — תת-הדומיין המקורי. עדיין בשימוש, אם כי אתרים רבים מפנים אותו לדומיין הבסיסי.

‎app.‎ — האפליקציה עצמה, נפרדת מדפי השיווק בדומיין הבסיסי.

‎api.‎ — גישה תכנותית. מפתחים יודעים בדיוק לאן לשלוח בקשות.

‎staging.‎ ו-‎dev.‎ — סביבות בדיקה שמשקפות את הייצור מבלי להשפיע על משתמשים אמיתיים.

‎blog.‎ — ניהול תוכן, לרוב עם תוכנה שונה מהאתר הראשי.

‎docs.‎ — תיעוד, המאוחסן לעיתים קרובות בפלטפורמות כמו ReadTheDocs או GitBook.

‎cdn.‎ — נכסים סטטיים המוגשים מרשת אספקת תוכן.

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

ניתוב מספר תתי-דומיינים לשרת אחד

אם כל תתי-הדומיינים שלך מצביעים על אותו שרת (דרך רשומות A לאותה IP), שרת האינטרנט שלך מחליט מה להציג בהתבסס על כותרת ה-‎Host‎ בכל בקשה.

כשדפדפן מבקש את blog.example.com, הוא שולח:

Host: blog.example.com

שרת האינטרנט שלך (Nginx, Apache, Caddy) קורא את הכותרת הזו ומנתב לאפליקציה המתאימה. שרת אחד, תתי-דומיינים רבים, כל אחד מגיש תוכן שונה. זה נקרא אירוח וירטואלי, וכך שרת שעולה 5 דולר לחודש יכול לטפל בעשרות תתי-דומיינים.

תתי-דומיינים עם תו כללי (Wildcard)

רשומת DNS עם תו כללי משתמשת בכוכבית כדי להתאים לכל תת-דומיין שאין לו רשומה מפורשת:

*.example.com  →  A  →  192.0.2.45

עכשיו anything.example.com נפתר לשרת שלך. ‎user123.example.com‎. ‎my-feature-branch.example.com‎. אפשרויות אינסופיות מרשומה אחת.

זה מאפשר דפוסים עוצמתיים:

• SaaS רב-דיירי: כל לקוח מקבל ‎customer-name.yourapp.com‎
• פרופילי משתמשים: ‎username.example.com‎ לדפים מותאמים אישית
• סביבות דינמיות: הפעלת ‎feature-xyz.example.com‎ לכל pull request

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

אישורי SSL לתתי-דומיינים

כל תת-דומיין זקוק ל-HTTPS. יש לך שלוש אפשרויות:

אישורים בודדים — אישור אחד לכל תת-דומיין. פשוט אך מייגע ככל שמוסיפים תתי-דומיינים.

אישורי Wildcard — אישור ל-‎*.example.com‎ מכסה את כל תתי-הדומיינים ברמה הראשונה: ‎blog.example.com‎, ‎api.example.com‎, כל דבר. הוא אינו מכסה את הדומיין הבסיסי (‎example.com‎) או תתי-דומיינים מקוננים (‎staging.api.example.com‎ — זה שתי רמות עמוק). רוב אישורי ה-Wildcard כוללים גם ‎*.example.com‎ וגם ‎example.com‎ כדי לפתור את פער הדומיין הבסיסי.

Let's Encrypt — אישורים חינמיים, כולל wildcards. פלטפורמות אחסון מודרניות מטפלות בזה אוטומטית. אם אתה מנהל שרת בעצמך, כלים כמו Certbot ישיגו ויחדשו עבורך אישורים.

הבחירה המעשית לרוב ההגדרות: Let's Encrypt עם חידוש אוטומטי. אלא אם יש לך דרישות ציות ספציפיות, אין סיבה לשלם עבור אישורים עוד.

אימות

לאחר יצירת רשומות DNS, בדוק שהן עובדות:

dig blog.example.com

או:

nslookup blog.example.com

שינויי DNS מתפשטים בדרך כלל תוך דקות. מספר "24-48 שעות" שלעיתים תראה הוא תרחיש גרוע ביותר מתקופה קודמת של תשתית DNS. אם הרשומה שלך לא נפתרת לאחר שעה, בדוק שוב את התצורה אצל ספק ה-DNS שלך — הבעיה כמעט בוודאות היא תצורה שגויה, לא עיכוב בהתפשטות.

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

מודל החשיבה

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

אתה מחזיק בדומיין. DNS מאפשר לך ליצור רשומות לכל שם תחת אותו דומיין. ‎blog.example.com‎ הוא שם. ‎api.example.com‎ הוא שם. ‎literally-anything.example.com‎ הוא שם. כל שם מצביע לשם מה.

זה תתי-דומיינים. השאר הוא רק להחליט לאן להצביע אותם.

שאלות נפוצות על תתי-דומיינים

האם אפשר ליצור תתי-דומיינים ללא הגבלה?

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

האם תתי-דומיינים משפיעים על SEO?

מנועי חיפוש מתייחסים לתתי-דומיינים כאתרים נפרדים מהדומיין הראשי שלך. תוכן ב-‎blog.example.com‎ לא ייהנה אוטומטית מהסמכות של ‎example.com‎. אם איחוד סמכות SEO חשוב לך, תת-ספרייה (‎example.com/blog‎) היא בדרך כלל הבחירה הטובה יותר.

כמה זמן לוקח לתת-דומיין חדש לעבוד?

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

האם אפשר להפנות תת-דומיין לספק אחסון אחר לחלוטין?

כן. האתר הראשי שלך יכול להיות על AWS, הבלוג שלך על WordPress.com, התיעוד שלך על GitBook, וה-API שלך על Heroku. כל תת-דומיין עצמאי — הצבע אותו לאן שצריך דרך רשומות A או CNAME.

מה ההבדל בין תת-דומיין לתת-ספרייה?

תת-דומיין (‎blog.example.com‎) הוא רשומת DNS נפרדת שיכולה להצביע לכל מקום. תת-ספרייה (‎example.com/blog‎) היא נתיב בשרת הקיים שלך. תתי-דומיינים מציעים גמישות ארכיטקטונית; תת-ספריות פשוטות יותר ומאחדות סמכות SEO.