Разрешение пространства имен DFS без netbios - почему это работает

Итак, моя проблема не в том, что что-то не работает. Но это работает, и я не могу понять, почему.

Укороченная версия: Я могу получить доступ к \\ mydomain \ MyDFSRoot, даже если netbios / LLMNR выключен, а DNS-запись mydomain.mydomain.locale не существует. Я не могу понять почему.

подробности

• Лес AD / Домен: MyDomain.locale
• Пространство имен DFS: MyDomain.locale / MyDFSRoot (v2)
• Уровень леса / домена: 2008R2

Тестовые компьютеры:

1. DC1 (контроллер домена - WS2019)
2. SRV (сервер пространства имен DFS - WS2019)
3. CLI (клиент, Windows 10 1903) (других компьютеров в этой сети нет)

Конфиг:

• LLMNR - отключено через GPO
• Netbios Node-Type P-Node через GPO
• WINS недоступен и не настроен
• Netbios через TCP / IP отключен на сетевых адаптерах
• SMBv1 отключен через GPO (служба браузера компьютера не запущена)
• DFS-Configuration настроен на использование полного доменного имени как на DC, так и на DFSn-Server (но это не имеет значения)
• Список поиска DNS-суффиксов по умолчанию (mydomain.locale)
• Интерфейс командной строки разделен в своей собственной сети (vswitch и направлен на DC / SRV), чтобы избежать любых широковещательных пакетов.
• Нет внешнего трафика из сети или какой-либо внешней конфигурации DNS

Наблюдения:

• РАБОТАЕТ: Все DFSN-пути (\ mydomain (sysvol | netlogon | mydfsroot)
• НЕ РАБОТАЕТ: общая папка в DC \ mydomain \ dcsharedfolder
• ЗАДЕРЖКА: Если я загружаю клиента, отключенного от сети, захожу в систему, включаю сеть и тестирую ... это может занять секунды / минуты, прежде чем он заработает.
• LLMNR / Netbios / BROWSER выключен: я захватил весь трафик, этих протоколов нет
• ipconfig / flushdns, dfsutil cache * flush и т. д. широко используются без какого-либо эффекта

Обновление: возможный ответ Кажется, я обнаружил сетевой пакет, который запускает короткое имя. В какой-то момент пакет типа SMB2 будет отправлено Request [FSCTL_DFS_GET_REFERRALS], FILE: (Обратите внимание, что путь к файлу отсутствует) (фильтр Wireshark smb2.ioctl.function == 0x00060194). В свою очередь, я получаю следующий ответ от контроллера домена:

            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

Теперь статья Microsoft «Как работает DFS» есть следующая цитата:

«Любой запрос UNC на клиенте сначала поступает в DFS перед любым из сетевых перенаправителей. DFS проверяет свой кеш домена, чтобы определить, является ли имя именем домена»

Однако в нем также указано, что кэш MUP должен знать путь заранее. Это может объяснить, почему изначально он не работает, но работает, «если я немного подожду». Проверка кеша домена DFS перед его началом работы:

[*][]
[*][MYDOMAIN]
[*][mydomain.locale]
[+][mydomain.locale]
        [+TESTDC.pertra.locale]

И после того, как он заработает:

[*][TESTDC.mydomain.locale]
[*][MYDOMAIN]
[*][mydomain.locale]
[+][mydomain]
        [+TESTDC] AccessStatus: 0
[+][mydomain.locale]
        [+TESTDC.mydomain.locale]

Запись с [+] впереди должна быть отсылкой, а [*] - «получено от службы рабочей станции». В этом сценарии это будет означать, что это работает сейчас, потому что я получил ссылку на путь, что, вероятно, связано с тем, что что-то еще (я думаю, GPO) обращается к корню DFS.

EDIT2: я проверил PID процесса, отправившего запрос, и это была служба рабочей станции.