Global server load balancing

HAProxy ALOHA can serve as an authoritative Domain Name System (DNS) server in a limited capacity, specifically for implementing global server load balancing (GSLB). This lets you respond to DNS queries with the IP address(es) assigned to a datacenter that is the best match for the end user, such as the one that is geographically closest to them. Or, you can configure DNS to return the address of a secondary datacenter if the primary becomes inaccessible.

By providing GSLB, you can fulfill the following use cases:

• DNS round-robin: Distributes traffic between all datacenters in multiple locations.

• Failover: Send all traffic to a primary datacenter by returning its IP address(es) in DNS responses, but direct traffic to a secondary datacenter if the primary becomes inaccessible.

• Geolocation-based DNS: GSLB enhances functionalities of the DNS naming system by distributing network traffic across servers located in multiple locations. It can detect users’ locations and route traffic to the nearest datacenter to lower latency.

The load balancer continuously monitors the health of your datacenter IP addresses so that it can remove them from the DNS responses if they become unavailable. It reroutes the traffic to another available datacenter by changing DNS records dynamically.

How global server load balancing works Jump to heading #

First, consider how DNS typically works. DNS servers translate human-readable domain names (for example, www.example.com) to numeric IP addresses (for example, 10.10.0.5).

1. A client’s web browser queries the DNS server to get the IP address of a website.
2. The DNS server returns an IP addresses.
3. The browser connects to the website through its IP address.

Global server load balancing offers a DNS server a smarter way to choose which IP address it should return. It can take into account where the client is located in the world and the health of each datacenter before selecting the IP address to return in a DNS response. This allows it to send a client to the best match.

1. A client’s web browser queries the DNS server to get the IP address of a website.
2. HAProxy ALOHA, acting as the DNS server returns an IP address, but one based on the geographic IP location of the client and/or the health of the datacenter.
3. The client gets the best possible user experience by connecting to the website through the IP address of the datacenter that is the best match for them.

HAProxy ALOHA polls the servers to make sure they remain responsive. If they stop responding, then the affected IP addresses will be removed from the list of valid responses HAProxy ALOHA will return to clients.

One caveat: GSLB uses DNS to route clients, and DNS responses are often cached. If a datacenter becomes unavailable, clients will continue to use the cached IP address returned in the original DNS response until the cached response expires. However, it remains an effective strategy overall for distributing traffic across datacenters.

Configure the GSLB service Jump to heading #

1. In the Services tab, click gslb setup.

   

2. Optional: By default, the GSLB service listens for DNS queries at the addresses 0.0.0.0:53 and 127.0.0.1:153. To change this, set the listen directive to the IP address and port at which the GSLB service should listen for DNS queries.

3. To enable the service to start automatically when the appliance boots, delete the no autostart line, click OK and then Close.

4. To make the changes persist after a reboot, go to the Setup tab and click Save within the Configuration section.

Scenarios Jump to heading #

In the following sections, we describe how to configure the GSLB service for several scenarios.

DNS round-robin load balancing Jump to heading #

You can make the GSLB service return several IP addresses from healthy datacenters in a round-robin weighted fashion.

1. In the Services tab, click [advanced mode]. Then edit the gslb configuration.

   

   The current configuration displays.

2. Edit configuration:

   • Replace the domain example.com with your domain name and record entries.
   • Add a new list record to the zone section. A record of type list is a dynamic record followed by list of space-separated answer-list names.
   • Create answer-list sections that set IP addresses to return in a round-robin rotation. Optionally, add different weights to the answer-record lines.

   zone example.com
     ttl 10
     # ORIGIN records
     record @ SOA ns1.example.com hostmaster.example.com 1 86400 3600 3600 3600 60
     record @ NS  ns1.example.com
     record @ ttl 3600 MX 100 mail1.example.com
     
     # Static records
     record ns1   ttl 20 A 10.0.0.1
     record mail1 ttl 20 A 10.0.0.2
     
     # Dynamic records
     record www   ttl 20 list dc1
   
   answer-list dc1
     method single-rr
     option httpchk
     http-check connect
     http-check send uri /health.html hdr host www.example.com
     answer-record srv1 20.0.0.1 weight 10
     answer-record srv2 20.0.0.2 weight 20

   zone example.com
     ttl 10
     # ORIGIN records
     record @ SOA ns1.example.com hostmaster.example.com 1 86400 3600 3600 3600 60
     record @ NS  ns1.example.com
     record @ ttl 3600 MX 100 mail1.example.com
     
     # Static records
     record ns1   ttl 20 A 10.0.0.1
     record mail1 ttl 20 A 10.0.0.2
     
     # Dynamic records
     record www   ttl 20 list dc1
   
   answer-list dc1
     method single-rr
     option httpchk
     http-check connect
     http-check send uri /health.html hdr host www.example.com
     answer-record srv1 20.0.0.1 weight 10
     answer-record srv2 20.0.0.2 weight 20

   The answer-list section syntax is as follows:

   Directive	Description
   method	Set the single-rr parameter.
   option	Specify httpchk to monitor the health of servers.
   http-check	Set any relevant health check parameters.
   answer-record	Enter any number of answer-record directives along with the corresponding IP addresses. Weights determine how often a particular IP address will be returned, with higher weights being chosen more often. By specifying method single-rr, HAProxy ALOHA alternates which IP for a datacenter it sends to clients in order to distribute traffic across all servers. In that case, the odds of a server’s IP being returned is server weight / sum of all server weights.

3. Save your configuration, close the configuration editor, then apply your changes on the gslb line in the Services tab.

   

4. To make your changes persistent after a reboot, click the Setup tab. Then click Save under Configuration.

Geolocation-based load balancing Jump to heading #

You can deliver content to users based on their geographic location. HAProxy ALOHA with global server load balancing enabled returns the IP address from the closest healthy datacenter or server. To use this feature, you will need to download a GeoIP database from MaxMind.

For example, you can:

• comply with regulations governing the location of data storage.
• reduce latency.
• deliver content that is tailored to users’ country and native language.

To enable geolocation-based load balancing:

1. If your HAProxy ALOHA host is a virtual appliance instead of hardware, you need to create an additional partition large enough to contain the GeoIP databases.

   • Attach a new hard disk to the virtual machine. It should be 30 GB or larger.

     • Microsoft Hyper-V
     • VMware vSphere

   • Power on your HAProxy ALOHA Virtual Appliance.

   • Log in to your HAProxy ALOHA web UI as an administrator. The web UI runs at port 4444.

   • Select the Tools tab, then edit the file /etc/config.rc through the File Manager. Add the following directives at the end of the service system section, then click Save:

     app_auto_mount
     app_auto_format
     app_device_size 30000000000

     app_auto_mount
     app_auto_format
     app_device_size 30000000000

     where:

     • app_auto_mount automatically mounts the partition on /app.
     • app_auto_format automatically formats the /app partition, if needed.
     • app_device_size <Size in bytes> specifies the size in bytes of the /app partition. Here we set it to 30 GB.

   • Select the Setup tab, then click Save to save your modifications.

   • Restart HAProxy ALOHA.

2. Create your account through the MaxMind website and download the GeoIP databases.

   What is a geolocation database?

   You can store GeoIP database files, typically in a specific format like MaxMind’s GeoIP2 or GeoLite2. GeoIP data is information about the geographical location of IP addresses. This data is used in GSLB to determine the optimal routing of client requests based on their geographic location. These database files contain mappings between IP addresses and their corresponding geographical information, such as country, region, city, and latitude/longitude coordinates.

   When a client makes a request to the GSLB system, the system can analyze the client’s IP address and consult the GeoIP database to determine the client’s location. Based on this information, the GSLB system can make intelligent routing decisions to direct the client’s request to the most appropriate server or data center that can serve the request efficiently and optimize network performance.

3. Use scp or Winscp to copy the databases to /app/extra on your HAProxy ALOHA server. Example:

   nix
   scp GeoIP2-City.mmdb admin@192.168.56.50:/app/extra

   nix
   scp GeoIP2-City.mmdb admin@192.168.56.50:/app/extra

4. In the Services tab, click [advanced mode]. Then edit the gslb configuration.

   

   The current configuration displays.

5. Edit the configuration:

   • Replace the domain example.com with your domain name and record entries.
   • Add a new map record to the zone section. A record of type map is a dynamic record followed by a geoip-map name.
   • Create geoip-map sections that set answer-list sections to use depending on the client’s location.
   • Create answer-list sections. Below, the answer-list for DC1 contains a list of IP addresses for the datacenter in Europe, while the DC2 answer-list contains a list of IP addresses for the datacenter in North America.

   zone example.com
     ttl 84600
     record @ ttl 900  SOA   ns1 hostmaster 1 7200 30M 3D 900 
     record @          NS    ns1.example.com. 
     record ns1        A     203.0.113.1   # nameserver: Load balancer IP address
     record alias      CNAME www
     record www        map   mymap 
   
   geoip-map mymap
     location-base /data/geoip/GeoLite2-City.mmdb
     location EU/FR/Paris DC1 DC2
     location NA/US/Chicago DC2 DC1
     network 198.51.100.0/24 DC1 DC2
     network 203.0.113.0/24 DC2 DC1
   
   answer-list DC1
     up_threshold 0.5
     method single-rr
     option tcpchk fall 10 rise 10
     tcp-check connect port 80
     answer-record srv1 198.51.100.1 weight 20
     answer-record srv2 198.51.100.2 weight 20
     answer-record srv3 198.51.100.3 weight 10
     answer-record srv4 2001:db8::4001 weight 20
     answer-record srv5 2001:db8::4002 weight 20
     answer-record srv6 2001:db8::4003 weight 10
                
   answer-list DC2
     up_threshold 0.5
     method single-rr
     option httpchk
     http-check connect
     http-check send uri /health.html hdr host www.example.com
     http-check expect status 200,301,302
     answer-record srv1 203.0.113.10  weight 20
     answer-record srv2 203.0.113.11  weight 20
     answer-record srv3 203.0.113.12  weight 10

   zone example.com
     ttl 84600
     record @ ttl 900  SOA   ns1 hostmaster 1 7200 30M 3D 900 
     record @          NS    ns1.example.com. 
     record ns1        A     203.0.113.1   # nameserver: Load balancer IP address
     record alias      CNAME www
     record www        map   mymap 
   
   geoip-map mymap
     location-base /data/geoip/GeoLite2-City.mmdb
     location EU/FR/Paris DC1 DC2
     location NA/US/Chicago DC2 DC1
     network 198.51.100.0/24 DC1 DC2
     network 203.0.113.0/24 DC2 DC1
   
   answer-list DC1
     up_threshold 0.5
     method single-rr
     option tcpchk fall 10 rise 10
     tcp-check connect port 80
     answer-record srv1 198.51.100.1 weight 20
     answer-record srv2 198.51.100.2 weight 20
     answer-record srv3 198.51.100.3 weight 10
     answer-record srv4 2001:db8::4001 weight 20
     answer-record srv5 2001:db8::4002 weight 20
     answer-record srv6 2001:db8::4003 weight 10
                
   answer-list DC2
     up_threshold 0.5
     method single-rr
     option httpchk
     http-check connect
     http-check send uri /health.html hdr host www.example.com
     http-check expect status 200,301,302
     answer-record srv1 203.0.113.10  weight 20
     answer-record srv2 203.0.113.11  weight 20
     answer-record srv3 203.0.113.12  weight 10

   The geoip-map section syntax is as follows:

   Directive	Description	Example
   location-base	Absolute path to the geolocation database. You can supply several geolocation database names separated by spaces.	location-base /data/geoip/GeoLite2-City.mmdb
   location	The first parameter is a hierarchical path to a geographic region in the order of the continent code, a country ISO code, then more specific regions like state and city name. Refer to the MaxMind reference guide and ISO-3166 for these codes. Note that GSLB will search deeper into the hierarchy if a match is not found at the current layer. For example, you could specify country and city name, but omit the state name between them. The second parameter is a space-separated list of answer-list section names (e.g. DC2). GSLB directs client requests sent from this location to the first healthy datacenter in the list.	location NA/US/NY DC2
   network	As an alternative to using location, which uses geolocation data to choose the datacenter, you can also specify a client IP range. Set a subnet value in CIDR notation followed by an ordered list of datacenters (separated by spaces). The second parameter is a space-separated list of answer-list section names (e.g. DC2). GSLB directs client requests sent from this subnet to the first healthy datacenter in the list.	network 198.51.100.0/24 DC1

   About the answer-list sections:

   • GSLB will send DNS responses based on the location of the client. It will only send either IPv4 or IPv6 addresses, depending on the type of IP addresses the client requests.
   • Weights determine how often a particular IP address will be returned, with higher weights being chosen more often. The weight values apply only to the IPv4 or IPv6 pool of IP addresses. In the example, the IPV4 pool of servers and the IPv6 pool of servers have their own total weight sums.
   • By specifying method single-rr, HAProxy ALOHA alternates which IP for a datacenter it sends to clients in order to distribute traffic across all servers. In that case, the odds of a server’s IP being returned is server weight / sum of all server weights.
   • You can set method multi-rr to return multiple IP addresses to the client. In that case, the odds of a server’s IP being returned is server weight / max weight value.
   • The up_threshold directive determines the percentage of servers that must be up. Otherwise, traffic is routed to a different datacenter altogether.

6. Save your configuration, close the configuration editor, then apply your changes on the gslb line in the Services tab.

   

7. To make your changes persistent after a reboot, click the Setup tab. Then click Save under Configuration.

Datacenter failover Jump to heading #

While you can use geolocation-based load balancing to route traffic to the datacenter nearest to the client, you can also use HAProxy ALOHA for basic failover and failback between datacenters without the geolocation component. If a critical resource fails and service is disrupted, traffic will be automatically redirected to healthy datacenters. This minimizes impact and avoids manual intervention.

1. In the Services tab, click [advanced mode]. Then edit the gslb configuration.

   

   The current configuration displays.

2. Edit the configuration:

   • Replace the domain example.com with your domain name and record entries.
   • Add a new list record to the zone section. A record of type list is a dynamic record followed by list of space-separated answer-list names. Essentially, you are specifying datacenters in order of preference, with fallback datacenters following primary datacenters.
   • Create answer-list sections that match the names you listed on the list record in the zone section.

   Below, the list record www enumerates two answer-list sections, DC1 and DC2, where DC1 is the primary datacenter and DC2 is the fallback. You could list additional fallback datacenters too.

   zone example.com
     ttl 10
     
     # ORIGIN records
     record @ SOA ns1.example.com hostmaster.example.com 1 86400 3600 3600 3600 60
     record @ NS  ns1.example.com
     record @ ttl 3600 MX 100  mail1.example.com
     
     # static records
     record ns1   ttl 10 A 10.0.0.1
     record mail1 ttl 10 A 10.0.0.2
     
     # dynamic records - DC1 is primary, DC2 is a fallback
     record www ttl 30 list DC1 DC2
   
   answer-list DC1
     up_threshold 1
     method multi-up
     option httpchk
     http-check connect
     http-check send uri /health.html hdr host www.example.com
     http-check expect status 200,301,302
     answer-record srv1 20.0.0.1
   
   answer-list DC2
     up_threshold 1
     method multi-up
     option httpchk
     http-check connect
     http-check send uri /health.html hdr host www.example.com
     answer-record srv1 30.0.0.1

   zone example.com
     ttl 10
     
     # ORIGIN records
     record @ SOA ns1.example.com hostmaster.example.com 1 86400 3600 3600 3600 60
     record @ NS  ns1.example.com
     record @ ttl 3600 MX 100  mail1.example.com
     
     # static records
     record ns1   ttl 10 A 10.0.0.1
     record mail1 ttl 10 A 10.0.0.2
     
     # dynamic records - DC1 is primary, DC2 is a fallback
     record www ttl 30 list DC1 DC2
   
   answer-list DC1
     up_threshold 1
     method multi-up
     option httpchk
     http-check connect
     http-check send uri /health.html hdr host www.example.com
     http-check expect status 200,301,302
     answer-record srv1 20.0.0.1
   
   answer-list DC2
     up_threshold 1
     method multi-up
     option httpchk
     http-check connect
     http-check send uri /health.html hdr host www.example.com
     answer-record srv1 30.0.0.1

   The answer-list section syntax is as follows:

   Directive	Description
   up_threshold	Determines the percentage of servers that must be up. Otherwise, traffic is routed to a different datacenter altogether. A threshold of 1 means that all servers in an answer-list must be healthy for the corresponding datacenter to be regarded as active. If you specify 0.1, then 10% of the total weighted number of servers must be up.
   method	Determines which IP addresses to return. As with geolocation-based load balancing, you can return a single IP in a round-robin rotation (single-rr), multiple addresses in a round-robin rotation (method multi-rr), all servers that are up (method multi-up), or all servers, even if they are down (method multi-all).
   option	Specify httpchk to monitor the health of servers. If the servers are HAProxy ALOHA load balancers, you can use monitor URI as the health check endpoint.
   http-check	Set any relevant health check parameters.
   answer-record	Enter any number of answer-record directives, which denote IP addresses assigned to the datacenter.

3. Save your configuration, close the configuration editor, then apply your changes on the gslb line in the Services tab.

   

4. To make your changes persistent after a reboot, click the Setup tab. Then click Save under Configuration.

Testing Jump to heading #

You can use the dig command to test implementation. For example, if your domain is example.com you can use dig www.example.com @127.0.0.1 -p 153 to test.

; <<>> DiG 9.10.6 <<>> A @127.0.0.1 -p 153 example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4343
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                    IN      A

;; ANSWER SECTION:
example.com.             139   IN      A       20.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#153(127.0.0.1)
;; WHEN: Tue Jul 03 23:27:15 UTC 2023
;; MSG SIZE  rcvd: 74

; <<>> DiG 9.10.6 <<>> A @127.0.0.1 -p 153 example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4343
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                    IN      A

;; ANSWER SECTION:
example.com.             139   IN      A       20.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#153(127.0.0.1)
;; WHEN: Tue Jul 03 23:27:15 UTC 2023
;; MSG SIZE  rcvd: 74

Logs and status Jump to heading #

To see logs related to GSLB, call the syslog read system command from the CLI.

nix
sudo service syslog read system | fgrep gslb

nix
sudo service syslog read system | fgrep gslb

output
text
Mar 18 10:29:38 aloha01 daemon.info gdnsd[9313]: gdnsd version 3.8.0 @ pid 9313
Mar 18 10:29:38 aloha01 daemon.info gdnsd[9313]: DNS listener threads (2 UDP + 2 TCP) configured for 0.0.0.0:53

output
text
Mar 18 10:29:38 aloha01 daemon.info gdnsd[9313]: gdnsd version 3.8.0 @ pid 9313
Mar 18 10:29:38 aloha01 daemon.info gdnsd[9313]: DNS listener threads (2 UDP + 2 TCP) configured for 0.0.0.0:53

To see the up / down status of each DNS answer record’s IP address, call the service gslb stats command from the CLI or from the Diagnostic Tools menu on the Tools tab.

• real_state refers to the up/down status of the IP address based on health checks.
• state refers to an administrative override value of the IP address’s status (currently not supported).

nix
sudo service gslb stats

nix
sudo service gslb stats

json
{
  ...
  "198.51.100.1/DC1": { "state": "UP", "real_state": "UP"},
  "198.51.100.2/DC1": { "state": "UP", "real_state": "UP"},
  "198.51.100.3/DC1": { "state": "UP", "real_state": "UP"},
  "2001:db8::4001/DC1": { "state": "UP", "real_state": "UP"},
  "2001:db8::4002/DC1": { "state": "UP", "real_state": "UP"},
  "2001:db8::4003/DC1": { "state": "UP", "real_state": "UP"},
  "203.0.113.10/DC2": { "state": "UP", "real_state": "UP"},
  "203.0.113.11/DC2": { "state": "UP", "real_state": "UP"},
  "203.0.113.12/DC2": { "state": "UP", "real_state": "UP"},
}

json
{
  ...
  "198.51.100.1/DC1": { "state": "UP", "real_state": "UP"},
  "198.51.100.2/DC1": { "state": "UP", "real_state": "UP"},
  "198.51.100.3/DC1": { "state": "UP", "real_state": "UP"},
  "2001:db8::4001/DC1": { "state": "UP", "real_state": "UP"},
  "2001:db8::4002/DC1": { "state": "UP", "real_state": "UP"},
  "2001:db8::4003/DC1": { "state": "UP", "real_state": "UP"},
  "203.0.113.10/DC2": { "state": "UP", "real_state": "UP"},
  "203.0.113.11/DC2": { "state": "UP", "real_state": "UP"},
  "203.0.113.12/DC2": { "state": "UP", "real_state": "UP"},
}

Reference guide Jump to heading #

This section describes the syntax of the zonefile, which you can access by going to the Services tab, clicking [advanced mode], then editing the gslb configuration.

Domain zone Jump to heading #

A zone section defines a domain zone, a distinct part of the domain namespace. It contains one or more record directives.

Syntax:

zone <ZONE_NAME>
  ttl <TTL>
  record <DOMAIN_NAME string> ttl <seconds> <RECORD_TYPE> <FIELDS> 

zone <ZONE_NAME>
  ttl <TTL>
  record <DOMAIN_NAME string> ttl <seconds> <RECORD_TYPE> <FIELDS> 

This example defines a zone for example.com.

zone example.com

zone example.com

In the following sections we describe directives found within the zone section.

Time to Live Jump to heading #

The minimum TTL for records in this zone: TTL <num>. This is the default used for records unless specified otherwise in individual records.

zone example.com
  ttl 84600

zone example.com
  ttl 84600

The TTL here is 86,400 seconds, or 24 hours. DNS resolvers and clients that retrieve this DNS record will be allowed to cache it for up to 24 hours before checking for updates by querying the authoritative DNS server again.

Records Jump to heading #

Records declared using the record directive provide zone responses.

Syntax:

record <DOMAIN_NAME string> ttl <seconds> <RECORD_TYPE> <FIELDS>

record <DOMAIN_NAME string> ttl <seconds> <RECORD_TYPE> <FIELDS>

Arguments include:

SOA records Jump to heading #

Start of Authority (SOA) records provide administrative information about the zone, like the primary name server, the email of the domain administrator, and some configuration parameters. A zone must have exactly one SOA record.

zone example.com
  ttl 86400
  record @ ttl 900 SOA ns1.nameserver.com. admin.example.com. 2023090501 3600 1800 604800 86400

zone example.com
  ttl 86400
  record @ ttl 900 SOA ns1.nameserver.com. admin.example.com. 2023090501 3600 1800 604800 86400

The SOA record’s arguments include:

A records Jump to heading #

Map a domain name to an IPv4 address.

record www A 203.0.113.1

record www A 203.0.113.1

AAAA records Jump to heading #

Map a domain name to an IPv6 address.

example.com. AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

example.com. AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

CNAME records Jump to heading #

Creates an alias or nickname for one domain that points to another domain’s canonical (primary) name.

www.example.com. CNAME example.com

www.example.com. CNAME example.com

MX records Jump to heading #

An MX (mail exchange) record represents the mailing record for the domain. MX <Priority number> indicates the preference or priority of this mail server. Lower values represent higher priority.

Here the ttl is set to 30 seconds, and 10 is the priority value for the mail server:

record example.com ttl 30 MX 10 mail.example.com

record example.com ttl 30 MX 10 mail.example.com

NS records Jump to heading #

Specifies the authoritative name servers for a domain. These servers are responsible for providing DNS information for the domain.

example.com. NS ns1.examplehosting.com 
example.com. NS ns2.examplehosting.com

example.com. NS ns1.examplehosting.com 
example.com. NS ns2.examplehosting.com

List records Jump to heading #

A list of answer-list names separated by spaces associated with the domain name, for example:

record www2 list london paris amsterdam

record www2 list london paris amsterdam

Map records Jump to heading #

A list of geoip-map names separated by spaces associated with the domain name, for example:

record www3 map mymap

record www3 map mymap

Answer list Jump to heading #

An answer-list configuration is a set of parameters that dictate how to select and serve the best server or resource to a client based on certain conditions such as server health, load, or geographical location. It specifies the method for server selection, health check options, and other variables.

Syntax:

answer-list <ANSWER_LIST_NAME string>
  up_threshold <THRESHOLD number>
  method multi-up|multi-all|multi-rr|single-rr|cname
  option httpchk|tcpchk [fall <FALL_COUNT number>] [rise <RISE_COUNT number>]
  http-check connect
  http-check send uri <URI string> hdr <HEADER_NAME string>
  http-check expect status <STATUS number>
  answer-record <NAME> [<IP>] [weight <WEIGHT number>]

answer-list <ANSWER_LIST_NAME string>
  up_threshold <THRESHOLD number>
  method multi-up|multi-all|multi-rr|single-rr|cname
  option httpchk|tcpchk [fall <FALL_COUNT number>] [rise <RISE_COUNT number>]
  http-check connect
  http-check send uri <URI string> hdr <HEADER_NAME string>
  http-check expect status <STATUS number>
  answer-record <NAME> [<IP>] [weight <WEIGHT number>]

GeoIP map Jump to heading #

A geoip-map is a configuration setting that allows you to perform geolocation-based routing using your geolocation database. This will return different IP addresses in response to client DNS queries based on their geographical location.

Syntax:

geoip-map <MAP_NAME string>
  location-base <PATH string>
  location <GEO string|default> <ANSWER-LISTS>
  network <SUBNET cidr> <ANSWER-LISTS>

geoip-map <MAP_NAME string>
  location-base <PATH string>
  location <GEO string|default> <ANSWER-LISTS>
  network <SUBNET cidr> <ANSWER-LISTS>