02-20-2024 12:46 PM
We have a exp E cluster that I'd figure should be able to resolve their FQDN but it doesn't seem to be the case. in the utility i punch in one of the FQDNs from the clustering page (different node), and it doesn't resolve in the dns utility. THere's NAT in play and two interfaces.
Is this normal?
The cluster works but there are some complaints of sign-in issues.
02-20-2024 01:03 PM
On the E it is common to use external DNS servers. These can often not resolve the FQDN name to the IP of the internal interface of the E. To do that you can on the cluster configuration page configure specific names that are mapped to the internal IP of each node in the cluster. You can also on the DNS configuration page define domain name(s) that uses internal DNS servers, so that it can resolve the names used in the traversal zone.
02-20-2024 06:06 PM - edited 02-20-2024 06:14 PM
so the domain name used for the traversal has a different domain and is associated to the internal subdomain. Those seem to be fine.
The FQDNs mentioned in the cluster page has the mapping pointed using the public domain FQDNs to a private address (not the public IP). Since NAT is in play i guess it only matters so much - in that the IPs are kind of relative anyway, and the SRVs that most clients use would see the public IPs.
all that said, running the dns utility to verify public FQDNs from the clustering page fails (other node FQDNs). yet it still can form a cluster and show green checks. I guess what's on the clustering page isn't exactly a host file like mapping. /shrug.
02-20-2024 09:59 PM - edited 02-21-2024 12:42 AM
Cluster communication is done using the internal interface. That’s why you need to define the local mapping on the cluster configuration page so that the E can resolve the FQDN of itself and other cluster members to the internal IP.
If I understand correctly what you’re writing you don’t actually have any problem(s). You could have been somewhat clearer about that in your original post. That said the local mapping configuration on the cluster page has no relevance for actual general DNS lookups, those are only significant to the cluster function in Expressway.
02-21-2024 06:55 AM - edited 02-21-2024 06:57 AM
Thanks for your response. i thought i made the things clear in my first post when I stated that "in the utility i punch in one of the FQDNs from the clustering page (different node), and it doesn't resolve in the dns utility". I also stated "The cluster works but there are some complaints of sign-in issues". In my second post I elaborated on the point how the cluster was working (what i meant).
The fact it doesn't resolve the public FQDN of peers in the dns utility appears to be normal operation.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide