Interesting inconsistency: Relay Selection ignores hosts file? Or just for fallback?

[straffin]

In trying to test a platform migration, we went through all the steps to move data from our old server to our new server then dropped a modified hosts file on a test client to make it think that every component server in our old BigFix was our new server. This worked fine except when it came to seeking our failback server. Even though x-bes-fallback-server is defined by hostname and that hostname is redirected in the hosts file (along with the root server and all relay servers), the relay selection process found the “real” address for the fallback server and connected to it instead.

I was able to bypass this by blocking that IP address in the test client’s firewall (HA! SO THERE!), but it’s odd that every other address redirected to the new server except the fallback.

[straffin]

(This won’t be a concern when we perform the “real” migration, as only the root server will be redirected via DNS and all existing relays–fallback included–will still be normally reachable as they will be communicating with the new server as well.)

[DerrickD]

Nice find.

I feel like I had success with the lastfallbacklist a few years back & hosts when I setup our environment, but maybe not. Making a mental note for the future

[atlauren]

Maybe the client uses a different DNS API for the fallback case?

[Aram]

I can double-check, but my guess is that OS-level DNS caching may have interfered here (i.e. I don’t believe we’re doing anything different for resolving fallback Relays).

[JasonWalker]

Ensure you have both the short hostname and the fully-qualified names for the last-fallback-relay name defined in the HOSTS file. When the client uses the HOSTS file for name resolution, it doesn’t apply the same ‘DNS Suffix Search Order’ logic defined on your network adapter as it would for a DNS query.

[straffin]

I feel like I had success with the lastfallbacklist a few years back

Oh, the setting works fine as is… it’s just that relay selection apparently works differently than the rest of the BigFix network processes, so something that works for the rest (hosts file) does not work for that process. The same is true for nslookup on Windows. It’s not a test of name-to-IP processing; it’s literally “name server lookup”, so it does not look at the hosts file at all.

[straffin]

OS-level DNS caching may have interfered

I’d swear that I performed at least one ipconfig /flushdns during my testing. I can try again…

[straffin]

Ensure you have both the short hostname and the fully-qualified names for the last-fallback-relay name defined

ORLY? We have so many subdomains in use here that we pretty much never do anything by short name.

/me goes to check…

Yeah… the fqdn in the x-bes-fallback-server masthead setting has a domain that’s not part of our DNS Suffix Search Order. There’d be no way for this computer to come up with that domain as an option for the shortname, so it can;t just be asking by short name(… can it? Networking is the are where I’m weakest.).