רשומות DNS: איך מפנים דומיין לשרת או לאחסון

איך מגדירים רשומות DNS כדי שהדומיין יפנה לשרת או לאחסון החדש? משנים את רשומת A של הדומיין הראשי ואת הרשומה של www כך שיצביעו לכתובת ה-IP של השרת החדש, ולא נוגעים ברשומות הדואר (MX ו-TXT) אם הדואר נשאר במקומו. רשומות DNS הן ההוראות שאומרות לכל דפדפן ולכל שרת דואר לאן לפנות כשמישהו מקליד את הדומיין שלכם או שולח אליו מייל.

המדריך מסביר את סוגי הרשומות, איפה עורכים אותן, למה שינוי לוקח זמן ואיך עושים את ההפניה צעד אחר צעד בלי להפיל את הדואר. בכל שלב אפשר לראות מה מוגדר בפועל בכלי בדיקת רשומות DNS שלנו או בפקודות dig ו-nslookup שמופיעות בהמשך. בדוגמאות נשתמש בדומיין example.com ובכתובות ששמורות לתיעוד (203.0.113.10 ו-2001:db8::10). אצלכם מחליפים אותן בדומיין ובכתובת של השרת.

רשם, שרתי שמות ורשומות: מי מחזיק מה

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

הרשם (Registrar) הוא החברה שדרכה קניתם את הדומיין ושאליה משלמים על החידוש. רישום דומיינים בסיומת il נעשה דרך רשמים שהוסמכו על ידי איגוד האינטרנט הישראלי. אצל הרשם מגדירים פרט אחד שקובע הכול: אילו שרתי שמות (Nameservers, רשומות NS) אחראים על הדומיין.

ספק ה-DNS הוא מי שמפעיל את שרתי השמות האלה, ורק אצלו נמצא אזור ה-DNS (Zone) עם רשומות A, MX, TXT ושאר הרשומות. לפעמים זה הרשם עצמו, לפעמים חברת האחסון ולפעמים שירות DNS נפרד.

המשמעות המעשית: אם שרתי השמות מצביעים לספק האחסון הקודם, שינוי רשומת A בממשק של הרשם לא ישפיע על דבר. כל העולם קורא את הרשומות משרתי השמות שמוגדרים אצל הרשם, ומשם בלבד. לפני שמשנים משהו, בדקו בבדיקת WHOIS לדומיין מי הרשם ואילו שרתי שמות רשומים. הכלי שולף את נתוני הרישום בתקן RDAP. לסיומת il, שאינה זמינה ב-RDAP, הוא מציג קישור לחיפוש ה-WHOIS של איגוד האינטרנט.

יש שתי דרכים להפנות דומיין לשרת חדש, וההבדל ביניהן גדול:

	שינוי רשומות אצל ספק ה-DNS הקיים	החלפת שרתי השמות לספק חדש
מה משתנה	רק הרשומות שעורכים, בדרך כלל A ו-www	כל אזור ה-DNS עובר לספק החדש
הדואר	ממשיך לעבוד אם לא נוגעים ב-MX ו-TXT	צריך להעתיק MX, SPF, DKIM ו-DMARC לפני ההחלפה
זמן עדכון	לפי ה-TTL של הרשומה שהשתנתה	לפי ה-TTL של רשומות ה-NS, שחלקו נקבע במאגר הסיומת ולא אצלכם
מתי מתאים	מעבר אתר בלבד	כשרוצים לנהל את כל ה-DNS במקום אחד חדש

סוגי רשומות DNS ומה כל אחת עושה

אלה הרשומות שתפגשו כמעט בכל הפניית דומיין:

רשומה	מה היא עושה	ערך לדוגמה
A	מפנה שם לכתובת IPv4	203.0.113.10
AAAA	מפנה שם לכתובת IPv6	2001:db8::10
CNAME	הופכת שם לכינוי של שם אחר, והחיפוש ממשיך לשם היעד	www אל example.com
MX	שרת הדואר שמקבל מייל לדומיין, עם מספר עדיפות (נמוך קודם)	10 mail.example.com
TXT	טקסט חופשי: SPF, DKIM, DMARC ואימות בעלות לשירותים חיצוניים	v=spf1 ip4:203.0.113.10 -all
NS	שרתי השמות שאחראים על הדומיין	ns1.example.net
CAA	אילו רשויות אישורים רשאיות להנפיק תעודת SSL לדומיין	0 issue "ca1.example.net"
PTR	DNS הפוך: מכתובת IP לשם	mail.example.com

כמה כללים מהתקנים שחוסכים תקלות:

• רשומת MX מצביעה לשם של שרת, לא לכתובת IP. השם הזה צריך להיות רשומת A או AAAA, לא CNAME (‏RFC 2181, סעיף 10.3).
• שם שיש לו CNAME לא יכול להחזיק רשומות אחרות (‏RFC 1034 ו-RFC 2181). לכן CNAME מתאים לתת-דומיין כמו www, ולא לדומיין הראשי.
• SPF נכתב כרשומת TXT שמתחילה ב-v=spf1 (‏RFC 7208). אין יותר סוג רשומה נפרד בשם SPF.
• רשומת PTR לכתובת IPv4 יושבת באזור in-addr.arpa, ולכתובת IPv6 באזור ip6.arpa. היא מוגדרת אצל מי שמחזיק את כתובת ה-IP, כלומר ספק השרת, ולא באזור ה-DNS של הדומיין שלכם. היא רלוונטית בעיקר כשהשרת שולח דואר בעצמו.
• רשומת CAA לא חובה. אם קיימת אחת, רשות אישורים שלא מופיעה בה לא תנפיק תעודה לדומיין (‏RFC 8659). אחרי מעבר לאחסון שמנפיק תעודות מרשות אחרת, בדקו שהיא מופיעה ברשומה.

TTL: למה שינוי ב-DNS לא מתעדכן מיד

לכל רשומה יש TTL (Time To Live), מספר שניות שבמהלכן שרת DNS שקיבל את התשובה רשאי לשמור אותה במטמון. ספק האינטרנט של הגולש שואל פעם אחת, שומר את התשובה ומחזיר אותה לכל מי ששואל עד שה-TTL נגמר.

לכן "התפשטות DNS" היא בעצם המתנה לפקיעת מטמונים. אם ל-A הישנה היה TTL של 86400 שניות (24 שעות), חלק מהגולשים עלולים להגיע לשרת הישן עד יממה אחרי השינוי. אם ה-TTL היה 300 שניות, רובם יעברו תוך דקות.

מכאן הכלל לפני כל מעבר: מורידים את ה-TTL מראש. יום או יומיים לפני המעבר משנים את ה-TTL של רשומות A, AAAA ו-www ל-300, ומחכים לפחות את משך ה-TTL הישן כדי שכל המטמונים ייקחו את הערך החדש. אחרי שהמעבר הצליח והכול יציב, מחזירים את ה-TTL לערך גבוה יותר.

הפניית דומיין לשרת חדש, צעד אחר צעד

1. מתעדים את המצב הקיים. בודקים בכלי ה-DNS כל סוג רשומה (A, AAAA, CNAME ל-www, MX, TXT, NS) ושומרים את התוצאות. אם ממשק ספק ה-DNS מאפשר ייצוא של קובץ האזור, מורידים עותק.
2. מורידים TTL ל-300 ומחכים כמו שהוסבר למעלה.
3. מכינים את האתר בשרת החדש ובודקים אותו לפני שינוי ה-DNS. הדרך הפשוטה היא קובץ hosts במחשב שלכם, שגובר על ה-DNS רק אצלכם. ב-Windows הקובץ נמצא ב-C:\Windows\System32\drivers\etc\hosts, ובלינוקס וב-macOS ב-/etc/hosts. מוסיפים שורה כזו ומוחקים אותה אחרי הבדיקה:

203.0.113.10 example.com www.example.com

4. משנים את רשומת A של הדומיין הראשי (מופיעה בממשקים רבים כ-@) לכתובת ה-IP של השרת החדש.
5. מטפלים ב-www. אפשר להגדיר לו רשומת A לאותה כתובת, או CNAME שמצביע לדומיין הראשי. בשני המקרים www צריך להגיע לאותו שרת.
6. מטפלים ב-AAAA. אם לשרת החדש יש כתובת IPv6, מעדכנים אותה. אם אין, מוחקים את רשומת ה-AAAA הישנה.
7. מוודאים תעודת SSL. תעודה שמונפקת אוטומטית באימות HTTP דורשת שהדומיין כבר יצביע לשרת החדש, ולכן מנפיקים אותה אחרי שינוי ה-A.
8. בודקים, ומשאירים את השרת הישן פעיל עד שעבר לפחות ה-TTL הישן, עם מרווח ביטחון. בזמן הזה עדיין יגיעו אליו גולשים, ובחנות או בטופס צור קשר זה אומר הזמנות ופניות שנשמרות בשרת הישן.

מעבירים רק את האתר? כך הדואר ממשיך לעבוד

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

הראשון: רשומת MX שמצביעה לדומיין הראשי עצמו, או ל-mail.example.com שמוגדר כ-CNAME לדומיין הראשי. במצב כזה שינוי ה-A של הדומיין מעביר גם את הדואר לשרת החדש, בלי שהתכוונתם. לפני השינוי יוצרים ל-mail.example.com רשומת A נפרדת עם כתובת שרת הדואר הנוכחי, ומפנים אליה את ה-MX.

השני: החלפת שרתי שמות. כאן כל הרשומות מתחילות מאפס אצל הספק החדש, ולכן מעתיקים אליו מראש את ה-MX, את רשומת ה-SPF, את רשומות ה-DKIM (בשמות כמו selector._domainkey) ואת רשומת ה-DMARC (בשם _dmarc). אם ה-MX חסר, דואר נכנס לא יגיע. אם SPF, DKIM או DMARC חסרות, מיילים יוצאים עלולים להידחות או להגיע לתיקיית הספאם. הסבר מלא על שלוש הרשומות נמצא במדריך הגדרת SPF, DKIM ו-DMARC.

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

טעויות נפוצות ברשומות DNS

CNAME על הדומיין הראשי. בדומיין הראשי חייבות להיות רשומות SOA ו-NS, ו-CNAME לא יכול לשבת לצד רשומות אחרות. CNAME כזה סותר את התקן ועלול לשבור את הדואר ואת רשומות האימות שיושבות על הדומיין הראשי. בדומיין הראשי משתמשים ב-A וב-AAAA. חלק מספקי ה-DNS מציעים לזה פתרון משלהם, שאינו חלק מהתקן.

שתי רשומות SPF. מוסיפים ספק דיוור חדש ויוצרים לו רשומת v=spf1 נוספת במקום לעדכן את הקיימת. לפי RFC 7208, כשיש יותר מרשומת SPF אחת התוצאה היא שגיאה קבועה (permerror) במקום תוצאה תקינה, והשרת המקבל לא יכול לאמת לפיה את השולח. מאחדים הכול לרשומה אחת, ושמים לב למגבלה של 10 מנגנונים שדורשים שאילתת DNS (כמו include).

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

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

AAAA שמצביע לשרת הישן. מעדכנים את רשומת A ושוכחים את ה-AAAA. לפי RFC 8305, לקוחות שיש להם חיבור IPv6 שולחים קודם שאילתת AAAA ומעדיפים IPv6, ולכן חלק מהגולשים ימשיכו להגיע לשרת הישן ואחרים לחדש. מהמחשב שלכם התקלה עלולה לא להופיע בכלל. דף מה כתובת ה-IP שלי מציג את הכתובת הציבורית שממנה אתם גולשים; אם היא בפורמט IPv6, החיבור שלכם עובר ב-IPv6 ורשומת ה-AAAA משפיעה גם עליכם.

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

איך בודקים רשומות DNS: dig, nslookup והכלי שלנו

בכלי בדיקת ה-DNS באתר מזינים דומיין, בוחרים סוג רשומה (A, AAAA, MX, TXT, NS או CNAME) ומקבלים את הערכים כפי ששרת ה-DNS הציבורי של Cloudflare רואה אותם, עם ה-TTL של כל רשומה. זה מספיק כדי לוודא אחרי שינוי שהעולם החיצוני רואה את הכתובת החדשה.

בלינוקס וב-macOS משתמשים ב-dig. הדגל +short מציג רק את הערך:

dig example.com A +short
dig www.example.com +short
dig example.com AAAA +short
dig example.com MX +short
dig example.com TXT +short
dig example.com NS +short

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

dig @ns1.example.net example.com A

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

ב-Windows משתמשים ב-nslookup. אפשר לציין שרת DNS בסוף הפקודה, למשל 1.1.1.1 של Cloudflare:

nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 1.1.1.1

שאלות נפוצות

כמה זמן לוקח לשינוי DNS להתעדכן?

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

אפשר להפנות דומיין לשרת חדש בלי להעביר אותו לרשם אחר?

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

לבחור A או CNAME עבור www?

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

צריך רשומת AAAA אם לשרת החדש אין IPv6?

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

למה האתר החדש מופיע אצלי אבל לקוח עדיין רואה את הישן?

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

מעבר לאחסון אתרים באמפייר אייאל

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

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