מה זה DNS ואיך מחברים דומיין לשרת VPS?

מהו DNS, ומדוע הדומיין שלכם עדיין לא מגיע ל-VPS שלכם

DNS (מערכת שמות מתחם) מתרגמת שם כמו example.com לכתובת IP (פרוטוקול אינטרנט) כמו 203.0.113.10. דפדפן אינו יכול להתחבר לשם; הוא מתחבר לכתובת, ולכן כל טעינת דף מתחילה בשאילתת DNS ובתשובה. אם זה עתה רכשתם דומיין ו-VPS משלכם, ושום דבר לא נטען, אחת משתי אפשרויות נכונה: אין עדיין רשומה שמקשרת את השם לכתובת השרת שלכם, או שקיימת רשומה אך גורם כלשהו בדרך עדיין מספק תשובה ישנה.

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

כל בדיקה כאן משתמשת ב-dig, שאינו מותקן כברירת מחדל במכונת Ubuntu או Debian חדשה.

sudo apt update && sudo apt install -y bind9-dnsutils

רשם (Registrar), שרתי שמות (nameservers) ומארח DNS: מה עליך לערוך

שלושת המושגים הללו מתארים תפקידים שונים. בלבול ביניהם הוא הסיבה הנפוצה ביותר לכך ששינויים אינם משפיעים על המציאות.

• הרשם (registrar) הוא החברה שממנה רכשת את הדומיין. תפקידו הקריטי הוא האצלת סמכויות (delegation): הוא מודיע לרישום (registry) שמנהל את ה-TLD שלך (סיומת הדומיין, החלק של ה-.com) אילו שרתי שמות הם הסמכותיים עבור הדומיין שלך.
• שרתי השמות הסמכותיים (authoritative nameservers) מחזיקים את הרשומות האמיתיות עבור ה-zone שלך. zone הוא הדומיין שלך והשמות שתחתיו.
• מארח ה-DNS (DNS host) הוא הגוף שמפעיל את שרתי השמות הללו. זה יכול להיות הרשם, ספק נפרד, או bind9 שרץ על שרת שבבעלותך.

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

גלה היכן העולם מבצע את השאילתות:

dig example.com NS +short
dig +trace example.com

הפקודה הראשונה מדפיסה את שרתי השמות שעונים עבור הדומיין כיום. השנייה עוקבת אחר השרשרת החל משרתי השורש (root servers) ומדפיסה את ההפניה ששרתי ה-TLD מספקים, שהיא האצלת הסמכויות שהרשם שלך שולט בה. אם שמות אלו שייכים לספק שאינך מזהה, אותו ספק הוא בעל לוח הבקרה שאתה צריך.

כיצד מתבצע חיפוש בודד

בתהליך מעורבים ארבעה גורמים, וכל אחד מהם שומר עותק של המידע שהוא לומד.

1. ה-stub resolver במחשב שלך. הוא אינו מבצע חיפוש בעצמו. הוא פונה לשרת אחד שהוגדר לו ומקבל את תשובתו כעובדה. ב-Ubuntu, הקובץ /etc/resolv.conf הוא בדרך כלל קישור סימבולי ל-/run/systemd/resolve/stub-resolv.conf ומצביע על 127.0.0.53, שהוא systemd-resolved הרץ באופן מקומי עם מטמון (cache) משלו.
2. ה-recursive resolver. זהו ה-resolver המופעל על ידי ספקית האינטרנט (ISP) שלך, או שירות ציבורי כגון 1.1.1.1, או שרת שאתה מפעיל בעצמך. הוא מבצע את העבודה בפועל של מציאת התשובה.
3. ה-root and TLD servers. ה-recursive resolver פונה לשרת שורש (root server), שאינו מכיר את הכתובת שלך אך משיב בהפניה לשרתי ה-.com. אלו משיבים בהפניה לשרתי השמות (nameservers) שלך.
4. ה-authoritative nameserver. הוא אינו שואל איש. הוא משיב מתוך ה-zone שלך ומסמן את התשובה כ-authoritative.

הפקודה dig +trace example.com מציגה לך את התהליך הזה, כיוון שהיא מתחילה בשורש עצמו ומדפיסה כל הפניה במקום לשאול מטמון. זו הדרך המהירה ביותר לוודא שה-delegation וה-zone תואמים זה לזה.

רשומות DNS שחשוב להכיר בעת הפעלת שרת

• A: מיפוי שם לכתובת IPv4. example.com. A 203.0.113.10. זו הרשומה שמפנה את שם המתחם שלכם אל ה-VPS.
• AAAA: מיפוי שם לכתובת IPv6, כגון 2001:db8::10. פרסמו אותה רק כאשר השירות שלכם אכן מאזין בכתובת זו. לקוחות ברשתות IPv6 ינסו קודם את התשובה של AAAA, לכן כתובת שאין לה מענה תגרום לעיכוב בכל כניסה.
• CNAME: כינוי (alias) משם אחד לשם אחר. www.example.com. CNAME example.com. מפנה מבקרים מ-www לכל כתובת שאליה מתרגם שם המתחם הראשי. רשומת CNAME לא יכולה להתקיים ב-apex (המתחם הראשי ללא תת-דומיין, example.com), כיוון שה-apex חייב להכיל רשומות SOA (start of authority) ו-NS משלו, ורשומת CNAME אינה מורשית לחלוק שם עם אף רשומה אחרת. ספקי שירות מציעים פתרונות עוקפים תחת שמות כמו ALIAS, ANAME או CNAME flattening.
• MX: מציינת לאן יישלח דואר אלקטרוני עבור המתחם. היא כוללת שם מארח ומספר עדיפות, כאשר המספר הנמוך ביותר מקבל עדיפות ראשונה. רשומת MX חייבת להצביע על שם בעל רשומת כתובת (A או AAAA). הפניה של MX ל-CNAME אינה תקינה, ושרתים שולחים מסוימים יפסלו אותה.
• TXT: טקסט חופשי, המשמש לאימות ומדיניות. רשומות אימות דואר (SPF, DKIM, DMARC) נמצאות כאן, וכך גם אסימון ה-ACME (automatic certificate management environment) המשמש להנפקת תעודת wildcard.
• NS: מציינת אילו שרתי שמות מנהלים את ה-zone. העותק שקובע לאן העולם פונה נמצא ב-parent zone ומגיע מההאצלה (delegation) של ה-registrar שלכם, ולא מהעותק שנמצא בתוך ה-zone שלכם.

שני פרטים גורמים לבלבול רב יותר מסוגי הרשומות עצמם. שם שמסתיים בנקודה הוא מוחלט (absolute), לכן www.example.com. מציין בדיוק את השם הזה ולא מעבר לכך. רוב ממשקי הניהול מצפים לשם יחסי ומוסיפים את שם המתחם עבורכם, לכן הקלדת www.example.com בתיבת השם תיתן לכם את www.example.com.example.com, שאינו מתרגם לכתובת עבור אף אחד. הפרט השני הוא @, שבכמעט כל ממשק ניהול משמעותו ה-apex: שם המתחם כשלעצמו, ללא תת-דומיין.

הפניית רשומת A אל ה-VPS שלכם

תחילה, השיגו את הכתובת שדרכה האינטרנט מזהה את השרת שלכם:

curl -4 https://ifconfig.me
ip -brief -4 address show

לאחר מכן, צרו רשומה אחת אצל ספק ה-DNS שלכם: סוג A, שם @, ערך הכתובת שהשגתם, ו-TTL (זמן חיים) של 300. הוסיפו רשומה שנייה עבור www, או באמצעות A נוסף עם אותה כתובת, או באמצעות CNAME המצביע אל ה-apex.

כעת, ודאו שהרשומה מתרגמת כראוי, רצוי מהמחשב האישי שלכם ולא מהשרת עצמו:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

הפקודה הראשונה משתמשת בנתיב הרגיל של המחשב שלכם, כולל ה-cache. השנייה מדלגת על ה-cache המקומי ופונה ל-recursive resolver ציבורי. השלישית פונה ישירות ל-authoritative nameserver שלכם, כך שהתשובה היא האמת העדכנית ללא כל cache בדרך. כאשר הפקודה השלישית מחזירה את הכתובת שלכם והראשונה לא, ה-DNS שלכם מוגדר כראוי ואתם ממתינים לרענון של עותק ישן השמור ב-cache.

פתרון בעיות טעינה

פתרון שמות (name resolving) מוכיח ש־DNS עובד. הוא אינו מוכיח דבר לגבי שרת ה־web שלכם. ברגע ש־dig מחזיר את הכתובת הנכונה, בדקו את החיבור:

curl -I http://example.com

curl: (6) Could not resolve host: example.com מעיד על בעיית DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused אינו בעיית DNS: השם פוענח והחבילה הגיעה ליעדה, לכן הבעיה היא ששום תהליך לא האזין בפורט זה. בקשה שנתקעת ולאחר מכן מסתיימת ב־timeout מעידה בדרך כלל על כך שחומת האש השליכה את החבילה בשקט במקום לסרב לה. כאן מסתיים תפקידו של ה־DNS, והנושא עובר לטיפול ב־פורטים ו־sockets מאזינים וב־חוקי ה־ufw firewall בשרת ה־VPS שלכם. לאחר השלמת החיבור, המשך טעינת הדף הוא עבודתו של פרוטוקול HTTP.

מדוע הדפדפן עדיין מציג את המארח הישן

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

עותקים קיימים ביותר מקומות ממה שאנשים מצפים: המטמון הקצר של הדפדפן עצמו, ה-stub resolver במחשב, ה-recursive resolver שבו משתמשת הרשת, וכל resolver שמותקן על ידי VPN בלקוח. כל אחד מהם שומר את העותק שלו עד לזמן ה-TTL שקיבל. שני אנשים בשתי רשתות שונות יכולים לראות שתי תשובות שונות במשך שעות, ושני המחשבים מתנהגים בצורה תקינה.

עקבו אחר הספירה לאחור מול resolver שמבצע שמירה במטמון:

dig @1.1.1.1 example.com +noall +answer

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

קיים מטמון שני שכמעט איש אינו לוקח בחשבון: תשובות שליליות. כאשר נאמר ל-resolver ששם מסוים אינו קיים, הוא שומר גם את ה-NXDOMAIN הזה, למשך הזמן שנקבע בשדה האחרון של רשומת ה-SOA באזור (zone) שלך.

dig example.com SOA +short

המספר האחרון בשורה זו הוא ה-TTL השלילי, לרוב 3600. לכן, חיפוש של staging.example.com לפני יצירתו עלול להסתיר ממך את הרשומה למשך שעה שלמה לאחר שתצור אותה. צור את הרשומה תחילה, ורק אז בצע שאילתה.

שינוי שרתי DNS איטי יותר משינוי רשומה, והסיבה לכך מכנית. רשומות ההאצלה (delegation) באזור .com מוגשות עם TTL של 172800 שניות, שהן יומיים, ולכן resolver ששמר במטמון את שרתי ה-DNS הישנים שלך יכול להמשיך לפנות אליהם למשך זמן זה. מכאן מגיעה העצה "להמתין עד 48 שעות". היא תקפה לשינויי שרתי DNS, לא לעריכת רשומות רגילה.

תכננו הגירה סביב ה-TTL במקום להילחם בו:

1. הנמיכו את ה-TTL של הרשומה ל-300 ושמרו.
2. המתינו זמן ארוך יותר מה-TTL הישן, כדי שכל עותק שמור הנושא את הערך הישן יפוג.
3. שנו את הכתובת.
4. לאחר שהתעבורה עברה, העלו את ה-TTL בחזרה ל-3600 או יותר, שכן TTL נמוך גורם לכל resolver לפנות לשרתי ה-DNS שלך בתדירות גבוהה בהרבה.

כדי לנקות את מה שהמחשב שלך מחזיק:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics מדפיס מקטע מטמון עם מונים של הצלחות (hits) וכישלונות (misses), כך שמיד לאחר ניקוי המטמון, החיפוש הבא יופיע כ-miss. דפדפנים מחזיקים מטמון נפרד, מה שאומר ש-Chrome עדיין יכול להשתמש בתשובה ישנה גם לאחר שהמטמון של המערכת ריק. נקו אותו ב-chrome://net-internals/#dns. בדקו גם את /etc/hosts, מכיוון ששורה שנותרה שם גוברת על ה-DNS באותו מחשב בלבד. getent hosts example.com מציג את התשובה שהמערכת באמת תשתמש בה, כולל /etc/hosts.

תעודות Wildcard מאומתות באמצעות רשומת TXT

רשות אישורים (CA) בודקת שליטה על שם מתחם לפני הנפקת תעודה. אתגר ה-HTTP-01 מגיש קובץ דרך פורט 80 בכתובת המדויקת, פתרון שעובד היטב עבור שם בודד. תעודת wildcard מכסה את *.example.com, קבוצה פתוחה של שמות מתחם שה-CA אינה יכולה למשוך מהם קובץ, ולכן Let's Encrypt מנפיקה תעודות wildcard רק באמצעות אתגר ה-DNS-01. עליכם לפרסם רשומת TXT ב-_acme-challenge.example.com המכילה אסימון (token) שניתן לכם מה-CA, והשליטה באזור ה-DNS מהווה את ההוכחה.

תהליך זה הופך את ספק ה-DNS שלכם לחלק מחידוש התעודה. Certbot חייב ליצור ולמחוק את רשומת ה-TXT בכל חידוש ללא התערבותכם, ולכן הוא זקוק ל-API ולתוסף תואם עבור הספק שלכם. כאשר האימות נכשל, ההודעה הנפוצה היא DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com, שמשמעותה שה-CA פנתה לפני שהרשומה הייתה גלויה: או שהיא מעולם לא נשמרה, או שתשובה שלילית עדיין הייתה שמורה ב-cache. ההליך המלא מופיע ב-מדריך לתעודות wildcard עם אתגר ה-DNS-01.

כאשר VPN משתלט על ה-resolver שלכם

לקוח VPN (רשת פרטית וירטואלית) מחליף בדרך כלל את ה-resolver של המערכת בזמן שהוא מחובר, כיוון ששליחת שאילתות לרשת המקומית תחשוף בפני אותה רשת את שמות כל האתרים שבהם אתם מבקרים. זו התנהגות תקינה, אך היא עלולה להיכשל בשני כיוונים.

אם המנהרה (tunnel) עולה ושמות מפסיקים להיפתר (resolve) בעוד שכתובות IP עדיין עובדות, ה-resolver שהלקוח התקין אינו נגיש מתוך המנהרה. ping 1.1.1.1 מצליח ו-curl https://example.com מחזיר curl: (6) Could not resolve host: example.com. אם לעומת זאת המנהרה עולה והשאילתות עדיין מופנות לרשת שבה אתם נמצאים, התעבורה שלכם עוברת במנהרה בעוד ה-resolver המקומי ממשיך לראות כל שם שאתם מחפשים.

resolvectl status

פקודה זו מדפיסה את ה-resolver שנמצא בשימוש עבור כל ממשק, כך שתוכלו לראות איזה מהם הותקן על ידי המנהרה והאם הוא אכן זה שהתכוונתם להשתמש בו. מנהרת WireGuard מגדירה זאת באמצעות השורה DNS = בקובץ התצורה של הלקוח, והמדריך תיקון DNS כאשר WireGuard משתלט על ה-resolver מכסה בפירוט את המקרים של systemd-resolved ו-resolvconf.

קודי התגובה והמשמעות של כל אחד מהם

• NXDOMAIN: שרת מוסמך מצהיר כי השם אינו קיים. בדקו את האיות, בדקו אם יש כפל בסיומת המתחם, וודאו שערכתם את ה-zone שאליו מצביעה ההאצלה (delegation) שלכם.
• NOERROR עם ANSWER SECTION ריק: השם קיים, אך אין לו רשומה מהסוג שביקשתם. בקשה עבור AAAA כאשר קיימת רק רשומת A תניב תוצאה זו בדיוק.
• SERVFAIL: ה-resolver ניסה ולא הצליח להפיק תשובה. שתי הסיבות הנפוצות הן שרתי סמכות שאינם משיבים, וכשל באימות DNSSEC (הרחבות אבטחה למערכת שמות המתחם). בצעו בדיקה עם dig @1.1.1.1 example.com A +cd, אשר מבטל את האימות. קבלת תשובה עם +cd ו-SERVFAIL ללא שימוש בדגל זה מעידה על כך שהחתימות הן הבעיה; מצב זה קורה לאחר העברת שרת שמות כאשר ה-parent עדיין מפרסם רשומת DS (delegation signer) ישנה.
• REFUSED: השרת שאליו פניתם לא יענה על השאלה, בדרך כלל משום שהפניתם את dig לשרת מוסמך עבור מתחם שהוא אינו משרת.
• ;; connection timed out; no servers could be reached: הפקודה dig לא הגיעה ל-resolver. זוהי בעיית רשת או בעיית resolver בצד שלכם, לכן המתחם אינו הגורם לבעיה.

ping: example.com: Temporary failure in name resolution מייצג את אותה מחלקת כשל המדווחת על ידי glibc במקום על ידי dig.

האם כדאי להריץ שרתי שמות (nameservers) על ה-VPS שלכם?

אפשר לעשות זאת. bind9, knot או nsd יגישו את ה-zone שלכם מהשרת, וזה מלמד על DNS יותר מכל לוח בקרה. ההתנגדויות הן מעשיות. דומיין צריך לפחות שני שרתי שמות ברשתות נפרדות, כך ש-VPS בודד הופך לנקודת כשל אחת עבור כל שירות בדומיין, כולל דואר אלקטרוני. שרתי שמות שמוגדרים בתוך הדומיין שהם משרתים זקוקים ל-glue records אצל הרשם (registrar), שהם הכתובת של ns1.example.com המאוחסנת ב-zone של ה-parent, כיוון שאחרת ל-resolver אין דרך להתחיל את החיפוש. כאשר resolver לא מצליח להגיע לשרת השמות שלכם, הוא לא עובר לשרת האינטרנט שלכם: כל הדומיין נעלם עבור אותו משתמש. שירות DNS מאוחסן עם API הוא הבחירה בעלת הסיכון הנמוך יותר עבור רוב האנשים. הרצת caching resolver על ה-VPS עבור המכונות שלכם היא משימה שונה, ומחייבת הרבה פחות.

FAQ

מדוע שינוי ה-DNS שלי טרם התעדכן?

שום דבר לא "מתעדכן" (propagate). שרתי השמות הסמכותיים (authoritative nameservers) מחזיקים בערך החדש ברגע השמירה, וכל פותר (resolver) שכבר ביצע שאילתה שומר עותק במטמון עד לפקיעת ה-TTL שקיבל. בצעו שאילתה ישירה מול השרת הסמכותי באמצעות dig @ns1.your-dns-host.net example.com A +short. אם הפקודה מחזירה את הכתובת החדשה, השינוי פעיל וכל השאר הוא עניין של מטמון. אם שיניתם שרתי שמות במקום רשומות, צפו לתהליך ארוך יותר, שכן האצלות (delegations) של TLD מופצות עם TTL של יומיים.

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

dig example.com NS +short מציגה את שרתי השמות שמשיבים עבור הדומיין כעת, ו-dig +trace example.com מציגה את שרשרת ההפניות מהשורש (root), כולל ההאצלה ששרתי ה-TLD מספקים. אם שמות אלו אינם שייכים לספק שבלוח הבקרה שלו ערכתם את השינויים, שם נמצאת התקלה. עליכם לערוך את הרשומות אצל הספק המופיע בהאצלה, או לשנות את ההאצלה אצל הרשם (registrar) שלכם כך שתצביע ליעד הרצוי.

הדומיין מתרגם לכתובת אך האתר עדיין לא נטען. מה עושים?

הטיפול ב-DNS מסתיים ברגע ש-dig example.com A +short מחזירה את כתובת השרת שלכם. לאחר מכן, הבעיה היא בחיבור. אם curl -I http://example.com מחזירה Connection refused, המשמעות היא שאין תהליך שמאזין בפורט זה. בקשה שנתקעת עד ל-timeout מעידה על כך שחומת אש (firewall) השליכה את החבילה. ודאו ששרת האינטרנט שלכם פעיל ומוגדר להאזין לכתובת הציבורית, ולאחר מכן בדקו את חומת האש בשרת ואת חומת האש הרשתית בלוח הבקרה של ספק הענן.

מדוע איני יכול להגדיר רשומת CNAME בדומיין השורש (root domain)?

רשומת CNAME מגדירה שם ככינוי לשם אחר, ושם בעל רשומת CNAME אינו רשאי להכיל רשומות אחרות. דומיין השורש חייב להכיל רשומות SOA ו-NS כדי להתקיים כ-zone, ולכן הוא אינו יכול להיות CNAME. השתמשו ברשומת A המכילה את הכתובת בשורש, או השתמשו בפיצ'ר של הספק המכונה ALIAS, ANAME או CNAME flattening, אשר שומר את השם ומשיב לשאילתות עם הכתובת שאליה השם מתרגם כרגע.