GSLB and DNS Services FAQ
1) How long does it take to get the expected DNS response after creating a new FQDN or Zone?
Normally it takes between 30 seconds to several minutes to get the correct DNS response after a new FQDN or Zone is created.
2) How do you link a GSLB service to a DNS service?
Create a Zone in DNS service with the same domain as the GSLB service. The A/AAAA records of the GSLB service should appear in the DNS service resource records list automatically.
3) How long does it take for a modification in DNS configuration (like zone A record Rdata) to take effect?
The DNS configuration should be active within a few minutes.
4) How long does it take for the IP to update after the status of one of GSLB service’s pool members changes?
It depends on the pool member health check parameters, including down/up retry, interval and timeout. The smaller the value is, the less time it takes for the IP to update. The approximate time it takes is: retry * interval + timeout + system_run_time (in a few seconds).
5) Why isn't the GSLB service or DNS service working? How do I figure out what the issue is?
For the GSLB service, first check the status on the GSLB services page and make sure the virtual server in the pool is up. If the status is up or if there is a DNS service resource record, check the Contact & License page and confirm that there are valid query licenses and that the number of used queries is smaller than total queries.
Alternatively, you can check the DNS response status directly. If it is REFUSED, most likely the user does not have valid personal licenses or the maximum capacity has been reached or the domain does not exist. If there is a NOERROR status with NS server information in the authority section, this means it can find that domain and record, but the virtual servers in pool are not available. If the status is NXDOMAIN with SOA record in authority section, it means the domain name exists but the record’s hostname doesn’t exist.
6) What do I do if I see the warning “The FQDN/Zone domain name is duplicate with another organization”?
If a user creates a new FQDN or Zone and the warning message appears, it means this domain name already exists in the FortiGSLB server. It might be in the same account but a different organization or in another account’s organization. First check your own account’s organizations and create the domain in the same organization if possible. A duplicate FQDN or Zone domain name in a different organization is not allowed. If you must use this FQDN or Zone domain name and it does not exist in your account, please contact our support team or submit a suggestion in the FortiGSLB suggestion box and we will respond to your request as soon as possible.
7) What’s the difference between FQDN configure DNS-Query-Origin and Virtual Server Pool GEO?
Both methods match DNS queries based on client’s DNS Server IP location.
DNS-Query-Origin method in FQDN uses location list to do the matching and can select multiple locations into the list. It only matches the region that is selected in location list.
GEO method in virtual server pool uses the virtual server’s data center region to respond to the DNS query geographically. This method matches the DNS query location with the data center’s region if they are in same region, country or continent.
8) What are the meanings of the special Regions?
Reserved: IP addresses that are not assigned (e.g. 10.0.0.0/24)
Anonymous Proxy: IP addresses that are defined as anonymous proxy in GeoIP-DB (e.g. 46.19.137.0/24)
Satellite Provider: IP addresses that are defined as satellite provider in GeoIP-DB (e.g. 57.72.6.0/24)
Other Country: Reserved for further use, and no IP address are assigned to this region
Asia/Pacific Region: IP addresses that are defined as Asia/Pacific Region in GeoIP-DB, but not belonging to any specified Asian countries
Europe Region: IP addresses that are defined as Europe in GeoIP-DB, but not belonging to any specified European countries
9) What are the meanings of the special Locations?
Any: Any client IP GEO location
10) How does FortiGSLB GEO work?
Assume that the user uses DNS-Query-Origin method in GSLB services and wants to perform load balancing according to DNS query source IP. The work flow is as follows:
1 - Client sends DNS query to the local DNS server
2 & 3 - The local DNS server functions as a resolver to ask who knows the IP for this DNS query.
4 - After doing recursion from root server, the query is sent to FortiGSLB with the local DNS server’s source IP address. FortiGSLB will respond with a best matched IP according to the DNS query source IP (local DNS server’s IP) location and send a DNS response to the client’s local DNS server.
5 - Then, the local DNS server will send a DNS response to the client.
11) What is the expected result if the source IP matches both the address group and location or one of the address groups or location when the DNS-Query-Origin virtual server pool selection method is selected in GSLB Services?
FortiGSLB will respond to the DNS query based on its source IP according to the address group and location parameter configured in the VSP.
If the source IP matches both the address group and location of one VSP, FortiGSLB will respond to the DNS query with the VS IP from this VSP.
If the source IP matches multiple VSP's address group or location, FortiGSLB will respond to the DNS query with the VS IP from the address group that matches the VSP first, and then the location (as the address group matched VSP has priority over the location matched VSP).
If the source IP matches one VSP's address group or location, FortiGSLB will respond to the DNS query with the VS IP from that VSP.
If the source IP matches no VSP's address group or location, FortiGSLB will respond to the DNS query by weight for all VSP.
12) What if the DNS query source IP matches multiple Virtual Server Pool's address group?
FortiGSLB will respond to the DNS query with the first matched VSP when multiple Virtual Server Pool's address groups are matched. You can reorder the VSP if you want the second matched VSP to be used to respond.