Howtos

now browsing by category

 

Configuring and using georouting

Scenario:

You have several servers around the world publishing a website or an application that is accessed by users coming from different countries and geographies.

You want to be able to decide which server(s) users will reach based on their country/countries of origin, and you want to handle “fallback” scenarios in case one or more servers are not available.

GSLB.me georouting allows the creation of an unrestricted number of “routing rules” to achieve flexible, granular and precise DNS balancing and traffic distribution.

Georouting rules can be based on:

  • country of origin of the requesting DNS client
  • ASN (Autonomous System Number) of origin of the requesting DNS client
  • ISP (Internet Service Provider) of origin of the requesting DNS client

In the following configuration example we will assume:

  • the FQDN that will be resolved by clients worldwide is geo-name.myowndomain.com. This is your website/application host name.
  • we have three servers (targets) that run contents for geo-name.myowndomain.com, that is: you own three servers to support your applications/services/websites:
    • 1 Server in Australia, having IP 1.1.1.1
    • 1 Server in France, having IP 2.2.2.2
    • 1 Server in the USA, having IP 3.3.3.3
  • the following georouting rules need to be configured to implement such requirements. Please note that rules ordering is crucial to achieve the desired DNS balancing behaviour
    • clients coming from Brazil, Argentina, Peru and Chile will have to be sent to the US-based server (IP address 3.3.3.3). If the US-based server is down, then clients will be redirected to the French server (IP address 2.2.2.2)
    • clients coming fromVerizon UK shall be sent to the US-based server (IP address 3.3.3.3).
    • clients coming from either The United Kingdom or the USA will be sent to the Australian and French servers (IP addresses 1.1.1.1 and 2.2.2.2 respectively). Selecting either the Australian or the French server has to be done in round-robin. If both the Australian and the French server are down, clients will be redirected to the US-based server (IP address 3.3.3.3). Notice that due to the previous, ISP-based rule, users in the UK that connect through Verizon UK will get a 3.3.3.3 reply, whereas other UK-based users will get 1.1.1.1 and 2.2.2.2.
    • clients coming from ASN (Autonomous System Number) AS23564 shall be sent to the Australian server (IP address 1.1.1.1) with no fallback
    • clients originating from other countries will use either 1.1.1.1, 2.2.2.2 or 3.3.3.3 based on their vicinity (geographical proximity) to the three servers. This is a kind of fallback rule, to make sure that valid DNS replies are always sent back to requesting clients.

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account

Screenshot-1

 If not already done, create an authoritative DNS zone: we will add a geohost to it later on. Georouting rules are applied to geohosts so in order to use georouting the minimum requirement is to set up a geohost: this howto shows the full picture, also including authoritative zone creation.

howto.georouting.1

Fill out domain name and contact e-mail address

howto.georouting.2

when done, click “Save” to save the newly created zone, which is then displayed on the left-hand side of the web interface.

howto.georouting.3

we now need to create the geohost where we will set up georouting. Right clicking on the zone name displays the menu where “Add Geohost” has to be clicked.

howto.georouting.4

In the geohost edit panel, fill out at least the geohost name and set the balancing algorithm to “Georouting” (the “Setup Georouting” button will be enabled automatically) and save the changes. This creates the geohost where georouting will be configured.

howto.georouting.5

The newly created geohost is now displayed in the main zones tree: the yellow star icon indicates that changes have been saved but are still not active, we will commit them later on.

howto.georouting.6

Geohost targets must be added now: each target is one of the servers that host the website/application that we want to access through georouting. Right click on the geohost name and select “Add Target” from the menu:

howto.georouting.7

The target edit panel required configuration of at least the target’s IP Address (or FQDN) and checks to determine whether the target is working as expected or if it’s down/unavailable. After setting paramters, click on save.

howto.georouting.8

The newly added target is then displayed in the main zones tree:

howto.georouting.9

Now repeat the steps to add a new target, in order to enter 2.2.2.2 and 3.3.3.3. When both are added, the main zones tree displays them with the relevant country flags showing their geographical location.

howto.georouting.10

Georouting rules can be configured now. Left click on the geohost name and then click the “Setup Georouting” button on the right.

howto.georouting.11

This opens the georouting configuration dashboard. The dashboard provides full control on rules based on client country, ASN and ISP.

By clicking on “Add country-based rule” we create the first rule we need:

screenshot9a

We need to type the rule descriptive name:

By clicking on “Create” the rule configuration panel is displayed.

The lower section of the dashboard is the rule panel: each rule can be customized by enabling/disabling it and four sections allow full configuration of the rule behaviour.

The “selected countries” section lists the countries that match this rule. The rule itself will be used whenever a DNS request comes from a client located in one of the “selected countries”.

GSLB.me will then check the targets configured in the “Primary targets” list: if available primary targets are found, they are used to build the DNS response. If the “Primary targets” list contains more than one target, the “Primary algorithm” will be used to decide which target(s) to use for the DNS reply.

The “Fallback targets”, if configured, defines the list of one of more targets that are used in case all primary targets are unavailable/marked “down”. The “Fallback algorithm” will be used to determine which fallback targets to use to build the DNS response.

Back to the configuration, from the “available countries” list at the top of the dashboard, one or more countries can be selected and added to the “selected countries” list by clicking the “+” button:

Selected countries are then added to the list of “Selected countries”.

This rule is valid and will be used for all client DNS requests coming from the selected countries. Now its primary targets must be defined: from the “Available targets” list select the primary targets that will clients coming from the specified countries (3.3.3.3 in our example) and click the “+” button in the “primary targets” section:

 

The selected target is moved from the “available targets” list to “primary targets”:

So far, the rule replies to all DNS requests from the selected countries with 3.3.3.3 In case 3.3.3.3 is unavailable, we want to fallback by returning IP address 2.2.2.2, so it must be added to the “Fallback targets” list. To do so, select 2.2.2.2 from the “Available targets” list and click the “+” button in the “Fallback targets” section:

The selected target is then moved to the “Fallback targets” list. Rule configuration is completed:

The second rule must match requests for DNS clients that connect from Verizon UK. An ISP-based rule need to be added by clicking on the “Add ISP-based rule” button:

The rule name must be typed:

 

The new ISP-based rule is then added and its configuration panel is displayed:

Verizon UK must be selected: type a search string in the “ISP search” box (ie. “verizon”, search is case insensitive). The list of Found ISP is updated. You might need to type more characters in case nothing is displayed in the “Found ISPs” list, the maximum number of displayed ISPs is set to 500 to keep the user interface tidy and fast.

 

Select “Verizon UK Limited” from the list of found ISPs and then click the “+” button in the rule configuration panel, to add the selected ISP to the list of those who will match the ISP-based rule:

In our example we want all DNS requests coming from Verizon UK go to 3.3.3.3: we need to select the target from the list of available targets, and then click “+” to add it. The target is then moved to the “Primary targets” list.

ISP rule configuration is complete. The next rule we need is the one matching requests coming from the UK and the USA. Click on “Add country-based rule” to add the new rule:

Type the rule descriptive name and click “Create”:

The rule configuration panel is displayed: select the countries you need to match and click on the “+” button to add them to the rule:

Requests coming from the UK and the USA will be replied with 1.1.1.1 and 2.2.2.2 using a round robin algorithm: select the two targets from the list of available ones and click the “+” button to add them to the list of primary targets.

We need to set up 3.3.3.3 as the fallback target: in case both primary targets are down, it will be used to reply to UK and USA clients. Click on the 3.3.3.3 target and on the “+” button to add it to the fallback targets list.

The next rule to be configured is ASN-based. We need all clients sending DNS requests from AS23564 to get 1.1.1.1 as a DNS response. Click on “Add AS-based rule” to create the new rule:

 

Type the rule descriptive name:

The ASN-based rule configuration panel is displayed:

 

AS23564 must be selected: type a search string in the “ASN search” box (ie. “AS2356, search is case insensitive). The list of Found ASN is updated. You might need to type more characters in case nothing is displayed in the “Found ASNs” list, the maximum number of displayed ASNs is set to 500 to keep the user interface tidy and fast.

 

Primary targets that will be used to reply DNS queries need to be selected: click on 1.1.1.1 in the “Available targets” list and then click the “+” button under the “Primary targets” list, to move the target to the list itself.

 

The last rule to be configured is the default one: it will match all remaining countries in order to return a DNS reply for all clients not matched by the previous georouting rules. The country “– Unknown countries” matches all requests that should come from IP addresses that for some reasons can’t be mapped to a specific country (ie. satellite providers, etc).. Add a country-based rule by clicking on the “Add country-based rule” button:

Type the rule descriptive name:

From the “Available countries” list select all countries: these are those that are not matched by previously configured per-country rules. When done, click on the “+” button in the rule configuration panel to add all selected countries to the rule itself.

 

Select all the three targets and add them to the list of primary targets by clicking on the “+” button. Click on the “Primary algorithm” and select “Proximity”. This way, the “Fallback” rule will reply DNS clients with the geographically closest available target.

 

Once all georouting rules are configured, we need to make sure they will be evaluated in the desired order. Rules ordering can be set up and modified using the “Georouting rules sorter” at the top right side. The “up” and “down” arrows can be used to sort enabled rules.

When rules have been sorted according to your needs, “Save all rules” must be clicked in order to permanently save changes. This step is mandatory.

After saving all rules, modifications must be committed to make them active: this is done by clicking the “Commit” button at the top of the screen.

Georouting configuration is complete. Don’t forget to commit all changes to make them active, by clicking on the “Commit” button displayed at the top of the screen.

The last needed step is authoritative DNS reconfiguration for the “myowndomain.com” domain: authoritative DNS must be set to ns1.gslb.me and ns2.gslb.me. This is of course needed only when DNS resolution for the domain is handled by GSLB.me. Your mileage may vary: you could also create a geohost using georouting and belonging to one of our “public” zones: gslb.biz, gslb.eu, gslb.info, gslb.mobi, gslb.us and gslb.ws and then simply configure a CNAME record in your own authoritative DNS zone in order to have DNS resolution handled by GSLB.me.

Enabling DNSSEC

Scenario:

You need to enable DNSSEC for one authoritative DNS zone you previously configured (please see the “Create an authoritative DNS zone” howto).

 

How to configure it:

Log on to GSLB.me using your credentials

metrics.1

From the main interface dashboard, click on the authoritative zone you want to enable DNSSEC for

 

The zone configuration dashboard is then displayed. By default DNSSEC is disabled: click on the “Enabled” switch button to turn it on:

After switching on the DNSSEC setting, a warning is displayed to remind you that you will have to send the DS record to your registrar, in order to establish the DNSSEC chain of trust.

After acknowledging the reminder, click on the “Save” button at the bottom of the page in order to save changes:

After saving changes, click on the “Show DS Record” button, to display the DS record that will have to be shared with your domain registrar:

The DS record for your DNSSEC-enabled domain is displayed. This will have to be shared with your domain registrar in order to complete DNSSEC configuration. Based on your preferred digest type you will be able to select one of the displayed DS records:

DNSSEC is now enabled, and will be used for all static and dynamic records, and for all geohosts belonging to the authoritative zone.

Configuring and using passive checks

Scenario:

You need to set up your smart DNS configuration so that the DNS resolution algorithm is driven by externally-fed performance/availability indicators.

In the following configuration example we will assume:

  • the FQDN that will be resolved by clients worldwide is mytest.gslb.eu. This is your website/application host name.
  • you have two servers (targets) that run contents for mytest.gslb.eu:
    • 1 server with IP address 8.8.8.8
    • 1 server with IP address 8.8.4.4
  • each server is considered available if its CPU load average is < 60% (this is handled by a passive check through metrics pushed to GSLB.me)

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account

metrics.1

From the main interface dashboard, select the “Metrics” icon to start configuring your custom metrics

metrics.2

The metrics editor is displayed: here you can set up your metrics names, their type and description. After defining all the metrics you need you will be able to push them to GSLB.me. Free users can define an unlimited number of metrics but can only update one metric at a time per target. Two consecutive updates can be pushed to GSLB.me every 180 seconds. When buying and enabling “advanced metrics collection” for a geohost, an unlimited number of metrics can be pushed per target, with a minimum update interval of 30 seconds.

metrics.3

Define the new metrics with the name “cpu_load”, setting type to “percentage” and type its description. When done, click on “Add metric” to create it. Metrics names are case sensitive.

metrics.4

All defined metrics can be edited and deleted by using the table in the lower part of the screen.

metrics.5

After defining the “cpu_load” metrics, click on the “checks” section in the left section of the screen, then right-click on “Custom [right click here to add more]”. From the menu then select “Passive“.

metrics.6

The passive check configuration dashboard is displayed. Here you can type the check description and the expression to evaluate in order to determine the check status. Expressions can be fully customized: full instructions on the syntax to use can be found here

After typing the check description and the expression, click “Save“.

metrics.7

The newly created check is now displayed in the “Checks” section on the left.

metrics.8

Now click on the “Main” section and right-click the “gslb.eu” zone: from the menu that is displayed select “Add geohost“.

metrics.9

In the geohost configuration panel type the geohost name and save by clicking the “Save” button.

metrics.10

Now add the first target, by right-clicking the geohost name and by selecting “Add Target” from the menu.

metrics.11

In the target configuration panel type the target IP address and select the “Check CPU load” check you defined previously. This tells GSLB.me to check the target availability using the passive check. Once done, click “Save“.

metrics.12

The first target is then displayed in the relevant geohost (mytest.gslb.eu in this example).

metrics.13

Right-click the geohost name and select “Add Target” again from the menu, to create the second target.

metrics.14

In the target configuration panel type the target IP address and select the “Check CPU load” check you defined previously. This tells GSLB.me to check the target availability using the passive check. Once done, click “Save“.

metrics.15

The new geohost now needs to be committed to make it active. You can do this by right-clicking the geohost name and selecting “Commit changes“.

metrics.16

After committing the geohost, the “star” icon beside its name disappears. The geohost is now active.

Right-click the geohost name again and select “Show Status” from the menu.

metrics.17

The self-refreshing geohost status window is displayed and both targets are marked “down” since the “Check CPU load” is telling GSLB.me that both targets are not available. When the “Check CPU load” check was defined, its expression was “output=cpu_load<60“, so each target will be marked as “up” only when the “cpu_load” metrics will be less than 60. No “cpu_load” metrics have been pushed to GSLB.me so far, hence the check is returning a “down” response.

metrics.18

Now it’s time to push to GSLB.me the actual “cpu_load” readings from the two targets: this is accomplished through a simple REST service: “cpu_load” values are computed directly on your infrastructure/servers and can be pushed in a variety of ways, including simple “curl” commands, such as the following. Full instructions on how to use the metrics submission REST service can be found here.

metrics.19

After submitting the “cpu_load” readings and based on the “check schedule” parameter defined for each target, GSLB.me will update targets status and start delivering service based on your metrics, algorithms and business logic.

metrics.20

Using 2-factor authentication

Scenario:

You want to enrich security when logging on to GSLB.me to configure and manage your DNS services. GSLB.me administration GUI and REST API are accessed via HTTPS. Enabling 2-factor authentication leverages Google Authenticator to provide One-Time Passwords for Web GUI access.

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account. Username and password are required at this stage: since 2-factor authentication is not enabled yet, the “OTP Code” field can be left blank.

2factor.1

 

After logging in, select the “Profile” menu at the top of the GUI and select the “2-factor authentication” option.

 

2factor.2

 

The 2-factor authentication screen pops up with an important note on usage (to be read carefully). The QR-code for Google Authenticator configuration is shown, together with Account name, Key and Type, the three fields you might want to use if you can’t scan the QR-Code. QR-Code and the three fields must be used with Google Authenticator’s application, that must be running on your mobile device.

 

2factor.3

After setting up your Google Authenticator application, you can click on the “yes, I scanned the QR code and I want to enable 2-factor authentication” button. This will switch your GUI account to 2-factor mode. From this point on Google-provided OTP code will be required to log on to GSLB.me GUI.

 

2factor.4

 

IMPORTANT NOTE: Should you lose access to your mobile device where Google Authenticator has been enabled, you won’t be able to log on to GSLB.me anymore. Should this happen, please contact us by e-mail at support@gslb.me to have your access restored.

 

In order to test your newly enabled 2-factor authentication setup, log off from the GUI:

 

2factor.5And log on again. This time you will have to type the OTP code provided by Google Authenticator App running on your mobile device:

 

 

2factor.6

 

After logging in you can select the “Profile” menu at the top of the GUI and then click on the “Show profile” option. Your 2-factor authentication status will be displayed as follows:

 

2factor.8

 

To disable 2-factor authentication, you can access the “Profile” menu, then click on the “2-factor authentication” option and then click on the “Yes, I want to disable 2-factor authentication” button:

 

2factor.9

A confirmation will be displayed, your GUI access type is then set back to the standard username+password pair.

2factor.10

Importing authoritative zones

Scenario:

You want to replace your current authoritative DNS infrastructure (either owned or hosted by a third party) with GSLB.me, and you want to leverage automatic import of your already existing zones. Import must not require manual configuration and must be based on standard DNS zone transfer from your existing authoritative DNS.

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account

Screenshot-1

 

The authoritative zones import dashboard can be accessed either by right-clicking on “Customer zones” on the left panel or on the “DNS zones import” icon in the main screen section.

 

import.howto.2

 

After selecting the DNS zones import tool, the import dashboard is displayed

 

import.howto.3

 

Here you can configure the IP address or FQDN of your current primary authoritative DNS server hosting the zone(s) you want to import to GSLB.me. The default TCP port to be used for zone transfers is 53, and is customizable should you use a different one.

GSLB.me can perform zone transfers using a TSIG key (Transaction SIGnature key) or by configuring your current primary authoritative DNS server to allow zone transfers over TCP as requested by GSLB.me‘s zone importer’s IP address, which is shown on the DNS zone importer screen.

Several zones can be imported at the same time: all zone names must be entered in the “Zones to import” section, typing one zone name per line. When done, you can click “Import zones” to run the import procedure.

 

import.howto.4

 

When done, a summary is displayed detailing the zone import outcome on a per-zone basis.

 

import.howto.5

After importing one or more authoritative zones to GSLB.me you will need to contact your registrar to change their authoritative DNS to ns1.gslb.me and ns2.gslb.me: this will enable GSLB.me to fully host and handle your domain(s) resolution.

When done you will be able to add smart DNS resolution to your zone(s) by configuring geohosts to implement load balancing, proximity routing, geo-routing, add security by setting up DNS firewall rules, tracking and analyzing your DNS traffic creating customized analytics reports and more. Our technical support team is available to assist you configuring your DNS services, for free.

Using Reporting and Data Intelligence

Scenario:

You need to keep track and analyze DNS requests and responses for one of your running geohosts by configuring and customizing graphical reports.

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account:

graph-howto-1

To create a new graph from the main screen you can either right-click on the geohost name and select “Reporting engine“:

graph-howto-2

Or you can select the “Geohost reporting engine” from the main panel:

 

graph-howto-3

After clicking the “Geohost reporting engine” icon you can select the geohost you want to define graphs for using the dropdown menu:

 

graph-howto-4

Accessing the “Geohost reporting engine” brings you to the main graphs configuration section, which is initially empty. Clicking on the “Add new graph” button allows you to configure and customize your graph(s):

graph-howto-5

In order to create a new graph, its descriptive name must be specified. This is a purely mnemonic name and can’t be changed:

graph-howto-6

After typing the name, a default graph is set up, to display geohost DNS requests and responses (split by target) over the last 24 hours. Several other parameters such as font size, resolution, colors, etc are set to default values. After making changes, you can click on the “Save and update graph” button at the bottom of the page to commit and to display the updated graph.

graph-howto-7

The newly created graph can be fully modified and customized by setting its parameters in the “Graph style and appearance“, “Data series configuration” and “Timespan selection” sections. For instance you can try to change the parameter “Summarize minutes” from the default value of 1 to 10: this tells GSLB.me to display the graph averaging values over 10 minutes timeframes. By default data is averaged every 60 seconds. After setting “Summarize minutes” to 10 you need to click the “Save and update graph” at the bottom of the screen to commit changes.

graph-howto-8

As a further example. you might want to display only DNS requests sent to your geohost: the default graph also displays per-target DNS responses. In order to disable the latter, you can turn off the “Draw replies for all targets” switch. Once done, you can click on the “Save and update graph” button at the bottom of the screen:

graph-howto-9

The updated graph is then displayed.

You can define an unrestricted number of additional graphs, to keep track of DNS requests and responses, and to show different geohost-related scenarios.

To delete an existing graph you can click on the “X” close to the graph title, in the tab row at the top of the screen:

graph-howto-10

 

 

A confirmation window is displayed, and you can click “Yes” to delete the selected graph:

 

graph-howto-11

 

Configuring and using DNS firewall

Scenario:

You are running a service that is dinamically resolved through a geohost (ie. myservice.gslb.info) and you need to set up security and DNS resolution rules to:

  1. respond “NXDOMAIN” (FQDN not found) to all Internet clients running malware that try to resolve myservice.gslb.info
  2. always allow (whitelist) DNS resolution from your own public IP subnet (ie. 1.1.1.0/24). DNS resolution will take place according to the geohost configuration (to set up your geohost please refer to one of our howtos listed here below)
  3. respond with CNAME “www.google.com” to queries coming from subnet 6.5.4.0/28

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account

Screenshot-1

If we don’t have a geohost, it can be created by following one of our howtos. Our example geohost will be named myservice.gslb.info

 

Once the geohost is configured and working as expected, a firewall policy can be created and applied to it. In the web configuration interface the geohost is displayed in the left panel, and from the dashboard on the right the “Firewall policies” icon can be clicked to display the firewall configuration section.

 

howto-dnsfw.1

Once the Firewall section is displayed, right click on the “All policies” label to open the menu and select “Add policy”. This starts creation of a new firewall policy.

howto-dnsfw.2In the main configuration panel type a descriptive name for the firewall policy, make sure it is enabled and click on “save”.

howto-dnsfw.3

After saving the new policy, it is displayed in the tree on the left side of the screen. Right-click on the name of the newly created policy and select “Add client reputation rules” from the menu. This leads to the client reputation configuration panel.

howto-dnsfw.4

The client reputation panel allows you to configure rules to handle invasive/bad clients and to define the kind of DNS reply they will get when trying to resolve the geohost FQDN. Type a descriptive name for the client reputation rule, select the firewall action “Reply with NXDOMAIN” and move the “Malware Domain” category in the “selected” column using the “>>” button. When done, apply changes by clicking on the button.

howto-dnsfw.5

When changes are applied, the newly created client reputation rule is displayed on the left panel. Notice that the “my test firewall policy” has no active lists: later on we will need to define which rule lists will be effectively used as part of our firewall policy.

howto-dnsfw.6

Let’s add a whitelist now: right click on the policy name and select “Add whitelist” from the menu. This brings up the whitelist configuration panel.

howto-dnsfw.7

In the main configuration panel type a descriptive name for the whitelist, make sure it is enabled and apply changes.

howto-dnsfw.8

After applying changes, click on the whitelist name in the panel on the left side of the screen, this brings up the whitelist configuration.

Whitelist entries can be either IP addresses or whole subnets using the ip/netmask notation. Entries can be added manually and can include a description, or they can be imported from plaintext files. For the scope of this howto add a sample 1.1.1.0/24 subnet to the whitelist, together with its description, and then click on “Add” to save the entry. After adding the entry apply changes by clicking on the “Apply changes” button.

howto-dnsfw.10

After applying changes to the whitelist, it is displayed on the left hand side of the screen. Right-click on the policy name to open the menu and select “Add blacklist”.

howto-dnsfw.12

The blacklist configuration panel allows you to configure what reply to send to unwanted clients that try to resolve your FQDN. Type a descriptive name for the blacklist and select the firewall action “Reply with a CNAME”.

howto-dnsfw.13

Select “Reply with a CNAME” as the firewall action, type the CNAME you want blacklisted clients to get as a reply, let’s use www.google.com. When done, apply changes.

howto-dnsfw.14

After applying changes, the blacklist is displayed on the left hand side of the screen. Left-click it to open its configuration panel again. Now blacklist entries can be added, together with their optional description. Click the “Add” button to add the entry, and then click on “Apply changes” to commit the blacklist.

howto-dnsfw.15

All three lists are now configured and displayed under the firewall policy.

howto-dnsfw.16

Now we need to select what lists we want to run in the firewall policy, and define their matching order. To do so, click on the firewall policy name. This brings you to the policy configuration panel. Here we can select available lists and make them active in the current firewall policy. Selected lists can be ordered using the “up” and “down” buttons. The “Save” button applies changes.

howto-dnsfw.17

Select the “block malware clients” as the first list, then “my test whitelist” followed by “blacklist: forwarded to google.com”. This sets up the order firewall rules will be processed. Click on save when done.

howto-dnsfw.18

Firewall policy configuration is now complete. We need to associate the policy to our geohost in order to protect it based on the rules we just defined. To do so, open the “main” panel and left-click on the geohost name. This displays the geohost configuration panel, where the “Firewall” section can be found.

howto-dnsfw.19

In the “Firewall” section set “Enabled” to “on” and then select the firewall policy from the dropdown menu. This applies the firewall policy to the geohost. When done, click the “Save” button.

howto-dnsfw.20

On the left side of the screen, the geohost is marked by a “shield” icon. This means that a firewall policy is in place and will be used to check all DNS requests trying to resolve the geohost. The “star” icon reminds us that geohost configuration changes still have to be committed to make them active. To commit geohost changes you can click on the “Commit” button at the top of the screen.

howto-dnsfw.21

When geohost changes have been committed, the “star” icon disappears and GSLB.me starts running the firewall policy for the geohost. Realtime firewall statistics are available and can be accessed by right-clicking the geohost name and by selecting “Show Statistics” from the menu.

howto-dnsfw.22

Realtime statistics include two sections related to firewall policy activity, to keep track of blocked and allowed clients.

howto-dnsfw.23The first tab “DNS Requests” details all DNS requests for the current geohost, providing an overview on source countries.

howto-dnsfw.24

The second tab “DNS Responses” keeps track on the number of responses and their content.

howto-dnsfw.25

The third tab “Firewall policy” shows all blacklists and whitelists matches: list names are displayed together with matching IPs/subnets and the number of matches.

howto-dnsfw.26

The fourth tab “Client reputation” summarizes statistics on DNS requests coming from unclean/dangerous clients showing information on source countries, reputation categories and number of matches.

howto-dnsfw.27

DNS Firewall configuration is complete. Read our other howtos and contact us for any support request.

Create an authoritative DNS zone

Scenario:

You want to use GSLB.me as the authoritative DNS for your domain “mydomain.com“. mydomain.com can be a new domain you’re about to register, or it can be an already existing domain.

What you get:

  • flexible IPv4 and IPv6 support
  • support for A, AAAA, ALIAS, CERT, CNAME, LOC, MX, NS, RP, SOA, SPF, SRV, TXT records
  • dynamic DNS support for as many FQDNs as you need
  • configurable TTL for all records (subscribers only)
  • support for wildcard records
  • works with all Internet top level domains
  • easy migration from your legacy DNS provider
  • fast and advanced web user interface
  • seamless configuration, no need to manage master and slave DNS servers
  • globally distributed with no single point of failure so that your domains are always accessibile
  • actively developed and supported
  • two access models: totally free or subscription-based for additional features and flexibility

The first domain you configure on GSLB.me for authoritative DNS purposes is totally free.

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account

Screenshot-1

Create a new “customer zone”: this is the domain name you want to handle using GSLB.me as your authoritative DNS. You can create a customer zone for a domain name you already own (in this case you will ask your registrar to modify the authoritative DNS it relies on) or for a domain name you still have to register (in this case you will tell your registrar to use GSLB.me as your domain’s authoritative DNS servers). Creating a new zone can be done either by clicking on the button you can find on the main page immediately after logging on to GSLB.me…

Screenshot-2

…or by right clicking in the main panel on the “Customer zones” section.

Screenshot-3

The “Zone edit” page allows you to create your domain: here you have to specify the domain name and the e-mail address of the contact person. This e-mail address will be used as the postmaster in the SOA record for your zone.

Screenshot-4

Once done, click on “Save” to create your zone. After saving, the left-hand side of the page will be updated showing your newly created zone:

Screenshot-5

The SOA and NS records for your zone have been automatically created. “2 rrsets” indicates that ns1.gslb.me and ns2.gslb.me have been defined as the “NS” records for your domain. You can check this using dig or similar tools:

Screenshot-6

On the left-hand side of the screen click on the domain you just created: this brings you to the main domain configuration page.

Screenshot-8

Here you can change the domain’s contact e-mail address and fully edit your domain records (also called rrsets). Records types A, AAAA, CNAME, LOC, MX, NS, RP, SOA, SPF, SRV, TXT are supported. In order to add a new record you simply have to type the record name, select the type from the dropdown menu and assign a value. TTL is set to 86400 seconds for free GSLB.me users. Subscribers can set it to anything in the 300-86400 seconds range.

In order to add a record for your zone you have to set the record name, select its type, define the value and set the TTL (free users can’t change TTL: it is set to 86400 seconds by default). When done, click “Add record” in order to save the new rrset.

Screenshot-9

After saving your record(s), it is displayed in the lower section of the page. In the example here the record name “www” is appended with the zone name: the actual record shown here is www.mydomain.com, and it points to IP address 1.2.3.4

Screenshot-10

It is required to click on “Save” when all records have been added to your zone. If you don’t do this, your records will be kept but they will not be active. Clicking the “Save” button applies changes and makes all records active and running.

You can now check to see if the newly configured record works fine:

Screenshot-11

After configuring all the records you need (free users are limited to 20 records, subscribers can use an unrestricted number of records per domain) you need to get back to your registrar and tell them that you want to use ns1.gslb.me and ns2.gslb.me as authoritative DNS for your domain (mydomain.com in this example).

Once this last step is completed you’re done! You domain is fully handled by GSLB.me and you can rely on all the features it provides.

When configuring a record you can use a FQDN (Fully Qualified Domain Name) as the record value: for instance record “@”, type “MX” can have a value of “10 myothermailserver.myotherdomain.com.”. If the record value ends with “.” it is used as it is. If it doesn’t end with “.” your zone name is added at the end of the specified record value. For instance record “@”, type “MX” can have a value of “10 mail”. This means that the Mail eXchanger for mydomain.com is mail.mydomain.com where “.mydomain.com” is added after “mail”.

One more last thing: in addition to using GSLB.me as your authoritative DNS of choice you can seamlessly mix static DNS resolution together with GSLB dynamic resolution to handle disaster recovery, business continuity, CDN offload, geographical balancing for one or more records in your domain (such “smart” records are referred to as “geohosts”). To achieve this, simply right click on your domain name and create your geohosts!

Screenshot-12

In order to discover the full power of geohosts you can read our other howtos.

Create URL Forwarding Rules

Scenario:

You want to use GSLB.me to define URL Forwarding rules to translate a short, easy-to-remember URL to a longer web address that can point to a different port and/or rewriting an HTTP request into an HTTPS one. URL Forwarding is a feature that allows you to:

  • share a shorter, easier-to-remember HTTP address that automatically redirects clients to a different HTTP/HTTPS address by changing the server name, the URI and the server port
  • hide your complex website/application URLs behind an iframe-powered “masquerading” HTTP address
  • host your own webserver on your home/office Internet connection even if your ISP is blocking direct access to port 80, 443 or other ports. The shorter HTTP address is published by GSLB.me geographically redundant infrastructure and translates clients requests steering them to your home/office webserver

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account

Screenshot-1

 

Add a new “URL Forward” rule: this can be done either by clicking on the “URL Forward” icon on the main page that is displayed immediately after logging in:

 

howto.urlfwd.1

 

and then selecting the zone where you want to create the URL Forward rule:

 

howto.urlfwd.3

…or by right clicking in the main panel in the “Customer zones” section (if you are adding a URL Forward rule to one of your own domains) or in the “GSLB.me zones” section (if you just need a URL Forward rule without using GSLB.me as your authoritative DNS solution):

howto.urlfwd.2

The “URL Forward edit” page allows you to define your URL Forward rule. Parameters that can be defined include:

  • name: This is the name of your “short” HTTP address. This name will be trailed with the zone name so, if “name” is set to “myshorturl” and “zone name” is set to “gslb.mobi“, the full HTTP address you will type in your browser (and share on the Internet) will be http://myshorturl.gslb.mobi
  • destination URL: This is the HTTP (or HTTPS) address the “short” address will be forwarded/translated to. If “destination URL” is set to “http://my.very.long.url.com:8080/test/page.html?id=123“, all browsers and HTTP clients requesting “http://myshorturl.gslb.mobi” will be transparently forwarded to “http://my.very.long.url.com:8080/test/page.html?id=123
  • hidden destination URL: if this option is disabled, browsers and HTTP clients requesting the “short” URL will be redirected to the “destination URL“. If “hidden destination URL” is enabled, the “destination URL” will be displayed on clients browsers inside an hidden iframe. This behaviour “masquerades” the redirection from the end user’s perspective. This option is supported if the destination URL is an HTTP address, if it is an HTTPS address, hidden destination URL is silently ignored.
  • browser window title: if hidden destination URL is enabled, it is possible to set up the window title the browser will show when rendering the destination URL through the iframe. This option is supported if the destination URL is an HTTP address, if it is an HTTPS address, browser window title is silently ignored.

howto.urlfwd.4

Once done, click on “Save” to create your URL Forward rule. After saving, the left-hand side of the page will be updated showing your newly created rule, marked with a star icon, meaning that it has to be committed in order to make it active and fully operative:

howto.urlfwd.5

In order to fully enable the URL Forward rule, it is necessary to “commit” it. This can be done by either clicking on the “commit” button displayed at the top of the GSLB.me screen, or by right-clicking the rule name and selecting “commit changes“:

howto.urlfwd.6

After committing pending changes the URL Forward rule is fully operative. You can now run your favourite browser/HTTP client and browse to http://myshorturl.gslb.mobi

You will be redirected to the “Destination URL” configured here above.

Set up Dynamic DNS

Scenario:

You want to use GSLB.me as the authoritative DNS for your domain “mydomain.com“. mydomain.com can be a new domain you’re about to register, or it can be an already existing domain. Once done, you want to run “www.mydomain.com” from your webserver which sits on an Internet connection with a dynamic IP.

How to configure it:

Log on to GSLB.me using your credentials or register if you still don’t have an account

Screenshot-1

Create a new “customer zone”: this is the domain name you want to handle using GSLB.me as your authoritative DNS. You can create a customer zone for a domain name you already own (in this case you will ask your registrar to modify the authoritative DNS it relies on) or for a domain name you still have to register (in this case you will tell your registrar to use GSLB.me as your domain’s authoritative DNS servers). Creating a new zone can be done either by clicking on the button you can find on the main page immediately after logging on to GSLB.me…

Screenshot-2

…or by right clicking in the main panel on the “Customer zones” section.

Screenshot-3

The “Zone edit” page allows you to create your domain: here you have to specify the domain name and the e-mail address of the contact person. This e-mail address will be used as the postmaster in the SOA record for your zone.

Screenshot-4

Once done, click on “Save” to create your zone. After saving, the left-hand side of the page will be updated showing your newly created zone:

Screenshot-5

The SOA and NS records for your zone have been automatically created. “2 rrsets” indicates that ns1.gslb.me and ns2.gslb.me have been defined as the “NS” records for your domain. You can check this using dig or similar tools:

Screenshot-6

On the left-hand side of the screen click on the domain you just created: this brings you to the main domain configuration page.

Screenshot-8

Here you can change the domain’s contact e-mail address and fully edit your domain records (also called rrsets). Records types A, AAAA, CNAME, LOC, MX, NS, RP, SOA, SPF, SRV, TXT are supported. In order to add a new record you simply have to type the record name, select the type from the dropdown menu and assign a value. TTL is set to 86400 seconds for free GSLB.me users. Subscribers can set it to anything in the 300-86400 seconds range.

In order to add a record for your zone you have to set the record name, select its type, define the value and set the TTL (free users can’t change TTL: it is set to 86400 seconds by default). When done, click “Add record” in order to save the new rrset.

Screenshot-9

After saving your record(s), it is displayed in the lower section of the page. In the example here the record name “www” is appended with the zone name: the actual record shown here is www.mydomain.com, and it points to IP address 1.2.3.4

Screenshot-10

It is required to click on “Save” when all records have been added to your zone. If you don’t do this, your records will be kept but they will not be active. Clicking the “Save” button applies changes and makes all records active and running.

You can now check to see if the newly configured record works fine:

Screenshot-11

After configuring all the records you need (free users are limited to 20 records, subscribers can use an unrestricted number of records per domain) you need to get back to your registrar and tell them that you want to use ns1.gslb.me and ns2.gslb.me as authoritative DNS for your domain (mydomain.com in this example).

When configuring a record you can use a FQDN (Fully Qualified Domain Name) as the record value: for instance record “@”, type “MX” can have a value of “10 myothermailserver.myotherdomain.com.”. If the record value ends with “.” it is used as it is. If it doesn’t end with “.” your zone name is added at the end of the specified record value. For instance record “@”, type “MX” can have a value of “10 mail”. This means that the Mail eXchanger for mydomain.com is mail.mydomain.com where “.mydomain.com” is added after “mail”.

Once this last step is completed, your www.mydomain.com FQDN correctly responds to DNS queries.

 

How to update dynamic DNS records:

Dynamic DNS records can be updated in two ways:

  • Using GSLB.me REST APIs either directly or through GSLB.me update client
  • Using a standard update client such as ddclient: GSLB.me fully supports dyndns2 protocol

 

Updating dynamic DNS records via REST APIs:

You can install GSLB.me update client in order to tell GSLB.me to associate your dynamic IP address to your FQDN (www.mydomain.com in our example).

GSLB.me update client can be downloaded here (you need at least v1.1beta). It’s a Java client, hence it can be run virtually anywhere. It provides a number of parameters in order to correctly fetch your dynamic IP address. Once downloaded and unpacked you will find the startup script inside the “/sbin” directory. Some useful commandlines to run it are:

Updating a FQDN with the public (dynamic) IP of the specified interface without/with custom TTL:

	./sh.GSLB.ME-RestClient -u [username] -p [password] -dyn [fqdn] -iface [interface name]
	./sh.GSLB.ME-RestClient -u [username] -p [password] -dyn [fqdn] -iface [interface name] -ttl [seconds]

Updating a FQDN with the public (dynamic) IP using automatic IP detection without/with custom TTL:

	./sh.GSLB.ME-RestClient -u [username] -p [password] -dyn [fqdn]
	./sh.GSLB.ME-RestClient -u [username] -p [password] -dyn [fqdn] -ttl [seconds]

For correct operations running the update client should be done via crontab every 2 minutes or so, in order to keep your FQDN in sync with your dynamic IP.

Crontab job example:

*/2 * * * *    root     /home/mydir/GSLB.ME-RestClient/sbin/sh.GSLB.ME-RestClient -u username@domain.com -p myPassword -dyn www.mydomain.com -ttl 60 >/dev/null 2>/dev/null

Updating dynamic DNS records via dyndns2 protocol:

GSLB.me fully supports the dyndns2 protocol. It is then possible to use any DNS update client or device that can use the dyndns2 protocol to update your dynamic DNS records.

One of such update clients is ddclient (http://ddclient.sourceforge.net/) and a sample configuration you can use to make it work with GSLB.me is:

daemon=30                       # check every 30 seconds
syslog=yes                      # log update msgs to syslog
mail=YOUR_EMAIL_ADDRESS         # mail all msgs to your e-mail address
mail-failure=YOUR_EMAIL_ADDRESS # mail failed update msg to your e-mail address
pid=/var/run/ddclient.pid       # record PID in file.
use=if,if=ppp0                  # set dynamic IP address via interfaces

server=dynupdate.gslb.me        # GSLB.me update server
login=YOUR_GSLBME_USERNAME      # GSLB.me username
password=YOUR_GSLBME_PASSWORD   # GSLB.me password
protocol=dyndns2                # The dyndns2 protocol
YOUR_GSLBME_DYNAMIC_FQDN        # The dynamic DNS record to update (ie. www.mydomain.com)

 

Conclusion:

One more last thing: in addition to using GSLB.me as your authoritative DNS of choice you can seamlessly mix static DNS resolution together with GSLB dynamic resolution to handle disaster recovery, business continuity, CDN offload, geographical balancing for one or more records in your domain (such “smart” records are referred to as “geohosts”). To achieve this, simply right click on your domain name and create your geohosts!

Screenshot-12

In order to discover the full power of geohosts you can read our other howtos.

^