סדר name resolution ב-Windows — hosts, DNS cache, LLMNR/mDNS ו-DoH

“ההגדרות זהות, אבל רק המחשב הזה אינו מגיע לשרת הפנימי.” “זה נפתח בדפדפן, אבל האפליקציה העסקית נכשלת ב-name resolution.” “שמתי ב-hosts ואין אפקט.”

כשחוקרים בעיות כאלה, הדבר הראשון לקבע הוא איזה מנגנון עונה לשם הזה. ל-Windows יש כמה נתיבים: ה-cache, hosts, שרת DNS, LLMNR, NetBIOS ו-mDNS, וחלק מהאפליקציות משתמשות בנתיב משלהן שנפרד מ-Windows.

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

תנאים מוקדמים למאמר

מאמר packet capture מכסה את ה-packets שזורמים על ה-wire, ומאמר ה-proxy מכסה “של מי הגדרות ה-proxy נקראות”. המאמר הזה מכסה את השלב שלפניהם: “מאיפה באה כתובת ה-IP של היעד”, מאורגן על בסיס מקורות ראשוניים של Microsoft.

1. קודם המסקנה

יש שלושה דברים לזכור.

• Name resolution ב-Windows אינו תמיד מתקדם בתור בודד לפי סדר. ה-cache ו-hosts באים קודם, אבל לשם single-label, DNS ו-LLMNR/NetBT רצים במקביל כברירת מחדל.³⁴
• אותו שם נותן תוצאות שונות כשהגדרות ה-PC ונתיב האפליקציה שונים. חושבים בנפרד על suffixes, VPN, NRPT וה-resolver המובנה של הדפדפן.⁵⁶⁷
• בחקירה, מגבילים את הנתיב שבשימוש ומשווים את התוצאות. מפרידים cache, DNS ו-link-local עם המתגים של Resolve-DnsName, ואז מאשרים עם diff של הגדרות מול מחשב שעובד ועם capture.⁸

משתמשים בדיאגרמה הבאה כמפה הכוללת.

flowchart TB
    accTitle: Name resolution הוא מחסנית של שכבות
    accDescr: בקשת name resolution עוברת מ-API של האפליקציה לשירות DNS Client; ה-cache ו-hosts נבדקים קודם, אחר כך שרת DNS, ולשמות single-label בלבד, מנסים LLMNR ו-NetBIOS (במקביל ל-DNS כברירת מחדל). לשמות .local, mDNS הוא נתיב נוסף לצד ה-DNS המוגדר. לדפדפן יש resolver משלו מחוץ לתור הזה
    app["אפליקציה (getaddrinfo)"] --> svc["שירות DNS Client"]
    svc --> cache["Cache (כולל hosts)"]
    cache -->|אם אין| dns["שואלים את שרת DNS"]
    cache -->|"אם אין, שם single-label (במקביל ל-DNS כברירת מחדל)"| ll["LLMNR / NetBIOS"]
    svc -->|"שם .local (נתיב נוסף)"| mdns["mDNS"]
    browser["דפדפן"] -.->|resolver משלו, DoH| ext["נתיב נפרד"]

ה-cache נבדק קודם; מעבר לו, DNS ו, לשמות single-label, LLMNR ו-NetBIOS רצים במקביל. לדפדפן יש נתיב נפרד.

להלן, “איזו שכבה עונה” מכוסה בפרקים 3 עד 5, “איך השאילתה נשלחת” בפרק 6, ו”איך לאמת” בפרקים 7 ו-8. DoH היא יכולת שמחליפה את ה-transport לשרת DNS ל-HTTPS; היא אינה מחליפה את הסדר של hosts, cache ו-NRPT.⁹

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 48, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. “Name Resolution” אינו פעולה אחת

כל מה שהאפליקציה מקבלת בחזרה הוא כתובת או שגיאה

כשאפליקציה מתחברת באמצעות שם כמו www.example.com, נקרא getaddrinfo של Winsock (גרסת Unicode היא GetAddrInfoW). למרחב השמות NS_DNS, הפונקציה הזו ממירה את השם לכתובת דרך DNS, קובץ hosts המקומי ומנגנונים אחרים. אם כמה ספקי namespace עונים, היא מאגדת את התשובות שלהם ומחזירה אותן.¹⁰

כלומר, מתוצאה שהאפליקציה מקבלת, אי אפשר לדעת איזו שכבה ענתה.

גם Dns.GetHostAddresses של .NET משתמש ב-getaddrinfo ב-Windows. למארח שרשום ב-hosts, הוא מחזיר את הכתובת הזו בלי לשאול שרת DNS. גם HttpClient רץ מעל מחלקת Dns הזו, כך שאפליקציית .NET שמתחברת ישירות ליעד יורשת את סדר name resolution של Windows.¹¹

דרך HTTP proxy, השם שנפתר משתנה. מה שנפתר מקומית הוא שם ה-proxy; שם היעד נפתר בצד ה-proxy. במקרה הזה hosts המקומי, ה-cache, suffixes ו-NRPT אינם משתתפים בפענוח היעד. אילו הגדרות proxy בשימוש מכוסה במאמר ה-proxy.

2.1 שירות DNS Client מחליט על הסדר

מה שעובד מתחת ל-getaddrinfo הוא שירות DNS Client (שם השירות Dnscache). התיעוד של Microsoft מתאר את הסדר הבסיסי כך.³

1. בודקים את ה-cache.
2. בודקים את קובץ hosts.
3. שואלים את שרת DNS.

כי תוכן hosts נטען ל-cache כשהשירות עולה, המאמר מתייחס לשני הראשונים יחד כ-שכבה 1, “cache ו-hosts”.⁵

מעבר לזה, הנתיב מתפצל לפי השם ולפי המדיניות.

“Smart multi-homed name resolution” ברירת המחדל שולח שאילתות DNS, LLMNR ו-NetBT לכל הרשתות במקביל. איזו תשובה מאומצת נקבעת לפי הכללים בסעיפים 4.3 ו-5.2.⁴

לכן, “מתי השאילתה נשלחת” ו”העדיפות שניתנת לתשובות שחוזרות” הם שני עניינים שונים. לראות LLMNR או NetBT ב-capture אינו אומר לבדו “DNS נכשל”. “שלוש השכבות” במאמר הן חלוקה להסבר; הן אינן אומרות שהשכבות תמיד רצות ברצף בסדר זמן.

2.2 דברים מחוץ לתור

שני אלה שקל במיוחד לבלבל הם אלה.

שימוש ב-client המובנה של Edge אינו אומר לבדו ששרת DNS משתנה. סעיף 6.2 מטפל בזה בנפרד מהגדרת Secure DNS שבוחרת ספק אחר.

3. שכבה 1 — ה-Cache ו-hosts

מה שרוצים לדעת בשכבה הזו הוא אילו תשובות נשארות בתוך ה-PC. ה-cache מחזיק לא רק תשובות נכונות אלא גם תשובות ישנות ותשובות “השם אינו קיים”.

3.1 hosts נטען ל-cache

קובץ hosts נמצא ב-C:\Windows\System32\drivers\etc\hosts. כששירות DNS Client עולה, המיפויים של שם-לכתובת-IP שלו נטענים ל-resolver cache. רשומות שהתקבלו משאילתות DNS מוחזקות באותו cache למשך ה-TTL (time to live) שלהן.⁵

ipconfig /displaydns מציג גם את הרשומות שנטענו מ-hosts וגם את הרשומות שהתקבלו משאילתות DNS אחרונות.¹³ בדוגמה של Microsoft עצמה, אם שמים contoso.com ב-hosts, Resolve-DnsName contoso.com מחזיר את הכתובת הזו ושום תעבורת DNS אינה זורמת.³

איך לקרוא היעדר packets של DNS

אם פותרים FQDN בלי DoH או DoT, name resolution מצליח, ואין שאילתה על פורט 53, ה-cache או hosts כנראה עונים. קודם, עם זאת, שוללים את הנתיבים האחרים הבאים.

לא מסיקים “cache” רק כי “אין כלום על פורט 53”; מסתכלים גם על הנתיבים שיכולים להיות בשימוש. שורת hosts לבדיקה שנשארה במכונת פיתוח יכולה להסיט חקירה.

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

3.2 גם תשובות שליליות נכנסות ל-cache

“לא נמצא” הוא גם אחת התשובות שנשמרות ב-cache. DNS client שומר תשובות שליליות וגם חיוביות.⁵

אם ipconfig /displaydns מציג “Name does not exist” לשם היעד, תשובה שלילית משרת DNS נשארת בלקוח. הנוהל של Microsoft אומר להשליך אותה עם ipconfig /flushdns.¹⁴¹³

זמן השמירה של ה-cache השלילי הוא MaxNegativeCacheTtl תחת HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters, וברירת המחדל היא 5 שניות.¹⁵ זו הסיבה שמחשב יכול להמשיך להחזיר כשלים לכמה שניות גם מיד אחרי שרשומה נוספה ל-DNS.

3.3 TTL ו-“רק חלק מהמחשבים ישנים”

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

Clear-DnsClientCache מתנהג כמו ipconfig /flushdns ומוחק את כל תוכן ה-cache, כולל תשובות שליליות.¹⁶ עם Get-DnsClientCache, אפשר לשלוף את ה-cache כאובייקטים ולבדוק את סוג הרשומה ואת ה-TTL שנשאר.¹⁷

# האם שם מסוים נמצא ב-cache, וכמה שניות TTL נשארו?
Get-DnsClientCache -Entry 'app01.corp.example.com' |
    Select-Object Entry, Type, Status, TimeToLive, Data

# בודקים יחד את תוכן hosts ואת ה-cache
ipconfig /displaydns | Select-String -Pattern 'app01' -Context 0,6

# משליכים את ה-cache (כולל תשובות שליליות)
Clear-DnsClientCache

אם נמצאת תשובה בשכבה 1, החיפוש הזה מוכרע לפני שהוא מגיע לשרת DNS. עם זאת, נשארת האפשרות שתשובה שגויה נלמדה במקור משרת DNS. לא עוצרים בניקוי; גם בודקים את התשובה שהתקבלה מחדש בשלב 3 של פרק 8.

4. שכבה 2 — שאילתת שרת DNS

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

4.1 שמות Single-Label ו-Suffixes

קודם בודקים את צורת השם שהאפליקציה העבירה.⁵

Suffix הוא חלק הדומיין שמצורף אחרי שם קצר. צירוף corp.example.com ל-app01 הופך את השם שנשאל ל-app01.corp.example.com.

כשקיימת רשימת חיפוש

Suffixes מרשימת suffix search של DNS מצורפים לפי הסדר מהראש, והשם נשלח עם נקודה בסוף. ברגע שרשימת חיפוש מוגדרת, רק הרשימה הזו בשימוש. ה-suffix הראשי, suffixes ספציפיים לחיבור, ו-name devolution אינם בשימוש.¹⁸

כשאין רשימת חיפוש

מצורף ה-DNS suffix הראשי. אם name devolution מופעל, התווית השמאלית ביותר מוסרת אחרי כל כשל והשם מנוסה שוב; למשל, מ-www.test.contoso.com ל-www.contoso.com. אם לאדפטר יש DNS suffix ספציפי לחיבור, גם זה מצורף ונשלח.⁵

מסיבה זו, אותו server01 מתרחב אחרת בסביבה שבה Group Policy מפיץ רשימת חיפוש ובסביבה שבה חברות בדומיין מספקת suffix ראשי.

רשימה ארוכה גם מגדילה את ההמתנה

אם ה-suffix הנכון קרוב לסוף הרשימה, זמן השאילתה מצטבר עד שמגיעים אליו. גם Microsoft מסבירה את ההשהיה הזו עם דוגמה שמנסה שישה suffixes. כדי לנסות רק הרחבה ספציפית אחת, מצרפים נקודה בסוף, כמו ב-internal.contoso.com..³

# הגדרות גלובליות: רשימת חיפוש ו-devolution
Get-DnsClientGlobalSetting

# לפי ממשק: suffix ספציפי לחיבור והגדרות רישום
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering

# שרתי DNS לפי ממשק (גם IPv4 וגם IPv6)
Get-DnsClientServerAddress | Where-Object ServerAddresses | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Get-DnsClientGlobalSetting מחזיר את ההגדרות הגלובליות כמו רשימת החיפוש והאם ובאיזו רמה devolution מופעל; Get-DnsClient מחזיר את ההגדרות לפי ממשק.¹⁹²⁰

4.2 הסדר של כמה שרתי DNS ו-Timeouts

כש”זה אינו נכשל, אבל יש המתנה של כמה שניות”, חושדים ב-retransmissions לשרת DNS שאינו עונה. לשרתי DNS המוגדרים על NIC בודד, תזמון retransmission ברירת המחדל מסתדר כך.²¹

זו הטבלה למקרה שבו אין תשובה. בפרט, לא מבלבלים בין השניים הבאים.

כש”עצרנו אחד מהם אבל זה אינו עובר”, אם שרת שמחזיק zone ישן ממשיך לרוץ ומחזיר תשובות שליליות, הפענוח אינו עובר לשרת הבא.²¹

השרת הרביעי ואילך אינם מושגים עד 4 שניות

אם השרת שיכול לענות הוא רביעי או מאוחר יותר ברשימה, עוברות לפחות 4 שניות אחרי השאילתה הראשונה. אם הדדליין של האפליקציה קצר מזה, היא נכשלת בשלב name resolution. כדי להוציא את השאילתה מוקדם יותר, היה צריך להזיז את השרת הזה לשלושת הראשונים, אבל התיקון השורשי הוא לתקן את השרתים שאינם ניתנים להגעה לפניו, או להסיר אותם מההגדרות. גם בוחנים מחדש את ה-timeout בצד האפליקציה.²¹

גם בדוגמה של Microsoft, תצורה שבה רק אחד מארבעה שרתים ניתן להגעה לוקחת כ-4 שניות להשלים. אפשר למדוד את הזמן שחלף עם Measure-Command, ואותו מסמך מתייחס לפחות משנייה כמקובל.³

# שואלים שרת מסוים ישירות, DNS בלבד, ומקבלים את הזמן שחלף במילישניות
(Measure-Command {
    Resolve-DnsName -Name 'app01.corp.example.com' -Server 10.0.1.2 -DnsOnly
}).TotalMilliseconds

כי הפקודה הזו מקבעת את השרת, היא מודדת את זמן התגובה של השרת הזה לבדו. ההשהיה עד שמגיעים לרשומה הרביעית ברשימה נבדקת עם שאילתה בלי -Server, או עם capture של השאילתה הזו.

שימו לב ש-DNS client מעלה שרתים שעונים מהר יותר, זוכר שרתים שאינם עונים, ומנסה אותם מחדש מעת לעת. גם ה-timeout ההתחלתי מותאם בטווח של 25 עד 1,000 מילישניות על בסיס ביצועים קודמים. הטבלה למעלה היא השלד ברירת המחדל, ולכן מדידות בפועל סוטות ממנה.⁵

4.3 כמה NIC-ים ו-“Smart Multi-Homed Name Resolution”

במחשב עם קווי ו-Wi-Fi, או מחשב שאליו נוסף מתאם VPN, בודקים לא רק את רשימת שרתי DNS אלא גם את השאילתה בין רשתות ואת בחירת התשובה.

Retransmission לכמה אדפטרים

בנוהל השאילתה של Microsoft, השאילתה הולכת לשרת DNS הראשון של האדפטר המועדף, עם המתנה של שנייה. אם אין תשובה, היא הולכת לשרת הראשון של כל אדפטר שעדיין בסט המועמדים, עם המתנה של 2 שניות, ואחרי זה לכל השרתים של כל האדפטרים, עם המתנות של 2, 4 ו-8 שניות. כששרת באדפטר אחד מחזיר תשובה שלילית, שאר השרתים של האדפטר הזה מוסרים מהמועמדים.⁵

ה-Policy ששולט בשאילתה במקביל

הגדרת Group Policy “Turn off smart multi-homed name resolution” שולטת בהתנהגות הבאה.⁴

כי שם ה-policy הוא “Turn off”, שימו לב שהפעלת ה-policy מכבה את האופטימיזציה.

דוגמה שבה VPN משנה את התוצאה

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

עם שתי תשובות חיוביות, האימוץ נקבע לפי סדר ה-binding. ב-Windows הנוכחי, העדיפות הזו נקבעת לפי interface metric; ככל ש-InterfaceMetric שמוצג על ידי Get-NetIPInterface קטן יותר, העדיפות גבוהה יותר. הבדלים בסדר הזה ממחשב למחשב הופכים להבדלים בתוצאה.²²

אם, מצד שני, הצד הביתי מחזיר תשובה שלילית, האדפטר הזה מוסר מהמועמדים ומשתמשים בתשובה של צד ה-VPN.⁵ מוצרי VPN מפיצים את NRPT או “Turn off smart multi-homed name resolution” בדיוק כדי לשלוט בהבדלים האלה.

4.4 NRPT — שינוי לאן שאילתות הולכות לפי namespace

NRPT (Name Resolution Policy Table) הוא טבלה שמציינת, לפי namespace כמו .corp.contoso.com, אילו שרתי DNS להשתמש בהם ואת הגדרות DirectAccess ו-DNSSEC. פרופילי DirectAccess ו-Always On VPN כותבים אליה כללים כדי לייצר התנהגות כמו “לשלוח רק שמות פנימיים ל-DNS הפנימי”.²³⁶

Get-DnsClientNrptPolicy -Effective מציג את הכללים שבתוקף בפועל.

# כללי NRPT שבתוקף בפועל
Get-DnsClientNrptPolicy -Effective

# מציגים רק את הכללים של namespace מסוים. -Namespace מסנן רק לפי מאפיין Namespace; הוא אינו מתאים מול שם.
# העברת 'app01.corp.example.com' אינה מחזירה את כלל ה-suffix של '.corp.example.com'.
# כדי לדעת איזה כלל חל על שם, מונים את הכללים ומתאימים אותם בעצמכם, כמו בשלב 4 של פרק 8
Get-DnsClientNrptPolicy -Effective -Namespace '.corp.example.com'

NRPT חל רק על אפליקציות שמשתמשות ב-Windows DNS API. אפליקציות עם מימוש DNS משלהן עוקפות את הנתיב הזה. תיעוד VPNv2 CSP מצטט nslookup כדוגמה ודורש Resolve-DnsName לבדיקת NRPT. גם ה-resolver המובנה של הדפדפן ו-DoH מחוץ ל-Windows DNS API.⁶

5. שכבה 3 — נתיבי המילוט לשמות Single-Label: LLMNR, NetBIOS, ואז mDNS

5.1 איך שלושת הפרוטוקולים נבדלים

LLMNR ו-NetBIOS over TCP/IP (NetBT) הם אמצעים חלופיים לפענוח שם single-label כמו app01. כברירת מחדל הם רצים במקביל ל-DNS, ותשובה link-local יכולה להיות מאומצת גם כש-DNS מחזיר תשובה חיובית. הם הופכים לרצף אחרי כשל DNS רק כש-smart multi-homed name resolution כובה.⁴

mDNS נפרד מאלה; זה נתיב נוסף לשמות .local. זה אינו catch-all שנכנס אחרי שפענוח DNS של שם single-label נכשל.²⁴

גם ל-.local, לא מדלגים על בדיקת DNS

.local אינו הופך ל-mDNS בלבד. אם דומיין Active Directory הוא משהו כמו corp.local, השם הזה ממשיך להיות נפתר גם על ידי שרתי DNS המוגדרים ועל ידי NRPT. גם RFC 6762 מתיר דו-קיום עם unicast DNS. כשחוקרים שמות .local, בודקים גם את מדיניות DNS ו-VPN.²⁴

NetBT תלוי אם WINS קיים ובסוג ה-node

בלי WINS מוגדר ברירת המחדל היא B-node; עם אפילו שרת WINS אחד מוגדר, ברירת המחדל היא H-node.²⁹ Broadcasts של LLMNR ו-NetBT אינם חוצים subnets, אבל שאילתות ל-WINS הן unicast ולכן יכולות.

nbtstat -c מציג את cache השמות של NetBIOS, ו-nbtstat -R מנקה את ה-cache וטוען מחדש LMHOSTS.³¹

5.2 איזה מהם מקבל עדיפות

איזו תשובה מקבלת עדיפות אחרי השאילתות במקביל גם נשלטת ב-policy.⁴

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

5.3 הכיוון של Microsoft: יישור ל-mDNS

באפריל 2022, Microsoft הכריזה על כיוון של יישור ל-mDNS והפחתה הדרגתית של NetBIOS name resolution ו-LLMNR.²⁷ גם פרוטוקולי גילוי התקנים ישנים ולא מאובטחים כמו Computer Browser הפכו ל-deprecated.³² תכנונים שמשלימים שמות single-label עם multicast או broadcast בדרך החוצה.

המידע של Microsoft על פגיעות LLMNR מפרט, כ-workarounds, חסימת TCP/UDP 5355 והפעלת הגדרת Group Policy “Turn off multicast name resolution”. הוא גם מציין שכתוצאה המחשב עשוי להפוך לבלתי נראה למחשבים אחרים.²⁵ הפעלת ה-policy הזה מכבה LLMNR בכל האדפטרים של DNS client.⁴

ההחלטה לכבות אותם עצמה נכונה, אבל צריך לספק תחליף לנתיב שנעלם ב-DNS. להתקנים שאינם רשומים ב-DNS, רושמים את רשומות A שלהם או מפעילים רישום דינמי דרך DHCP, ומשנים את היעדים ל-FQDNs. התקנים שתומכים ב-mDNS יכולים להשתמש בשמות .local, אבל הטווח מוגבל למקום שה-multicast עובר.

5.4 המקרה הטיפוסי “רק חלק מהמחשבים אינם מתחברים”: שמות Single-Label

כשקובץ תצורה או קיצור דרך מכיל \\fileserver01 או http://app01/, אותו שם מייצר את ההבדלים הבאים.

מה ש-Resolve-DnsName app01 -LlmnrOnly אומר לכם הוא “האם ניתן לפענח דרך LLMNR”. הוא אינו אומר מאיפה באה התשובה שאומצה בשאילתות יומיומיות. השוואה עם התוצאה בלי מתגים, ו-captures, נעשות בשלב 5 של פרק 8.⁸

התיקון השורשי הוא FQDNs ורישום DNS

משנים יעדים שתלויים בשמות single-label ל-FQDNs, ומאחדים name resolution על DNS.

SMB2 ואילך מתחברים ישירות על TCP 445 ואינם משתמשים ב-sessions של NetBIOS.³³ זה, עם זאת, עניין של transport. בשלב פענוח השם ביעד כמו \\fileserver01\share, עשויים להשתמש ב-LLMNR או NetBT. מציינים את ה-FQDN, כמו ב-\\fileserver01.corp.example.com\share, כדי להסיר את התלות בנתיב שם single-label.

נשארות כמה זהירויות גם עם FQDNs. גם FQDN בלי נקודה בסוף מנוסה עם suffixes אם ה-policy שמצרף suffixes לשמות multi-label מופעל. שם שמסתיים ב-.local עשוי להשתמש ב-mDNS לצד DNS. הצורה שמקבעת את השם ללא תנאי היא השם המוחלט עם נקודה בסוף. ההנחה לטיפול ב-“FQDN מקובע ל-DNS” כנכון בפועל היא שה-policy למעלה כבוי וששם הדומיין הפנימי אינו משתמש ב-.local.

6. ה-Transport לשרת DNS — DoH אינו משנה את הסדר

6.1 DoH ב-Windows 11 / Windows Server 2022

DoH של Windows היא יכולת ששולחת שאילתות לשרת DNS מעל HTTPS. היא משולבת עם hosts, cache ו-NRPT הקיימים, ועם הגדרות resolver לפי אדפטר ולפי פרופיל; היא אינה מחליפה את הסדר שתואר בפרקים 3 ו-4.⁹

DNS client של Windows 11 תומך ב-DoH, וגרסאות חדשות יותר תומכות גם ב-DoT (DNS over TLS). התיאור של Microsoft, עם זאת, אינו מציין אילו גרסאות תומכות ב-DoT, כך שזה אינו מובטח בכל סביבה שהמאמר מניח. הבא מכסה DoH.⁹

קודם בודקים את רשימת known DoH servers

אלא אם DDR מופעל, אפשר להשתמש רק בשרתים שברשימת known DoH servers. רשימת ברירת המחדל מכילה Cloudflare, Google ו-Quad9, ואפשר לבדוק אותה עם Get-DnsClientDohServerAddress. לשרת DNS פנימי וכדומה, רושמים תבנית DoH יחד עם הגדרות fallback ו-auto-upgrade.¹³⁴

# רשימת known DoH servers
Get-DnsClientDohServerAddress

# רושמים את שרת ה-DNS הפנימי כשרת DoH (בלי נפילה ל-plaintext, עם auto-upgrade)
Add-DnsClientDohServerAddress -ServerAddress '10.0.1.2' `
    -DohTemplate 'https://dns.corp.example.com/dns-query' `
    -AllowFallbackToUdp $false -AutoUpgrade $true

רישום אפשרי גם עם netsh dnsclient add encryption. ה-netsh dnsclient set global doh=yes|no|auto הגלובלי הוא הגדרה נפרדת מ-autoupgrade לפי שרת.³⁵

auto לבדו אינו אוסר fallback ל-plaintext. האם ליפול ל-UDP בכשל נקבע בנפרד על ידי udpfallback לפי שרת, או -AllowFallbackToUdp ב-PowerShell. כדי להגביל פענוח ל-transport מוצפן בלבד, מכבים גם את ה-fallback.³⁵

עם DDR מופעל, יש גם נתיב גילוי דינמי

בגרסאות שתומכות ב-DDR (Discovery of Designated Resolvers), resolver שמוגדר ב-plaintext יכול לפרסם את נקודות הקצה המוצפנות שלו. כי החיבור יכול לשדרג להצפנה בלי רישום ברשימה הסטטית, אי אפשר לומר “זה לא ברשימה, אז זה לא DoH”.³⁵

כדי ש-DDR יעבוד, נדרשים גם netsh dnsclient set global ddr=yes הגלובלי וגם set interface <name> ddr=yes לפי אדפטר. האם ליפול ל-plaintext כשפענוח מוצפן שהתקבל דרך DDR נכשל נקבע על ידי ddrfallback, שכבוי כברירת מחדל.

בחקירה, מלבד הרשימה הידועה, בודקים netsh dnsclient show global ו-netsh dnsclient show state, ואת הערכים שהוגדרו עם set interface באדפטרים שיש להם שרתי DNS. תת-פקודות show המוגדרות בתיעוד הן encryption, global ו-state; אין תת-פקודת show ספציפית לאדפטר.³⁵

מפרידים “Allow”, “Require” ונפילה ל-plaintext

באפליקציית Settings, מגדירים את הגדרות DNS לידניות; “Preferred DNS encryption” ניתן לבחירה רק כששרת DNS המועדף ברשימה הידועה. יש שלוש אפשרויות.¹

להגדרת Group Policy “Configure DNS over HTTPS (DoH) name resolution” יש Allow, Prohibit ו-Require. עם Allow, DoH בשימוש כש, בנוסף לרישום ברשימה הידועה, מתקיימים תנאים כמו auto-upgrade, הגדרת ההצפנה של האדפטר, או doh=auto הגלובלי. עם “Require”, name resolution עצמו נכשל מול שרתים שאינם תומכים ב-DoH.¹³⁵

לא מחילים “Require DoH” על מחשבים מצורפים לדומיין. Microsoft מזהירה על זה במפורש. Active Directory Domain Services תלוי מאוד ב-DNS, ושירות DNS Server שמגיע עם Windows Server אינו תומך בשאילתות DoH.¹

ב-capture, קוראים את ההגדרות ואת התעבורה בפועל בנפרד

שאילתות שנשלחות בפועל מעל DoH הולכות בתוך TLS על פורט 443 ולא UDP 53. גם עם “Allow DoH”, עם זאת, שאילתות לשרתים שאינם ברשימה הידועה, ו-fallbacks אחרי כשל הצפנה, זורמות ב-plaintext. זה ש-DoH מוגדר אינו גורם לתעבורת פורט 53 להיעלם.

אם אין שאילתות DNS גלויות, בודקים DoH ו-DoT (פורט 853) בנוסף ל-hosts ול-cache. לאיך ללכוד, ראו מאמר packet capture.

6.2 DoH בדפדפן נפרד מה-OS

DNS client המובנה של Edge ושינוי יעד השאילתה דרך Secure DNS קלים יותר להבנה כשמפצלים לשני שלבים.

ה-client המובנה נשלט על ידי BuiltInDnsClientEnabled, ושאילתות DoH תמיד נעשות על ידי ה-resolver המובנה.⁷ Secure DNS כבוי כברירת מחדל במחשבים בניהול ארגון ומוגדר עם DnsOverHttpsMode (off / automatic / secure) ו-DnsOverHttpsTemplates.³⁶³⁷

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

המסקנה: לא מתייחסים להצלחת הדפדפן ולהצלחת האפליקציה העסקית כראיה על אותו נתיב. בודקים את נתיב ה-OS עם Resolve-DnsName או ping.

7. איזה נתיב האפליקציה לוקחת?

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

המתגים העיקריים של Resolve-DnsName, מאורגנים לפי מטרת חקירה, הם כדלקמן.⁸

7.1 A ו-AAAA: IPv6 חוזר קודם

גם כש-name resolution מצליח, בחירת הכתובת שאחרי יכולה להאט את החיבור.

DNS client שואל גם A (IPv4) וגם AAAA (IPv6). גם ב-capture, שתי השאילתות מופיעות כזוג.³ אחרי שהתשובות חוזרות, getaddrinfo ומחסנית החיבור בוחרים את הכתובת לשימוש. Windows Vista ואילך משתמשים בטבלת prefix של RFC 3484, וכברירת מחדל מעדיפים IPv6 global unicast על IPv4.³⁸

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

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

Microsoft אינה ממליצה לכבות IPv6 כטיפול, כי חלק מרכיבי Windows מפסיקים לעבוד. במקום זה, היא מתארת הגדרת DisabledComponents ל-0x20 כדי להעדיף IPv4 במדיניות ה-prefix.³⁸ המקרה שבו localhost נפתר ל-::1 ומתנגש עם חקירה שהניחה 127.0.0.1 מכוסה גם במאמר packet capture.

8. נוהל הבידוד — מקלפים את השכבות מלמעלה

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

שלב 1: בודקים את צורת השם

בודקים, בלוג או בקובץ תצורה, את השם שהאפליקציה באמת מעבירה. הנתיב משתנה לפי אם זה שם single-label, מסתיים ב-.local, או יש נקודה בסוף. לשם קצר כמו http://app01/, מתחילים מההשלמה בסעיף 4.1 ומההבדלים לפי PC בסעיף 5.4.

שלב 2: האם ניתן לפענח מה-cache ומ-hosts לבדם?

Resolve-DnsName -Name 'app01.corp.example.com' -CacheOnly
Get-DnsClientCache -Entry 'app01.corp.example.com'
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String -Pattern 'app01'

-CacheOnly רק מגביל את החיפוש הזה ל-cache המקומי. אם תשובה שגויה נלמדה משרת DNS, אותו ערך חוזר אחרי ניקוי. העובדה שזה היה ב-cache אינה הוכחה ששרת DNS אינו קשור.⁸

שלב 3: האם ניתן לפענח דרך DNS לבדו?

# מוציאים את hosts, לא שולחים LLMNR/NetBIOS, ושואלים רק את שרתי ה-DNS המוגדרים
Resolve-DnsName -Name 'app01.corp.example.com' -NoHostsFile -DnsOnly

אם לשלב 2 לא הייתה תשובה והשלב הזה רק מצליח, זה בדרך כלל cache miss רגיל. אפשר לקרוא לזה בעיית cache או hosts רק כששלב 2 הראה תשובה ישנה, תשובה שגויה, או רשומת cache שלילית.

אם גם השלב הזה נכשל, חוקרים את הנתיב לשרת DNS, את צד השרת, ואת המדיניות בצד הלקוח. לפני שממשיכים לשלב 4, בודקים את הבאים.

• Get-DnsClientNrptPolicy -Effective: האם יש כלל שמכוון את השם לשרת DNS אחר?
• Get-DnsClientDohServerAddress ו-Group Policy של DoH: האם “Require DoH” מוגדר מול שרת שאינו תומך?

אם יש NRPT, שרתי היעד בשלב 4 משתנים. אם “Require DoH” הוא הסיבה, רק name resolution נכשל בעוד הנתיב והשרת שניהם בריאים. מסיימים קודם את הבדיקות בסעיפים 4.4 ו-6.1.

שלב 4: שואלים כל שרת ישירות

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

$name = 'app01.corp.example.com'
# אוספים את שרתי ה-DNS של הממשקים המחוברים, גם IPv4 וגם IPv6.
# שרתים שנשארו בהגדרות של VPN או virtual switch מנותקים אינם חלק מנתיב הפענוח הנוכחי, ולכן מוציאים אותם (לא מפספסים שרתים שמוגדרים ל-IPv6 בלבד)
$connected = @((Get-NetIPInterface -ConnectionState Connected).ifIndex | Select-Object -Unique)
$servers = @((Get-DnsClientServerAddress |
    Where-Object { $_.ServerAddresses -and ($connected -contains $_.InterfaceIndex) }).ServerAddresses)
# שרתי כלל ה-NRPT שחל על השם הזה (Always On VPN או DirectAccess כותבים אותם) אינם מופיעים בהגדרות האדפטר, ולכן בוחרים אותם מה-policy האפקטיבי.
# הפרמטר -Namespace של Get-DnsClientNrptPolicy מסנן רק לפי מאפיין Namespace של הכלל; הוא אינו מתאים מול השם.
# לכן מתאימים בעצמכם את כלל Any (.), כללי suffix (נקודה בהתחלה; חלים על ה-namespace עצמו ועל child domains), כללי FQDN וכללי prefix (חלק שם המארח; wildcards כמו web* מותרים),
# ומאמצים את הכלל הספציפי יותר (הארוך יותר). כלל Any הוא הקצר ביותר, ולכן נבחר רק כשאין כלל אחר שמתאים
# Namespace הוא קבוצת מחרוזות (מוצג Namespace : {.corp.example.com}), לכן מרחיבים את האיברים של כל כלל להתאמה ומסדרים לפי אורך ה-namespace שהתאים
# לשם מוחלט עם נקודה בסוף (app01.corp.example.com.) מסירים את הנקודה רק להתאמה. מעבירים את $name המקורי ל-Resolve-DnsName
$matchName = $name.TrimEnd('.')
$label = $matchName.Split('.')[0]
$matched = foreach ($policy in @(Get-DnsClientNrptPolicy -Effective)) {
    foreach ($ns in @($policy.Namespace)) {
        if (-not $ns) { continue }
        $hit = if ($ns -eq '.') { $true }
               elseif ($ns.StartsWith('.')) { $matchName.Equals($ns.TrimStart('.'), [System.StringComparison]::OrdinalIgnoreCase) -or $matchName.EndsWith($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               elseif ($ns.Contains('.')) { $matchName.Equals($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               else { $label -like $ns }
        if ($hit) { [pscustomobject]@{ Namespace = $ns; Policy = $policy } }
    }
}
$rule = $matched | Sort-Object { $_.Namespace.Length } -Descending | Select-Object -First 1
$policyServers = @()
if ($rule) { $policyServers = @(@($rule.Policy.NameServers) + @($rule.Policy.DirectAccessDnsServers) | Where-Object { $_ }) }
if ($policyServers.Count -gt 0) {
    # אם NRPT מציין שרתים ל-namespace הזה, השאילתה בשלב 3 הולכת לשרתים האלה. שרתי האדפטר מחוץ לנתיב, ולכן מחליפים אותם
    $servers = $policyServers
}
$servers = $servers | Where-Object { $_ } | Select-Object -Unique
foreach ($server in $servers) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $r = Resolve-DnsName -Name $name -Server $server -DnsOnly -ErrorAction Stop
        $status = 'OK'
        # כמה רשומות יכולות לחזור בסדר שונה בכל תשובה, לכן ממיינים לפני ההשוואה
        $answer = ($r.IPAddress | Sort-Object) -join ','
    } catch {
        # תשובות שליליות (השם אינו קיים), SERVFAIL ו-timeouts מגיעים לכאן. משאירים את הסיבה במקום לזרוק אותה
        $status = $_.Exception.Message
        $answer = ''
    }
    [pscustomobject]@{ Server = $server; Status = $status; Answer = $answer; Milliseconds = [int]$sw.ElapsedMilliseconds }
}

קודם מיישרים את השרתים להשוואה

NameServers ו-DirectAccessDnsServers של NRPT עשויים לא להופיע בהגדרות DNS של האדפטר. אם שלב 3 שאל את שרתי NRPT אבל שלב 4 בודק רק את שרתי האדפטר, משווים נתיבים שונים.

ל-NRPT יש סוגי כללים כמו suffix, FQDN, prefix ו-Any (.), וכללים ספציפיים יותר מקבלים עדיפות.⁴⁰ -Namespace רק מסנן לפי מאפיין הכלל; הוא אינו מתאים מול שם המארח. לכן הקוד למעלה מרחיב את ה-namespaces של הכללים ומתאים אותם מול שם היעד.²³

ב-VPN מסוג split-DNS, נורמלי שה-resolver בצד הבית מחזיר תשובה שלילית לשם פנימי בעוד רק צד NRPT מחזיר חיובית. אם גם משווים שרתים מחוץ לנתיב, רושמים אותם בנפרד כ-“ביקורת” ואינם מערבבים אותם בשיפוט של אי-התאמות zone. Timeouts מול שרתים שנשארו באדפטרים מנותקים גם הם נפרדים מהשהיות בנתיב הפענוח הנוכחי.

אחר כך קוראים את התוצאות בנפרד

אם הם נבדלים גם כסטים, בודקים את תוכן ה-zone ואת מספרי הסידור. וגם, זו מדידה עם היעד מקובע על ידי -Server. ההשהיה שנגרמת ממיקום ברשימה, “4 שניות עד שמגיעים לשרת הרביעי ואילך” מסעיף 4.2, נבדקת בשלב 3 או ב-capture שלו.

שלב 5: בודקים את שכבת link-local

Resolve-DnsName -Name 'app01' -LlmnrOnly          # LLMNR בלבד
Resolve-DnsName -Name 'app01' -LlmnrNetbiosOnly   # LLMNR או NetBIOS בלבד (בלי DNS)
nbtstat -c                                        # cache של שמות NetBIOS

הבדיקה הזו מכוונת לשמות single-label. -NetbiosFallback נופל ל-NetBIOS רק כש-DNS נכשל, כך שלשם ש-DNS יכול לפענח זו אינה בדיקת NetBIOS.⁸

קוראים את התוצאות כך.

איזה פרוטוקול ענה נבדל ב-capture לפי UDP 5355 (LLMNR) מול UDP 137 (NetBT). כדי לאשר את נתיב הפענוח היומיומי, גם משווים עם הכתובת שמוחזרת על ידי Resolve-DnsName בלי מתגים, ואם הם אינם מסכימים, בודקים את התשובה שאומצה ב-capture, כי כברירת מחדל גם DNS נשאל במקביל.

שלב 6: Diff של dumps של הגדרות

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

# name-resolution-dump.ps1 -- מריצים בהרשאות administrator ומשווים את קבצי הפלט של שני המחשבים זה לצד זה
$out = "$env:COMPUTERNAME-name-resolution.txt"
$sections = [ordered]@{
    'Get-DnsClientServerAddress' = { Get-DnsClientServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'Get-DnsClientGlobalSetting' = { Get-DnsClientGlobalSetting | Format-List | Out-String }
    'Get-DnsClient'              = { Get-DnsClient | Format-Table InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering -AutoSize | Out-String -Width 200 }
    'Get-DnsClientNrptPolicy'    = { Get-DnsClientNrptPolicy -Effective | Format-List | Out-String }
    'Get-DnsClientDohServerAddress' = { Get-DnsClientDohServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'netsh dnsclient show state' = { netsh dnsclient show state 2>&1 | Out-String }
    'Get-NetIPInterface'         = { Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table InterfaceAlias, AddressFamily, InterfaceMetric, ConnectionState, Dhcp -AutoSize | Out-String -Width 200 }
    'DNSClient policy registry'  = { Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue | Format-List | Out-String }
    'ipconfig /all'              = { ipconfig /all | Out-String }
}
$sections.GetEnumerator() | ForEach-Object {
    "===== $($_.Key) ====="
    try { & $_.Value } catch { "ERROR: $($_.Exception.Message)" }  # משאירים פריטים חסרים (כמו DoH ב-Windows 10) רשומים כשגיאות
} | Set-Content -Path $out -Encoding UTF8
Write-Host "wrote $out"

מה להשוות הם סדר שרתי DNS, רשימת החיפוש, suffixes ספציפיים לחיבור, NRPT, DoH, interface metrics וערכי policy.

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient מחזיק EnableMulticast ל-“Turn off multicast name resolution”, DisableSmartNameResolution ל-“Turn off smart multi-homed name resolution”, רשימת החיפוש, ה-suffix הראשי וכן הלאה.⁴ בודקים את ה-diff מול פעולת כל שכבה שסודרה עד כאן.

שלב 7: מגבים עם Packet Capture

נוהל איסוף הנתונים של Microsoft מתחיל netsh trace start capture=yes גם בלקוח וגם בשרת, משליך את ה-cache עם ipconfig /flushdns, משחזר את הבעיה, ועוצר עם netsh trace stop.⁴¹

ב-Wireshark, מסננים עם dns.qry.name == "app01.corp.example.com" או dns.qry.name contains "app01" כדי לראות איזה שרת נשאל מה, ומה חזר.

אם firewall בצד השולח חוסם UDP 53, Resolve-DnsName עושה timeout וגם אין שאילתת DNS ב-capture. מבודדים לא רק את המקרה שבו name resolution מצליח ואין תעבורה שיוצאת, אלא גם את המקרה שבו הוא נכשל ואין תעבורה שיוצאת.³

מעבר ל-DNS, בודקים 5355 ל-LLMNR, UDP 5353 ל-mDNS, ו-UDP 137 לשירות השמות של NetBT. DoH הוא 443 ו-DoT הוא 853. איך ללכוד ולקרוא captures מרוכז במאמר packet capture.

9. תכנון בצד האפליקציה העסקית — להפוך אותה לחסונה מול Name Resolution

כדי להקל חקירות, חשוב שצד האפליקציה יוכל לרשום “איזה שם, נפתר למה, ואיפה זה נכשל”. התאמת לוג האפליקציה מול dumps של הגדרות ו-captures שאנשי IT אוספים מקלה להחליט מאיפה בפרק 8 להתחיל.

מחזיקים יעדים כ-FQDNs ואינם תלויים ב-hosts

הופכים את ברירות המחדל בקבצי תצורה, קיצורי דרך ונתיבי UNC ל-FQDNs. זה מסיר את התלות בהשלמת suffix של שמות single-label וב-LLMNR ו-NetBT. הזהירויות מסעיף 5.4, עם זאת, נשארות: mDNS לצד DNS לשמות .local, וה-policy שמצרף suffixes לשמות בלי נקודה בסוף.

hosts נוח לדריסה זמנית בזמן פיתוח, אבל הוא דורש הרשאות Administrator ועבודה ידנית. הפצה והיסטוריית שינויים קשות לניהול, וחלק מה-resolvers אינם מתייעצים איתו בכלל (nslookup אינו¹²). מחליפים יעדים דרך קבצי תצורה.

רושמים את התוצאה, הזמן וסיבת הכשל של Name Resolution

באתחול ובנקודות דומות, רושמים את כתובות IPv4 ו-IPv6 ואת הזמן שחלף ליעדים העיקריים. כי Dns.GetHostAddresses מחזיר את אותה תוצאה כמו getaddrinfo, אפשר לעקוב אחרי “באיזה מחשב, מאז מתי, למה זה נפתר”.¹¹

// רושמים באתחול את תוצאות name resolution של היעדים העיקריים (.NET 6 ואילך)
static async Task LogNameResolutionAsync(ILogger logger, string host)
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var addresses = await System.Net.Dns.GetHostAddressesAsync(host);
        logger.LogInformation("פענוח שם {Host} -> {Addresses} ({Elapsed} ms)",
            host, string.Join(",", addresses.Select(a => a.ToString())), sw.ElapsedMilliseconds);
    }
    catch (System.Net.Sockets.SocketException ex)
    {
        logger.LogError(ex, "פענוח שם נכשל {Host} שגיאה {Code} ({Elapsed} ms)",
            host, ex.SocketErrorCode, sw.ElapsedMilliseconds);
        throw;
    }
}

רושמים כשלים וזורקים שוב. החלפה שקטה לשם אחר או ל-IP קבוע הופכת את הנתיב בפועל לבלתי ידוע בחקירה. עם קוד השגיאה והזמן שחלף, אנשי IT יכולים להחליט מאיפה בשלבים 2 עד 4 להתחיל.

מאפשרים Timeouts ותשובות IPv6

DNS client מבלה עד 10 שניות לכל מועמד שנשאל מול שרתים שאינם עונים.²¹ אם suffix search מייצר כמה מועמדים, הסך יכול לעבור 10 שניות.

אם timeout החיבור נסחט ל-2 או 3 שניות, name resolution אינו מסתיים לפני הדדליין בתצורות כמו אחת שבה השרת שיכול לענות הוא רביעי או מאוחר יותר. השרת השני, עם זאת, נשאל אחרי שנייה והשלישי אחרי 2 שניות, כך ששרת בודד שנכשל אינו בהכרח אומר כשל. מתכננים עם תזמון retransmission בסעיף 4.2 בראש.

וגם, כשתשובת AAAA חוזרת וקיימים כתובת מקור IPv6 ונתיב, Windows מעדיף IPv6 כברירת מחדל.³⁸ קוד חיבור שמניח IPv4 בלבד עשוי להיכשל להתחבר גם כש-name resolution הצליח. מפרידים את הצלחת name resolution מהצלחת החיבור, ומטפלים בשני סוגי הכתובת.

10. סיכום

הדברים הראשונים להפריד ב-name resolution של Windows הם צורת השם, השכבה שמחזירה את התשובה, והנתיב שהאפליקציה לוקחת.

ה-cache ו-hosts עונים קודם, ולשמות single-label DNS ו-LLMNR/NetBT רצים במקביל כברירת מחדל. ל-.local, mDNS מצטרף. ברגע שהפענוח עובר ל-DNS, suffixes, תזמון retransmission, כמה NIC-ים ו-NRPT משנים את התוצאה. DoH היא יכולת שמחליפה את ה-transport הזה, והיא נחשבת בנפרד מה-resolver המובנה של הדפדפן.

החקירה מגבילה את הנתיב בסדר -CacheOnly, ואז -NoHostsFile -DnsOnly, ואז -Server, ואז -LlmnrOnly, ומאשרת עם diff של הגדרות ו-capture. מה שחשוב הוא לא לפספס את ה-cache השלילי, את ההבדל בין אין תשובה לתשובה שלילית, ואת המדיניות בצד הלקוח.

כש”רק המחשב הזה אינו מתחבר”, קודם בודקים את שני הדברים האלה.

באיזו צורה השם מועבר? במחשב הזה, איזה נתיב עונה?

עם שני אלה מקובעים, אפשר לצמצם איפה לבדוק.

מאמרים קשורים

• Packet capture ב-Windows בפועל — איך בוחרים בין pktmon, netsh trace ו-Wireshark
• Proxy ארגוני ו-Windows apps —‏ WinINET, WinHTTP ו-.NET
• לא לעטוף HttpClient ב-using — HTTP מעשי באפליקציות עסקיות ב-C# (תבניות יצירה, timeouts, retries)
• Windows Firewall ואפליקציות עסקיות — רושמים inbound rule ב-installer
• מלכודות של network drives ו-UNC path — עבודה עם שרתי קבצים (תיקיות משותפות) מאפליקציה עסקית
• NTLM ו-Kerberos מוסברים בדיאגרמות — למה אימות נופל ל-NTLM
• מתכוני פקודות PowerShell מעשיים — להגדיל את הכלים הקטנים שבשימוש יומיומי

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בחקירות שורש של צרות תקשורת שקשורות ל-name resolution כמו “האפליקציה העסקית אינה מגיעה לשרת הפנימי רק בחלק מהמחשבים” ו-“זה נפתח בדפדפן אבל האפליקציה נכשלת ב-name resolution”, ב-design reviews של האם אפליקציה עסקית יכולה לעמוד בשינויי סביבה כמו כיבוי LLMNR, DoH ו-VPN, ובמימוש שכבת תקשורת שרושמת תוצאות name resolution ו-timeouts. אם מצרפים dumps של הגדרות ממחשב שעובד וממחשב שנכשל כשפונים, נקודת ההתחלה של החקירה מיושבת מהר.

• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• פיתוח אפליקציות Windows
• יצירת קשר

קישורים

מאמרים קשורים

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

נושאים קשורים

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

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

ערכתי את קובץ hosts אבל השינוי אינו נכנס לתוקף. למה?

ב-Windows, תוכן קובץ hosts נטען ל-cache כששירות DNS Client עולה, ו-name resolution מתקדם בסדר cache, hosts, שרת DNS. כששינוי אינו נכנס לתוקף, קודם בודקים את הרשומה לשם הזה עם ipconfig /displaydns, ואם תשובה ישנה עדיין שם, משליכים אותה עם ipconfig /flushdns. אחר כך שואלים אם הכלי שבודקים איתו עובר בכלל דרך ה-resolver של Windows. nslookup אינו משתמש ב-resolver של ה-OS; הוא עוקף את ה-cache, את hosts ואת NRPT ושואל את שרת DNS ישירות, כך ששום דבר ב-hosts אינו משתקף בפלט שלו. כדי לראות את תוצאת הפענוח בפועל כולל hosts, משתמשים ב-Resolve-DnsName או ping. אם זה עדיין אינו נכנס לתוקף, בודקים אם לאפליקציה, כמו דפדפן, יש resolver משלה או DoH.

האתר נפתח בדפדפן, אבל רק האפליקציה העסקית נכשלת ב-name resolution.

סביר שהדפדפן והאפליקציה פותרים את השם בנתיבים שונים. כברירת מחדל Microsoft Edge מדבר עם שרת DNS עם DNS client מובנה ולא עם DNS client של ה-OS, ואם נבחר ספק אחר תחת Secure DNS (DoH), הוא שואל resolver חיצוני. מצד שני, Dns.GetHostAddresses של .NET, ו-HttpClient שמתחבר ישירות ליעד, עוברים דרך getaddrinfo של ה-OS, כך שהם כפופים ל-hosts, ל-DNS cache, ל-NRPT ולרשימת suffix search של DNS (לבקשות שעוברות דרך HTTP proxy, שם היעד נפתר בצד ה-proxy). כששניהם מחזירים תשובות שונות, הנתיב המהיר ביותר הוא להתאים איזה נתיב שאל איזה שרת DNS מה, באמצעות Resolve-DnsName ו-packet capture.

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

משווים את צורת השם ואת השכבה שבה כל מחשב מקבל את התשובה. שם single-label (שם בלי נקודה, כמו server01) מושלם עם רשימת suffix search של ה-PC או עם ה-suffix הספציפי לחיבור ונשלח ל-DNS, וכברירת מחדל הוא גם נשלח, במקביל, למנגנונים שמוגבלים לאותו subnet כמו LLMNR ו-NetBIOS broadcast (הם מנוסים ברצף אחרי ש-DNS נכשל רק כשהאופטימיזציה כבויה; אם מוגדר WINS, NetBIOS משתמש ב-unicast ויכול לחצות subnets). מחשב מצורף לדומיין עשוי לפענח את השם כי ה-suffix משלים אותו ל-FQDN, בעוד מחשב ב-VPN או ב-subnet אחר, או מחשב עם LLMNR ו-NetBIOS כבויים, אינו יכול לפענח את אותו שם. השיטה האמינה היא לאסוף את הפלט של Get-DnsClientServerAddress, Get-DnsClientGlobalSetting, Get-DnsClient ו-Get-DnsClientNrptPolicy -Effective גם במחשב שעובד וגם במחשב שנכשל ולעשות diff. התיקון השורשי הוא להפוך את היעדים בקבצי תצורה ובקיצורי דרך ל-FQDNs.

Name resolution אינו נכשל; זה פשוט לוקח כמה שניות לפני שהחיבור סוף סוף עובר. מה גורם לזה?

זה מנגנון ה-timeout והניסיון החוזר של DNS client שמתגלה. מול שרת DNS שאינו עונה, Windows שולח retransmission ב-1, 2, 4 ו-8 שניות מההתחלה ומוותר ב-10 שניות. גם עם כמה שרתי DNS מוגדרים, אם זה שעונה הוא רביעי או מאוחר יותר ברשימה, Windows ממתין לפחות 4 שניות לפני שהוא שואל את השרת הזה. גם רשימת suffix search ארוכה צוברת השהיה, כי שם single-label מנוסה עם כל suffix בתורו. מודדים כמה זמן Resolve-DnsName לוקח עם Measure-Command, ומחילים מסנן dns.qry.name ב-Wireshark כדי לראות שאילתות של איזה שרת נשארות בלי תשובה.

כיבינו LLMNR ו-NetBIOS כאמצעי אבטחה, ועכשיו חלק מההתקנים כבר אינם ניתנים להגעה לפי שם.

זה תופעת לוואי צפויה. LLMNR ו-NetBIOS over TCP/IP הם אמצעים משניים לפענוח שמות single-label של התקנים שאינם רשומים ב-DNS בתוך אותו subnet, וכיבוי שלהם מסיר את הנתיב הזה. Microsoft עצמה הכריזה ב-2022 על כיוון של יישור ל-mDNS והפחתה הדרגתית של NetBIOS name resolution ו-LLMNR, כך שההחלטה לכבות אותם עצמה נכונה. הטיפול הוא לאחד name resolution על DNS: לרשום את רשומות A של ההתקנים ב-DNS הפנימי, או להפעיל רישום דינמי דרך DHCP, ולשכתב את יעדי האפליקציות וה-shares ל-FQDNs. התקנים שתומכים ב-mDNS ניתנים לפענוח לפי שמות .local שלהם, אבל גם הנתיב הזה מוגבל לטווח שה-multicast מגיע אליו.

מה קורה ל-name resolution פנימי כשמפעילים DoH (DNS over HTTPS) ב-Windows 11?

DoH היא יכולת שמחליפה את ה-transport ל-HTTPS כש-DNS client שואל את שרתי DNS המוגדרים; הסדר הקיים של hosts, cache ו-NRPT נשאר כפי שהוא. אלא אם DDR (Discovery of Designated Resolvers) מופעל, אפשר להשתמש ב-DoH רק כשהשרת ברשימת known DoH servers, כך שאם רוצים להשתמש בשרת DNS פנימי, מנהל חייב לרשום אותו עם Add-DnsClientDohServerAddress. אם הגדרת Group Policy "Configure DNS over HTTPS (DoH) name resolution" מוגדרת ל-"Require DoH", name resolution עצמו נכשל מול שרתים שאינם תומכים ב-DoH. Microsoft אומרת במפורש לא להפעיל את ההגדרה הזו במחשבים מצורפים לדומיין, כי שירות DNS Server שמגיע עם Windows Server, שעליו Active Directory תלוי, אינו תומך בשאילתות DoH.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.