GEO Version 2.3.58.0 Release Notes
GEO Version 2.3.58.0 is a feature and bug fix update for the General Availability (GA) branch, made available on 27 October 2022. Please read the sections below before installing or upgrading to this release.
These notes list the fixes related directly to GEO product functionality. For a list of the new features, changes, and fixes in the base LMOS system on which GEO is running, please see the LoadMaster Release Notes for LMOS 7.2.58.0.
Upgrade Notes
Please see the LoadMaster Release Notes for LMOS 7.2.58.0 for a list of supported models for this release as well as for other upgrade notes, including how to validate the update image's digital signature.
Change Notices
GEO: Ignore ECS for Public/Private Decisions
Extended DNS (EDNS) Client Subnet (or ECS) is a GEO feature introduced in LMOS 7.2.57.0. This feature leverages a new field in Etended DNS packets that provides a client subnet value set by the client that provide better geographic location of the client compared to earlier versions of DNS without this capability.
Problem: When ECS in 7.2.57.0 is enabled, An incoming request that contains an ECS value always uses the ECS field value (and not the source IP of the request) to determine if a public or private IP should be returned to the client. With the default settings for Public and Private addresses, a private address is returned to the client that is likely not reachable from the client’s network.
Example: A client with a private IP address on Site A makes a DNS request to the local DNS server which forwards it to a public DNS server and then on to GEO. If all hops support ECS, then GEO sees the private IP address/subnet in the ECS field and so returns a private IP address. The client, however, will be unable to reach the expected application using that address.
Solution: The desired behavior is that GEO would instead use the source IP address of the request (which will be the last-hop public DNS server) to determine whether to return a public or private address.
- Change the ECS default behavior so that ECS is ignored and the source IP is checked when the public/private settings are not both set to “all sites”.
- Provide a switch (per FQDN) that allows the customer to opt-out of this new default behavior and honor the ECS instead.
The settings and corresponding behavior is summarized in the table below.
ECS Setting |
Public & Private Settings |
Public / Private Behavior Determined By … |
New FQDN Option Effect when Enabled |
OFF |
Any |
Request source IP |
When ECS is disabled, the new option is ignored. |
ON |
!= "all sites" |
Request source IP (ECS ignored) |
The new FQDN option overrides the behavior at left, so that the request ECS value is used. |
ON |
= "all sites" |
Request ECS value |
When the Public & Private settings are both “All Sites”, the new option is ignored. |
Issues Resolved
LM-1503 |
GEO: Fixed an issue with high CPU consumption on units with a free license and GEO enabled. |
LM-1134 |
GEO EDNS Client Subnet (ECS): It has been observed that with ECS enabled and an FQDN with the default private/public behavior selected, a private-network client may receive a non-routable DNS response in certain scenarios. This issue has ben addressed as described in the Change Notices section, above. |
LM-864 |
GEO Performance: Starting with LMOS 7.2.55.0, a performance degradation has been seen where Queries per Second (QPS) can be up to 50% lower than with version 7.2.54 and previous releases. This issue has been addressed and performance levels have been returned to the levels stated in the data sheet. |
New Known Issues
LM-1723 | GEO Partnering: There is a small window of time during a partner sync where concurrent changes on the partners may not be reflected on both systems. The only workaround is to repeat the modification. |
LM-1527 | GEO Cluster Checks: GEO cluster checks against LoadMasters configured in Clustering mode do not work. |
Existing Known Issues
LM-477 |
GEO Downgrade: When downgrading from a release that supports more than 64 IPs per FQDN to a release that only supports up to 64 IPs per FQDN, the GEO configuration may become corrupted if there is at least one FQDN in the configuration that contains more than 64 IP addresses. The corruption will likely be evidenced by errors in the UI/API when you list the FQDNs. To avoid this issue entirely, reduce the number of IPs per FQDN to 64 or less for all FQDNs defined before you downgrade. If you have already downgraded, you can switch back to the previous boot partition to go back to the newer release (which supports > 64 IPs per FQDN); you can then reduce the number of IPs as above and downgrade again. If neither of these options is possible, please contact Kemp Support who will consult with engineering on a solution to your issues. |
PD-19704 |
GEO Cluster Status: When adding a Cluster that is unavailable (DOWN) to a Site, the Site may reflect the Cluster's status as available (UP) for a short time before changing to DOWN. |
PD-19108 LM-127 |
GEO: Modifying an FQDN entry displays a spurious error on the system console, similar to the one shown below. The FQDN is modified properly. <FQDN>:794 Uncaught ReferenceError: disp_addrr_elements is not defined at <FQDN>:794 (anonymous) @ <FQDN>:794 |
PD-19093 LM-127 |
GEO: Cannot configure GEO into partnering mode unless there is at least one FQDN already defined. |
PD-18615 LM-134 |
GEO: No statistics (queries per second, etc.) are displayed for a site if the FQDN is configured to use the "All Available" Selection Criteria. |
PD-15633 |
GEO: If you add a Zone Name to GEO after you have created working FQDNs, GEO may no longer respond to queries for one or more of the FQDNs after the Zone Name is added. The workaround is to remove and then re-add the FQDNs that are no longer working. |
PD-9765 |
GEO: DNS TCP requests from unknown sources are not supported. |