DFS Namespace Resolution without netbios - Why does it work

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.

Details

• AD-Forest/Domain: MyDomain.locale
• DFS-Namespace: MyDomain.locale/MyDFSRoot (v2)
• Forest/Domain Level: 2008R2

Test computers:

1. DC1 (Domain Controller - WS2019)
2. SRV (DFS Namespace server - WS2019)
3. CLI (Client, Windows 10 1903) (There are no other computers in this network)

Config:

• 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

Observations:

• 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.