[SERVER-34769] Server detects wrong FQDN when running Windows on AWS Created: 01/May/18  Updated: 27/Oct/23  Resolved: 19/Jun/18

Status: Closed
Project: Core Server
Component/s: Networking
Affects Version/s: 3.6.4
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: David Golub Assignee: Andrew Morrow (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Steps To Reproduce:

Launch a Windows host of type windows-64-vs2015-small. Download and install MongoDB onto the VM and start a MongoDB process. From the Mongo shell, run the following command:

db.runCommand({ serverStatus: 1, advisoryHostFQDNs: 1 })

The advisoryHostFQDNs field in the resulting document will contain the incorrect hostname.

Participants:

 Description   

When running on a Windows box on AWS, the server will detect an FQDN of the form WIN-T1NSTPV2UDM.ec2.internal, which is not correct. The correct hostnames for such an AWS box are WIN-T1NSTPV2UDM and ip-10-122-16-56.ec2.internal.

This bug is blocking us from being able to run our E2E tests on Windows on Evergreen, so please prioritize.

CC justin.moses mark.benvenuto



 Comments   
Comment by Andrew Morrow (Inactive) [ 15/May/18 ]

david.golub - Could you please clarify if the correct FQDNs are also returned, or are you only getting back the "invalid" one? Could you please post the complete contents of the advisoryHostFQDNs field returned by the runCommand posted above?

Comment by David Golub [ 14/May/18 ]

The failure is Windows-specific, and we're now beginning to run these tests on Windows, which we haven't done until now. It's not a regression.

Comment by David Golub [ 11/May/18 ]

The Monitoring Agent uses this field for discovery, so if it contains a hostname that can't be resolved, then it will attempt to monitor (and potentially automate) a host that doesn't exist and that it will never be able to reach. It's failing our tests, and I expect that it would cause problems for any customers who try to import an existing deployment if it's running on Windows hosts on AWS.

Comment by Andrew Morrow (Inactive) [ 11/May/18 ]

david.golub - Perhaps we should take a step back and discuss what it is that you hope to do with this data? I really wouldn't want to filter out things based on resolvability: the goal of the feature is to return more information, not less, with an understanding some or all of the returned information may be incorrect. In theory we could return some sort of data structure that annotated each returned FQDN with whether or not it succeeded at forward resolution, but that would be format change to the command response, and I'm not particularly interested in adding new options to this command or more complexity to what it already does. The information returned is advisory, not reliable, as the command states.

Comment by David Golub [ 10/May/18 ]

How about performing a DNS lookup to ensure that the generated FQDN actually can be resolved and, if not, omitting it? If it's handled that way, discovery should fall back to the ordinary hostname, which the Monitoring Agent should be able to see.

Comment by Mark Benvenuto [ 01/May/18 ]

This is a tricky issue given that this is how the Windows hosts are configured. We try to get the FQDN so we avoid returning any DNS name that lacks a period "." so we would drop the NETBIOS name if we got it. On EC2 Windows hosts, we see do return WIN-T1NSTPV2UDM.ec2.internal because this is the host name + DNS suffix configured for the machine. On Linux machines, the hostname is configured as "ip-10-122-18-157" which produces the FQDN "ip-10-122-18-157.ec2.internal" but not on Windows.

Detailed information:

> ipconfig /all
 
Windows IP Configuration
 
   Host Name . . . . . . . . . . . . : WIN-T1NSTPV2UDM
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : ec2.internal
                                       us-east-1.ec2-utilities.amazonaws.com
                                       compute-1.internal
 
Ethernet adapter Local Area Connection:
 
   Connection-specific DNS Suffix  . : ec2.internal
   Description . . . . . . . . . . . : AWS PV Network Device
   Physical Address. . . . . . . . . : 0E-04-19-6A-F1-EA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::a051:12ac:bc81:1b47%12(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.122.18.157(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Lease Obtained. . . . . . . . . . : Tuesday, May 01, 2018 4:13:19 PM
   Lease Expires . . . . . . . . . . : Tuesday, May 01, 2018 8:13:20 PM
   Default Gateway . . . . . . . . . : 10.122.16.1
   DHCP Server . . . . . . . . . . . : 10.122.16.1
   DHCPv6 IAID . . . . . . . . . . . : 220332043
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-7A-4A-73-0E-04-19-6A-F1-EA
   DNS Servers . . . . . . . . . . . : 10.122.0.2
   NetBIOS over Tcpip. . . . . . . . : Enabled
...

If we dump the information via Powershell, we see that this is simply the DNS configuration of the machine.

PS > foreach($a in [System.Net.Dns]::GetHostAddresses([System.Net.Dns]::GetHostName())) { echo $a; [System.Net.Dns]::GetHostByAddress($a) }
 
Address            :
AddressFamily      : InterNetworkV6
ScopeId            : 12
IsIPv6Multicast    : False
IsIPv6LinkLocal    : True
IsIPv6SiteLocal    : False
IsIPv6Teredo       : False
IsIPv4MappedToIPv6 : False
IPAddressToString  : fe80::a051:12ac:bc81:1b47%12
 
Exception calling "GetHostByAddress" with "1" argument(s): "The requested protocol has not been configured into the system, or no implementation for it exists"
 
Address            : 2635233802
AddressFamily      : InterNetwork
ScopeId            :
IsIPv6Multicast    : False
IsIPv6LinkLocal    : False
IsIPv6SiteLocal    : False
IsIPv6Teredo       : False
IsIPv4MappedToIPv6 : False
IPAddressToString  : 10.122.18.157
 
HostName    : WIN-T1NSTPV2UDM.ec2.internal
Aliases     : {}
AddressList : {10.122.18.157}

Generated at Thu Feb 08 04:37:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.