No DFS root referral before TreeConnect: domain-based namespace fails with STATUS_BAD_NETWORK_NAME

[cf-rafal]

Apart from #354, I have also other issue to report or maybe this is a feature request? Not sure yet :)

Environment

• SMBLibrary 1.5.7.1
• Client: .NET 9 on Linux (mcr.microsoft.com/dotnet/aspnet:9.0-alpine-extra container, working DNS servers and DNS search domain configured)
• Server: Active Directory domain with a domain-based DFS namespace
• Transport: SMBTransportType.DirectTCPTransport
• Authentication: NTLM, domain account

Names below are example values:

Element	Example value
AD domain / namespace name	example.local
Namespace share	Namespace
Namespace server (physical)	nsserver.example.local
DFS link (first path segment)	Link
Referral target server / share	FS01 / Data$

Summary

In one sentence: a domain-based DFS namespace cannot be connected at all, because SMBLibrary sends TreeConnect directly instead of first resolving the DFS root referral.

Why:

1. \\example.local\Namespace is not a real share on any host. The first path component is the AD domain name, and the namespace exists only as a DFS root referral served by domain controllers.
2. The Windows client therefore asks a DC for a root referral before the tree connect, learns which physical servers host the namespace, connects to one of them and tree connects there.
3. SMBLibrary skips that step: SMB2Client.TreeConnect("Namespace") goes straight to whatever host Connect(...) was called with, and the server answers STATUS_BAD_NETWORK_NAME.
4. There is no public API and no internal code path performing the root referral, so the failure occurs before SMB2DfsFileStore could even be created.

Steps to reproduce

1. Create a domain-based DFS namespace \\example.local\Namespace hosted on nsserver.example.local,
   with a link Link pointing to \\FS01\Data$.
2. From a client with working DNS for example.local:

var client = new SMB2Client();
var connected = client.Connect("example.local", SMBTransportType.DirectTCPTransport); // true
var login = client.Login("EXAMPLE", "svc_account", "***");                            // STATUS_SUCCESS

var store = client.TreeConnect("Namespace", out var status);
Console.WriteLine(status);   // STATUS_BAD_NETWORK_NAME, store == null

Actual result

Connect  -> true
Login    -> STATUS_SUCCESS
TreeConnect("Namespace") -> STATUS_BAD_NETWORK_NAME

Expected result

Either

• TreeConnect transparently resolves the DFS root referral for \\example.local\Namespace (ask a DC / the connected host for a DFS_REFERRAL of the root path, pick a namespace server, connect there and tree connect to the namespace share), or
• a documented public API is exposed so the caller can perform the root referral itself and connect to the resolved namespace server.

Notes

Connecting to the namespace server's own host name (Connect("nsserver.example.local") + TreeConnect("Namespace")) makes the tree connect succeed, but that is a workaround: it pins the client to one specific namespace server and loses the high availability the domain-based namespace exists for.

Impact

Domain-based DFS namespaces - the standard, highly available deployment form - cannot be accessed at all. Callers must hard-code a specific namespace server, which loses high availability and defeats the purpose of a domain-based namespace.

[TalAloni]

@cf-rafal Thanks, but I'm not sure that handling this virtual domain name falls within the scope of SMBLibrary (communicating with the domain controller is certainly outside the scope) I think it's up to the client to provide workable hostname / IP address
I am willing to extend the client so it would be possible to provide custom name resolution, e.g.:
public virtual IPAddress GetHostAddress()
Which will be called by the Connect method - does that work for you?

@jahales What do you think?

[jahales]

@TalAloni In this case Connect("example.local") and Login already succeed. The failure is at TreeConnect, so name resolution isn't the gap; what's missing is the root referral, which is just FSCTL_DFS_GET_REFERRALS on IPC$ over the session we already have (the same IOCTL DfsReferralHelper already uses for link referrals), so no DC-specific protocol is involved.

I'll take a closer look after I get my lab set up again.

[TalAloni]

Thanks