DNS ב-Windows Server: המדריך המקיף באמת — Zones, רשומות, Forwarders ו-Scavenging

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

מה זה DNS בעצם, ולמה FQDN חשוב

DNS הוא קיצור של Domain Name System, והתפקיד שלו פשוט לכאורה: לתרגם שמות לכתובות IP. בני אדם זוכרים שמות, מחשבים עובדים עם מספרים — וה-DNS הוא המתווך. אבל כיום DNS עושה הרבה מעבר לתרגום: הוא מפרסם שירותים, מנתב דואר, מאזן עומסים ומחזיק את כל התשתית של Active Directory על הרגליים.

FQDN (Fully Qualified Domain Name) הוא שם המחשב יחד עם הדומיין שלו. אם התחנה שלכם נקראת PC1 והדומיין הוא netme.local, אז ה-FQDN המלא הוא PC1.netme.local. זו הכתובת המלאה והחד-משמעית של המכונה בתוך המרחב השמי.

ההיררכיה: TLD, ccTLD ו-Root Hints

כדי להבין DNS בעולם האמיתי צריך להתחיל מלמעלה. TLD (Top Level Domain) הוא הרמה הגבוהה בהיררכיה. ניקח את הכתובת www.netme.co.il ונפרק אותה: על הסיומת co.il אחראי ccTLD (country-code TLD), ועל סיומות כמו com. או org. אחראי gTLD (Generic TLD). מעליהם, בראש הפירמידה, יושבים שרתי ה-Root Hints — 13 קבוצות שרתים שמסומנות בנקודה בודדת ".", כי הן הרמה הגבוהה ביותר שקיימת.

• ▸gTLD — סיומות גנריות: com., net., org., dev. ואפילו coffee.
• ▸ccTLD — סיומות מדינה: co.il., ru., de.
• ▸Root Hints — נקודת ההתחלה של כל תשאול שהשרת שלכם לא יודע לענות עליו.
• ▸Zone — הטבלה שמחזיקה בפועל את הרשומות של אותו מרחב שמות.

ארגון הגג IANA אחראי על כל ה-TLDs, ובכל מדינה הוא מסמיך Registrar שמורשה למכור שמות מתחם. בישראל האחריות היא של איגוד האינטרנט הישראלי. כשקונים דומיין, ה-Registrar מבקש מכם להזין ns1 ו-ns2 — שתי כתובות של שרתי DNS (Name Servers) שיהיו האחראים הרשמיים על הדומיין שלכם.

Recursive מול Iterative — ההבדל שכולם מתבלבלים בו

נניח שתחנה בארגון מבקשת את הכתובת של mail.netme.co.il. התחנה שולחת לשרת ה-DNS הארגוני שאילתת Recursive Query — כלומר: "תמצא לי את התשובה, לא מעניין אותי איך". השרת הארגוני בודק ב-Zones שלו, ואם אין לו — הוא מעביר את הבקשה ל-Forwarder (למשל 8.8.8.8 או 1.1.1.1).

• ▸ה-Forwarder פונה ל-Root Hints ומקבל הפניה לשרת שאחראי על co.il.
• ▸הוא שואל את שרת ה-co.il מי זה netme.co.il ומקבל את כתובת שרת ה-DNS של הדומיין.
• ▸הוא שואל את שרת ה-DNS של netme.co.il מהי הרשומה mail ומקבל תשובה.
• ▸כל שלב כזה הוא Iterative Query — שאלה אחת, הפניה אחת, בלי שהצד השני מחויב לסיים את העבודה.

התשובה שמגיעה משרת ה-DNS של הדומיין עצמו נקראת Authoritative Answer — תשובה מוסמכת מהמקור. השרת שאסף אותה מחזיר אותה חזרה כ-Recursive Answer לשרת הארגוני, וזה מחזיר אותה לתחנה. זהו כל הסיפור.

איך Windows באמת מתשאל: הסדר שאסור לפספס

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

• ▸1. DNS Cache מקומי — אפשר לראות עם ipconfig /displaydns ולנקות עם ipconfig /flushdns.
• ▸2. קובץ Hosts — בנתיב C:\Windows\System32\Drivers\etc. רשומה כאן גוברת על השרת לחלוטין.
• ▸3. שרת ה-DNS הראשי שמוגדר בכרטיס הרשת, ואם הוא לא מגיב — המשני.

שינית רשומה בשרת ועדיין מקבל כתובת ישנה? לפני שאתה מאשים את ה-DNS — נקה Cache ובדוק את קובץ ה-Hosts. ב-90% מהמקרים זה שם.

סוגי Zones: Primary, Secondary ו-Stub

• ▸Primary Zone — האזור הראשי, במצב Read/Write. כאן נוצרות ומתעדכנות הרשומות של הדומיין שלכם.
• ▸Secondary Zone — עותק Read Only שנשאב משרת DNS אחר. שימושי לאתרים מרוחקים או לשיפור זמינות. השרת המקורי חייב לאשר Zone Transfer.
• ▸Stub Zone — אזור מינימלי שמחזיק רק את רשימת שרתי ה-DNS המוסמכים של דומיין אחר, כדי לפנות אליהם ישירות בלי לעבור בכל ההיררכיה.

AD Integrated Zone מול Bind File — ההחלטה שמצילה אתכם בגיבוי

בעת יצירת Zone חדש יש תיבת סימון בשם Store the zone in Active Directory. כשהיא מסומנת, הרשומות נשמרות בתוך מסד הנתונים של AD (הקובץ NTDS.dit) ומשוכפלות אוטומטית לכל ה-Domain Controllers. כלומר: גם אם שרת אחד קורס, ה-Zone חי אצל האחרים, וגיבוי של AD כולל גם את ה-DNS.

אם תורידו את הסימון, ה-Zone ייכתב לקובץ טקסט מקומי על אותו שרת בלבד. שרת DC חדש לא יקבל אותו, ואם השרת נמחק — ה-Zone נמחק איתו. בארגון עם יותר מ-DC אחד, AD Integrated היא כמעט תמיד הבחירה הנכונה.

הרשומות: מה כל אחת עושה ומתי להשתמש בה

• ▸A Record — מיפוי שם לכתובת IPv4. הרשומה הבסיסית שכל מחשב ברשת מחזיק לפחות אחת ממנה.
• ▸AAAA Record — בדיוק אותו דבר, רק עבור IPv6.
• ▸CNAME / Alias — כינוי שמפנה לרשומה אחרת ולא לכתובת IP. אם ה-IP של השרת משתנה, הכינוי ממשיך לעבוד לבד. מושלם לשמות שירות כמו intranet או portal.
• ▸MX Record — מפנה שרתי דואר חיצוניים לשרת הדואר שלכם, כולל Priority לקביעת סדר עדיפויות בין כמה שרתים.
• ▸PTR Record — תרגום הפוך מ-IP לשם, יושב ב-Reverse Lookup Zone. חיוני ללוגים, ל-SIEM ולמערכות דואר.
• ▸SRV Record — מפרסם שירותים ברשת: LDAP, Kerberos, Global Catalog, VoIP. נוצר בדרך כלל אוטומטית על ידי השירות עצמו, ובלעדיו Active Directory פשוט לא עובד.

טיפ מהשטח: כדי לבדוק רשומת MX של דומיין, פתחו CMD, הריצו nslookup, ואז set type=mx ואחריו שם הדומיין. אותו כלי בדיוק יעזור לכם לאמת רשומות SRV של ה-Domain Controllers.

Dynamic Updates — נוחות מול סיכון אבטחתי

• ▸Secure only — רק מחשבים מצורפים לדומיין יכולים לעדכן את הרשומה שלהם. זו ההגדרה המומלצת.
• ▸Allow both nonsecure and secure — כל מכונה ברשת יכולה לכתוב רשומות. תוקף יכול לרשום שם שמתחזה לשרת ארגוני. להימנע.
• ▸Do not allow dynamic updates — ניהול ידני מלא. מתאים רק ל-Zones ייעודיים וקטנים.

Reverse Lookup Zone — למה זה לא אופציונלי

Reverse Lookup Zone מתרגם כתובת IP חזרה לשם. הפקודה ping -a 192.168.1.100 שמחזירה לכם שם תחנה עובדת בזכותו. בארגון בלי Reverse Zone, לוגים של Firewall, SIEM ומערכות ניטור יציגו לכם ים של מספרים במקום שמות — וחקירת אירוע הופכת לסיוט.

Forwarders ו-Conditional Forwarders

Forwarder הוא שרת ה-DNS שאליו השרת שלכם פונה כשאין לו תשובה. בכל שרת חייב להיות לפחות אחד — לרוב ה-DNS של הספקית, של גוגל (8.8.8.8) או של Cloudflare (1.1.1.1).

Conditional Forwarder הוא אותו רעיון, אבל בתנאי: "כל שאילתה לדומיין partner.local — שלח דווקא לשרת 10.20.0.5". זה הכלי הקלאסי לאינטגרציה בין ארגונים, בין יערות AD, או לפתרון שמות של סביבת ענן פרטית בלי לחשוף אותה לעולם.

Aging & Scavenging — הפיצ'ר שמנקה, ולפעמים הורס

Scavenging אחראי למחוק רשומות שלא התעדכנו לאורך זמן, כדי שה-DNS לא יתמלא ברשומות רפאים של מכונות שכבר לא קיימות. מפעילים אותו בקליק ימני על השרת, וקובעים מרווח בדיקה (ברירת מחדל 7 ימים).

אזהרה מהשטח: הגדרת No-Refresh ו-Refresh Interval אגרסיביים מדי תמחק רשומות של שרתים סטטיים חיים. הפעילו Scavenging בהבנה מלאה, ותמיד עם גיבוי של ה-Zone.

עוד שני דברים שכדאי להכיר

• ▸Round-Robin — כשלשם אחד יש כמה רשומות A, ה-DNS מחזיר אותן לסירוגין. איזון עומסים של עני, בלי בדיקת בריאות.
• ▸DNSSEC — לא רשומה אלא מנגנון אבטחה שחותם דיגיטלית על תשובות ה-DNS ומונע הרעלת Cache והתחזות.

צ'ק־ליסט תקלות DNS מהשטח

• ▸ipconfig /flushdns בתחנה לפני כל אבחון.
• ▸לוודא שקובץ ה-Hosts נקי מרשומות ישנות.
• ▸nslookup מול השרת הספציפי כדי לוודא מי בעצם עונה.
• ▸לבדוק שה-Forwarders מגיבים ושאין חסימה ביציאה 53.
• ▸לוודא שרשומות ה-SRV של ה-DC's קיימות — בלעדיהן אין התחברות לדומיין.
• ▸לבדוק שכרטיס הרשת של השרת מצביע על עצמו כ-DNS, ולא על שרת חיצוני.

רוצים לשלוט בתשתית הארגונית, לא רק להבין אותה?

DNS הוא רק פרק אחד בעולם של איש סיסטם. בקורס System Administrator — Windows Server של מכללת נטמי בונים את התשתית מאפס: התקנת Windows Server, הקמת Domain Controller, Active Directory, GPO, DNS, DHCP, PKI, WSUS ואוטומציה ב-PowerShell — הכל בעברית, עם מעבדות מעשיות וגישה לכל החיים. זה בדיוק הקורס שהופך אנשי Help Desk למנהלי מערכות שארגונים רבים אחריהם.