Windows – 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.