Jira (FACT-1142) Facter FQDN resolution is incorrect on Windows

Ethan Brown (JIRA)

unread,

Jul 22, 2015, 6:06:07 PM7/22/15

to puppe...@googlegroups.com

Ethan Brown created an issue

Facter /

FACT-1142

Facter FQDN resolution is incorrect on Windows

Issue Type:	Bug
Affects Versions:	FACT 3.0.1
Assignee:	Unassigned
Components:	Windows
Created:	2015/07/22 3:05 PM
Priority:	Normal
Reporter:	Ethan Brown

Native Facter has followed the previous model on Windows when resolving network facts. Unfortunately, it would seem that the method of calculating FQDN might be errant.

FQDN Is currently a combination of hostname + domain:

hostname is retrieved by GetComputerNameEX - in networking_resolver with the flag ComputerNameDnsHostname, which should be appropriate - note that Facter 2.x used the hostname.exe command which I believe called GetComputerName, which returns a NetBIOS name
domain still uses an older mechanism of registry spleunking with a fallback to the DnsSuffix returned from GetAdaptersAddresses at https://github.com/puppetlabs/facter/blob/ebf3003a2492cd0ac2595d7c24be9ce7f46f872e/lib/src/facts/windows/networking_resolver.cc#L202

FQDN is later calculated by concatenating these 2 pieces of data at https://github.com/puppetlabs/facter/blob/89550ef649866692afff9c7bd94044fe6c67cf4c/lib/src/facts/resolvers/networking_resolver.cc#L48-L51

This might be correct, but a better way of doing this is likely to use GetComputerNameEx with a COMPUTER_NAME_FORMAT of ComputerNameDnsFullyQualified, given the registry parsing / interface spelunking is more complicated than necessary.

When I first ran across this code, I didn't realize that Native Facter was at least using the DNS host name resolution in GetComputerNameEx, and had suggested that Facter might want to use the Winsock gethostname function. This was a bad suggestion given GetComputerNameEx can handle DNS hostnames, and given gethostname may return a hostname or FQDN based on implementation details, which make it a less attractive solution.

Not sure if it's worth changing Facter 2.x, which uses Netbios name + DNS domain name to calculate a FQDN. That might work under a lot of circumstances, but is not accurate, given Netbios names do not have to match DNS hostnames on Windows.

Add Comment

This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c)

Michael Smith (JIRA)

unread,

Jul 22, 2015, 6:10:06 PM7/22/15

to puppe...@googlegroups.com

Michael Smith updated an issue

Facter /

FACT-1142

Facter FQDN resolution is incorrect on Windows

Change By:	Michael Smith
Fix Version/s:	FACT 3.x

Add Comment

Michael Smith (JIRA)

unread,

Jul 22, 2015, 6:10:09 PM7/22/15

to puppe...@googlegroups.com

Michael Smith commented on

FACT-1142

Re: Facter FQDN resolution is incorrect on Windows

My reading is that this was also broken in Facter 2.x, so scheduling for after we finish off adding other platforms.

Add Comment

Ethan Brown (JIRA)

unread,

Jul 22, 2015, 6:16:06 PM7/22/15

to puppe...@googlegroups.com

Ethan Brown updated an issue

Facter /

FACT-1142

Facter FQDN resolution is incorrect on Windows

Change By:	Ethan Brown

Native Facter has followed parts of the previous model on Windows when resolving network facts. Unfortunately, it would seem that the method of calculating FQDN might be errant.

FQDN Is currently a combination of hostname + domain:

* hostname is retrieved by [GetComputerNameEX|https://msdn.microsoft.com/en-us/library/windows/desktop/ms724301(v=vs.85).aspx] - in [networking_resolver|https://github.com/puppetlabs/facter/blob/0f2896b5224c22d0b2a708ddbc362322087d194a/lib/src/facts/windows/networking_resolver.cc#L43] with the flag {{ComputerNameDnsHostname}}, which should be appropriate - note that Facter 2.x used the {{hostname.exe}} command which I believe called {{GetComputerName}}, which returns a NetBIOS name
* domain still uses an [older mechanism of registry spleunking|https://github.com/puppetlabs/facter/blob/ebf3003a2492cd0ac2595d7c24be9ce7f46f872e/lib/src/facts/windows/networking_resolver.cc#L158-L159] with a fallback to the {{DnsSuffix}} returned from {{GetAdaptersAddresses}} at https://github.com/puppetlabs/facter/blob/ebf3003a2492cd0ac2595d7c24be9ce7f46f872e/lib/src/facts/windows/networking_resolver.cc#L202

FQDN is later calculated by concatenating these 2 pieces of data at https://github.com/puppetlabs/facter/blob/89550ef649866692afff9c7bd94044fe6c67cf4c/lib/src/facts/resolvers/networking_resolver.cc#L48-L51

This might be correct, but a better way of doing this is likely to use {{GetComputerNameEx}} with a {{COMPUTER_NAME_FORMAT}} of {{ComputerNameDnsFullyQualified}}, given the registry parsing / interface spelunking is more complicated than necessary.

When I first ran across this code, I didn't realize that Native Facter was at least using the DNS host name resolution in {{GetComputerNameEx}}, and had suggested that Facter might want to use the Winsock [gethostname|https://msdn.microsoft.com/en-us/library/windows/desktop/ms738527(v=vs.85).aspx] function. This was a bad suggestion given {{GetComputerNameEx}} can handle DNS hostnames, and given {{gethostname}} may return a hostname or FQDN based on implementation details, which make it a less attractive solution.

Not sure if it's worth changing Facter 2.x, which uses Netbios name + DNS domain name to calculate a FQDN. That might work under a lot of circumstances, but is not accurate, given Netbios names do not have to match DNS hostnames on Windows.