So, my problem is not that something does not work. But that it works, and I cannot figure out why.
Short version: I am able to access \\mydomain\MyDFSRoot even though netbios/LLMNR is off, and DNS-entry mydomain.mydomain.locale does not exist. I cannot fathom why.
- AD-Forest/Domain: MyDomain.locale
- DFS-Namespace: MyDomain.locale/MyDFSRoot (v2)
- Forest/Domain Level: 2008R2
- DC1 (Domain Controller - WS2019)
- SRV (DFS Namespace server - WS2019)
- CLI (Client, Windows 10 1903) (There are no other computers in this network)
- LLMNR - Off via GPO
- Netbios Node-Type P-Node via GPO
- NO WINS available nor configured
- Netbios over TCP/IP disabled on network adapters
- SMBv1 disabled via GPO (No Computer Browser-service is running)
- DFS-Configuration set to use FQDN on both DC and DFSn-Server (but does not seem to matter)
- DNS suffix search list is default (mydomain.locale)
- CLI is separated in its own network (vswitch and routed to DC/SRV), this to avoid any broadcast packets
- No external traffic from the network nor any external DNS configuration
- WORKS: All DFSN-paths (\mydomain(sysvol|netlogon|mydfsroot)
- NOT WORKS: A shared folder on the DC \mydomain\dcsharedfolder
- DELAY: If I boot the Client disconnected from the network, log on, enable networking and test.. it might take seconds/minutes before it works.
- LLMNR/Netbios/BROWSER is OFF: I have captured all traffic, there is no trace of these protocols
- ipconfig /flushdns, dfsutil cache * flush etc is heavily used without seeming to have any effect
Update: Possible Answer
It seems I have located the network packet that will trigger the shortname to work. At some point a packet of type
SMB2 will be sent
Request [FSCTL_DFS_GET_REFERRALS], FILE: (Note there is no file path present)(Wireshark filter
smb2.ioctl.function == 0x00060194). In turn I get the following response from the domain controller:
Referrals Referral Version: 3 Size: 18 Server Type: Non-root targets returned (0) Flags: 0x0002, NameListReferral TTL: 600 Domain Offset: 36 Number of Expanded Names: 0 Expanded Names Offset: 0 Domain Name: \MYDOMAIN Referral Version: 3 Size: 18 Server Type: Non-root targets returned (0) Flags: 0x0002, NameListReferral TTL: 600 Domain Offset: 34 Number of Expanded Names: 0 Expanded Names Offset: 0 Domain Name: \MYDOMAIN.LOCALE
Now the Microsoft Article "How DFS Works" has the following quote:
"Any UNC request on the client comes to DFS first before any of the network redirectors. DFS checks its domain cache to determine whether the name is a domain name"
However, it also states that the MUP Cache must know about the path beforehand. This might explain why it initially does not work, but works 'if I wait a bit'. Checking the DFS domain cache before it starts working:
[*] [*][MYDOMAIN] [*][mydomain.locale] [+][mydomain.locale] [+TESTDC.pertra.locale]
And after it starts working:
[*][TESTDC.mydomain.locale] [*][MYDOMAIN] [*][mydomain.locale] [+][mydomain] [+TESTDC] AccessStatus: 0 [+][mydomain.locale] [+TESTDC.mydomain.locale]
The entry with [+] in front should be a referral, while [*] is "received from the workstation service". In this scenario this would imply that this works now because I have gotten a referral for the path, which is probably because something else (GPO I am thinking) access the DFS-root.
EDIT2: I checked the PID of the process that sent the query and it was the workstation service.