I work in an environment with the following properties:
  domain name=CONTOSO
  dnsdomainname=contoso.corp
  domaincontroller=dc.contoso.corp
  domain-based dfs "root" name=\\contoso.corp\DFS
  dfs servers that actually implement the root dfs namespace:
	dfs1.contoso.corp
	dfs2.contoso.corp

On Windows, when I open \\contoso.corp\DFS, that kicks off:
* [presumably] a comparison with server (contoso.corp) against the dnsdomainname (contoso.corp)
* because they are equal
  * windows looks up the domain controller (as normal)
  * a connection is made to dc.contoso.corp, rather than contoso.corp (\\dc.contoso.corp\IPC$)
* a FSCTL_GET_DFS_REFERRALS is made to the domain controller, which returns the following referrers:
  * Path: \contoso.corp\DFS
    Alt Path: \contoso.corp\DFS
	Node: \dfs1.contoso.corp\dfs
  * Path: \contoso.corp\DFS
    Alt Path: \contoso.corp\DFS
	Node: \dfs2.contoso.corp\dfs
* Windows then begins a session to whichever of those referrers is marked active (currently it's dfs2), and the share is mounted, etc.

Using SMBCLIENT from samba-4.2.2, do_connect in clidfs.c attempts to connect to contoso.corp directly, rather than do the dnsdomainname compare and connect to the domain controller.  Because contoso.corp isn't a "real" host, there's no kerberos principal for that hostname, and the call to cli_session_setup() fails.

If at the top of the do_connect() function, after the server is parsed out from the function's input, I add:
	if (0 == strcmp(server, "contoso.corp")) {
		server="dc.contoso.corp";
	}
Then the initial connection is forced to be made to my domain controller, and the cli_check_msdfs_proxy() call near the bottom is made correctly to my domain controller, and I can connect to "smbclient -k //contoso.corp/dfs" just fine.


Likewise, it seems that Windows does a similar, additional check for server == domain, as \\contoso\DFS also works in my environment, but not with smbclient (unless I make a similar modification as above for "contoso" as well).

In short, it seems that Windows's domain-based DFS client treats both the dnsdomainname(s) (or maybe the REALM name, for me they are the same, but different case) and the domain name as references for the client's domain controller of choice.  Smbclient 4.2.2 appears to not do this.