מה זה DNS? איך שמות דומיין הופכים לכתובות IP

DNS (Domain Name System) ממפה שמות כמו example.com לנתונים שהלקוח צריך בשלב הבא, ברוב המקרים כתובת IP. אפליקציות מבקשות שם, ו-DNS מחזיר רשומות. DNS אינו שרת ווב, דפדפן או שכבת הצפנה. הוא עונה על שאלות חיפוש ותו לא.

#הגרסה הקצרה

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

ה-resolver עונה מהמטמון שלו כשהוא יכול. אם לא, הוא עובר על ההיררכיה של DNS. הוא שואל שרת root אילו שרתים מטפלים בדומיין העליון (כמו .com), שואל את השרת ההוא באילו nameservers הדומיין משתמש, ואז מבקש את הרשומה מאחד משרתי ה-nameserver הסמכותיים האלה. השרת הסמכותי מחזיק את הנתונים האמיתיים. ה-resolver שומר את התשובה כל עוד ה-TTL של הרשומה מאפשר, ואז מחזיר אותה ללקוח.

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

#הרשומות שפוגשים ראשונות

#לנסות על דומיין שאפשר לתעד

להשתמש בדומיין בבעלותך או בניהולך. לתרגול בלבד, example.com הוא אחד השמות ששמורים לתיעוד (RFC 2606). כדאי להיצמד לשמות שמותר לך לחפש ולהימנע מסריקת מארחים שאין לך הרשאה לבדוק.

ב-Linux או ב-macOS, עם dig מותקן:

dig example.com A
dig example.com AAAA
dig example.com MX

ב-Windows, הכלי nslookup מגיע עם מערכת ההפעלה:

nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com

הפלט למטה נלכד על מכונת Windows ב-2026-11-08 עם nslookup, דרך ה-resolver שמוגדר במכונה כברירת מחדל (dns.google, 8.8.8.8). התשובה הגיעה מה-resolver הזה ולא מהשרת הסמכותי של הדומיין. המכונה הדפיסה את התוויות בפורטוגזית, וכאן הן מוצגות באנגלית. הערכים הם תמונת מצב, ויהיו שונים במכונה שלך ובהרצות מאוחרות יותר.

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

Name:    example.com
Addresses:  2606:4700:10::ac42:93f3
	  2606:4700:10::6814:179a
	  172.66.147.243
	  104.20.23.154

אותו resolver החזיר רשומת MX עבור הדומיין:

example.com	MX preference = 0, mail exchanger = (root)

mail exchanger עם הערך (root) אומר שהיעד הוא נקודה בודדת. זה null MX, שאומר לשולחים שהדומיין לא מקבל דואר (RFC 7505).

לבסוף, שאילתת TXT עבור אותו שם:

Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

example.com	text =

	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
example.com	text =

	"v=spf1 -all"

המחרוזת השנייה היא מדיניות SPF. הערך -all אומר שאף שרת לא מורשה לשלוח דואר עבור הדומיין הזה, וזה מתאים ל-null MX שלמעלה. המחרוזת הראשונה היא ערך אטום. מחרוזות כאלה משמשות בדרך כלל להוכחת בעלות על דומיין מול שירות. כמו שכתוב בטבלה, רשומת TXT מראה מה הבעלים פרסם ולא מוכיחה יותר מזה.

שני פרטים מההרצה הזו. השורה Non-authoritative answer מאשרת שהתשובה הגיעה מהמטמון או מהחיפוש של resolver, ולא מהשרת של הדומיין עצמו. כתובות ה-IPv6 הופיעו ראשונות, אבל אי אפשר להסתמך על הסדר: הרצה מאוחרת יותר יכולה להציג אותן אחרת או להחזיר כתובות אחרות.

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

#מטמון ולמה תשובות משתנות

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

לכן תשובה אחת היא תמונת מצב. שני resolvers יכולים לחלוק זה על זה בזמן שינוי, ושניהם יכולים להיות נכונים לגבי המטמון שלהם. כדי לדעת מה הבעלים פרסם, צריך לשאול nameserver סמכותי ישירות, למשל עם dig example.com A @<nameserver> מול שרת שמופיע ברשומות ה-NS של הדומיין, או לעקוב אחרי השרשרת עם dig +trace example.com A.

#DNS, OSINT ואבטחה

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

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

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

#טעויות נפוצות

• להתייחס לתשובה אחת כקבועה. צריך לבדוק את ה-TTL ולשאול שוב מאוחר יותר.
• לקרוא CNAME ככתובת IP. צריך לעקוב אחרי הכינוי עד לרשומת A או AAAA.
• להניח שה-resolver שנשאל הוא השרת הסמכותי. הפלט מראה איזה שרת ענה.
• לקרוא רשומת TXT כהוכחה שבקרת אבטחה עובדת.
• לסרוק מארח כי DNS הצביע עליו. חיפוש וסריקה הם פעולות שונות עם הרשאות שונות.

#מה ללמוד הלאה

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