Add/Modify an FQDN

Selection Criteria

The selection criterion used to distribute the resolution requests can be selected from this drop-down list. The Selection Criteria available are:

• Round Robin - traffic distributed sequentially across the server farm (cluster), that is, the available servers.
• Weighted Round Robin – Incoming requests are distributed across the cluster in a sequential manner, while taking account of a static “weighting” that can be pre-assigned per server.
• Fixed Weighting - the highest weight Real Server is used only when other Real Server(s) are given lower weight values. If multiple Real Servers share the same highest weight, the system distributes traffic among them in a round‑robin manner until a server with a higher weight becomes available.
• Real Server Load - LoadMaster contains logic which checks the state of the servers at regular intervals and independently of the configured weighting.
• Proximity – traffic is distributed to the closest site to the client. When using Proximity scheduling, new public sites are automatically mapped to geographic coordinates based on the GEO database. New private sites are mapped to 0º0'0" and function as expected. This coordinate should be overridden with accurate values to ensure correct balancing. The position of the client is determined by their IP address.

• Location Based - traffic is distributed to the closest site to the client. The positioning of the sites is set by inputting the location of the site (country or continent) during setup. The position of the client is determined by their IP address. If there is more than one site with the same country code, requests are distributed in a round robin fashion to each of the sites.
• All Available – returns all possible healthy targets for an A, AAAA or ANY query request. The contents of the returned list is also controlled by the Public Requests and Private Requests settings:

• For Public Sites Only the list can only contain public addresses. Likewise, for Private Sites Only the list can only contain private addresses.

• For Prefer Public the list only contains public addresses, unless no public addresses are available – in which case the list contains private addresses (if any are available). Likewise, for Prefer Private the list only contains private addresses, unless no private addresses are available – in which case the list contains public addresses (if any are available).

• For All Sites the list contains all available addresses

The purpose of this is to provide a list of preferred addresses, if they are available. Otherwise, provide a list of non-preferred addresses as a failback measure for improved availability.

Fail Over

The Fail Over option is only available when the Selection Criteria is set to Location Based. When the Fail Over option is enabled, if a request comes from a specific region and the target is down, the connection will fail over and be answered with the next level in the hierarchy. If this is not available, the connection is answered by the nearest (by proximity) target. If this is not possible, the target with the lowest requests are picked. For example, if a request from Ireland is received, but the site assigned to Ireland is unavailable, a site assigned to Europe is selected. If the site assigned to Europe is also unavailable, a site assigned to Everywhere is selected. If this too is unavailable, the site with the lowest requests of the available sites in the same continent is selected using the round robin method. The Fail Over setting affects all targets.

Public Requests & Private Requests

The Isolate Public/Private Sites setting has been enhanced in version 7.1-30. The checkbox has been migrated to two separate dropdown menus to allow more granular control of DNS responses. Existing behavior has been preserved and is migrated from your current setting, ensuring that no change in DNS responses is experienced.

These new settings allow administrators finer control of DNS responses to configured FQDNs. Administrators may selectively respond with public or private sites based on whether the client is from a public or private IP. For example, administrators may wish to allow only private clients to be sent to private sites.

The following table outlines settings and their configurable values:

ECS Public/Private Request Checking

In LoadMaster firmware version 7.2.58, a new check box called ECS Public/Private Request Checking was added to the modify FQDN screen.

By default, the ECS Public/Private Request Checking check box is disabled. When disabled, the device uses the client request’s source IP address to determine if the request is public or private. When enabled, the device uses the EDNS Client Subnet (ECS) value instead (if one is received) to determine if the request is public or private. This option becomes inactive in either of the following conditions:

• The EDNS Client Subnet (ECS) option (in Global Balancing > Miscellaneous Params) is disabled.

• The Public Requests and Private Requests values are both set to All Sites.

The following table summarizes the behavior depending on the configuration:

Site Failure Handling

The default is for failover to occur automatically. However, in certain circumstances, for example in a multi-site Exchange 2010 configuration, this may not be optimal and different behaviour may be required. Failure Delay is set in minutes. If a Failure Delay is set, a new option called Site Recovery Mode becomes available.

Site Recovery Mode

The Site Recovery Mode options only become available when a Failure Delay is set. If an endpoint fails the health check it is marked as "failing". After the Failure Delay time ends, the endpoint is marked as down. The Site Recovery Mode determines what recovery options are implemented when a failed site recovers.

• Automatic - when the endpoint recovers (passes the health check), the endpoint is marked as up and the LoadMaster automatically makes the endpoint available for use

• Manual - upon failure, the endpoint is administratively disabled and is not available for use until you click Enable for the relevant endpoint and the health check is passing.

Enable Local Settings

Selecting this option will display two additional fields – TTL and Stickiness. These can be set on a per-FQDN basis or globally. To set them for an FQDN – enable local settings and configure them as needed. The per-FQDN settings will default to the value of the global settings when the FQDN is created.

TTL

The Time To Live (TTL) value dictates how long the reply from the GEO LoadMaster can be cached by other DNS servers or client devices. The time interval is defined in seconds. This value should be as practically low as possible. The default value for this field is 10. Valid values range from 1 to 86400.

Stickiness

‘Stickiness’, also known as persistence, is the property that enables all name resolution requests from an individual client to be sent to the same resources until a specified period of time has elapsed. For further information on Stickiness, refer to the GEO Sticky DNS Feature Description.

Unanimous Cluster Health Checks

If this option is enabled, if any IP addresses fail health checking - other FQDN IP addresses which belong to the same cluster are marked as down. When Unanimous Cluster Health Checks is enabled, the IP addresses which belong to the same cluster within a specific FQDN are either all up or all down. For example, example.com has addresses 172.21.58.101, 172.21.58.102 and 172.21.58.103 which all belong to cluster cl58:

• If 172.21.58.101 fails, the unanimous policy forces 172.21.58.102 and 172.21.58.103 down as well.
• When 172.21.58.101 comes back, the unanimous policy brings back 172.21.58.102 and 172.21.58.103 along with it.

So, at any given time – either all three addresses are available or all three addresses are down.

The same approach applies for site failure mode with manual recovery. Manual recovery causes a failed address to be disabled, so the administrator can re-enable it after fixing the problem. When Unanimous Cluster Health Checks is enabled, all three addresses are disabled.

The unanimous policy ignores disabled addresses. So, if you know that an address is down, and for whatever reason you want to continue using the other addresses that belong to the same cluster, you can disable the failed address and the unanimous policy will not force down the other addresses with it.

When Unanimous Cluster Health Checks are enabled, some configuration changes may cause FQDN addresses to be forced down or brought back up. For example, if an address is forced down and you remove it from the cluster while the unanimous policy is in effect, the address should come back up. Similarly, if you add an address to a cluster where the unanimous policy is in effect and one of the addresses is down, the new address should be forced down. This change may not occur immediately, but it should happen the next time health checking occurs.

If there are addresses with the Checker set to None combined with addresses that have health checking configured – addresses with no health checking will not be forced down, but they can be forcibly disabled if the Site Recovery Mode is set to Manual. For example, say there are three addresses:

• 172.21.58.101 with a Checker of Cluster Checks
• 172.21.58.102 with a Checker of Cluster Checks
• 172.21.58.103 with a Checker of None

If site failure handling is off or automatic, the failure of 172.21.58.101 causes 172.21.58.102 to be forced down, but 172.21.58.103 remains up. The rationale is that if you do not want health checking on 172.21.58.103 then it should remain up.

However, if the Site Recovery Mode is set to Manual, failure of 172.21.58.101 causes both 172.21.58.102 and 172.21.58.103 to be disabled, along with 172.21.58.101. For site recovery – all addresses are disabled, even the ones with no health checking configured. This is to keep traffic away from the problem data center until the system administrators fix it. This does not conflict with having addresses with no health checking because you can have an address that is up but disabled.

IP Addresses

To create an IP address for an FQDN, enter the IP address of the domain in the New IP address text box.

Cluster

If needed, the cluster containing the IP address can be selected.

Checker

This defines the type of health checking that is performed. The options include:

• None: This implies that no health check is performed to check the health status of the machine (IP address) associated to the current FQDN.

• ICMP Ping: This tests the health status by pinging the IP address.

• TCP Connect: This will test the health by trying to connect to the IP address on a specified port.

• Cluster Checks: When this is selected, the health status check is performed using the method associated with the selected cluster.

  Note: If there are no clusters configured, the Cluster Checks value is grayed out.

• HTTP/HTTPS: In LoadMaster firmware version 7.2.53, support was added to perform Layer7 (L7) HTTP and HTTPS health checks on back-end servers within GEO "sites" that are not handled from the LoadMaster for application delivery. In other words, site health determination can be enhanced directly from GEO by checking the health of back-end servers that are not being health-checked by LoadMaster.

  Note: HTTP/1.1 is supported (HTTP/1.0 is not supported).

  

  The available options that appear when HTTP or HTTPS is selected as the Checker are as follows:

  • Address: Set the address and port to use to health check the IP address. The default port is 80 when HTTP is selected and 443 when HTTPS is selected.

  • URL: By default, the health checker tries to access the URL forward slash (/) to determine if the machine is available. You can specify a different URL here.

  • The URL must begin with a forward slash (/).

  • The URL cannot contain http: or https:.

  • The URL can be a maximum of 127 characters.

  • If the URL is left blank, a forward slash (/) is sent by default.

  • Status Codes: A space-separated list of HTTP and HTTPS status codes that should be treated as successful when received from the server.

  • Codes must be between 300-599.

  • There is a maximum of 32 codes.

  • There is a limit of 127 characters.

  • Host: A hostname can be supplied in the request to the server. If this is not set, the server address is sent as the host.

  • There is a limit of 127 characters.

  • Allowed characters: alphanumerics and -._:

  • Method: When accessing the health check URL, the system can use the GET, the POST, or the HEAD method. If POST is selected, another field appears to set the POST data. Up to 2047 characters of POST data can be passed to the server.

  • Show/Hide Custom Headers: When you click the Show/Hide Custom Headers option, it displays the custom headers that are to be part of the health check request.

  • Header: Add a header to be part of the health check request.

    • There is a limit of 255 characters for the total check headers string. The first text box allows you to specify a key for the custom header. The second text box allows you to specify a value for the custom header. The value has a maximum length of 128 characters.
    • Allowed characters for header keys: alphanumerics and _-
    • Allowed characters for header values: alphanumerics and _-.+=;()
  Note: You can specify a maximum of four custom headers.

  The status of the health check displays in the Availability column.

  Note: It is not possible to override the GEO health checks on a per-FQDN basis (like you can with Virtual Services).
  Note: The Check Parameters in Rules & Checking > Check Parameters do not apply to GEO. Only the settings in Global Balancing > Miscellaneous Params apply to GEO.

For further information regarding health checks, refer to the GEO Feature Description.

Parameters

The parameters for the Selection Criteria are described and can be changed within this section. The parameters differ depending on the Selection Criteria in use, as described below:

• Round Robin – no parameters available
• Weighted Round Robin – the weight of the IP address can be set by changing the value in the Weight text box and clicking the Set Weight button
• Fixed Weighting – the weight of the IP address can be set in the Weight text box
• Real Server Load – the weight of the IP address can be set in the Weight text box and the Virtual Service which is measured can be chosen from the Mapping field
• Proximity – the physical location of the IP address can be set by clicking the Edit button
• Location Based – the locations associated with the IP address can be set by clicking the Show Locations button

Delete IP address

An IP address can be deleted by clicking the Delete button in the Operation column of the relevant IP address.

Additional Records

In LoadMaster firmware version 7.2.53, a new Additional Records section was added to allow you to configure records for a specific FQDN. You can add, modify, or delete a additional TXT, CNAME, and MX records to an FQDN. These record types allow you to communicate domain resources to clients:

• TXT: A TXT (text) record is essentially unformatted data that can be used for almost any purpose, but typically contains information to be consumed by clients to classify a domain in some way, provide details about a domain, or specify resources available within a domain.

• CNAME: A CNAME record points a DNS name (such as www.example.com) to another DNS name (such as lb.example.com). This is typically used to define a website alias.

  If you select CNAME from the Type drop-down list, the NAME and RDATA fields become available. By default, the RDATA field is set with the FQDN name unless some other value is entered in the field. You can add an FQDN that is unrelated to the FQDN to which the records are being added, if desired.

• MX: A mail exchanger (MX) record specifies the mail server responsible for accepting email messages on behalf of a domain name.

For more information and instructions, refer to the GEO Feature Description.

Delete FQDN

An FQDN can be deleted by clicking the Delete button at the bottom of the Modify (Configure) FQDN screen.