DNS configuration option for Adobe Connect Edge servers

This TechNote is intended to be used as a supplement to the Adobe Connect Enterprise Server 6 installation and Configuration guide.

Edge servers aggregate data at a remote location, package what it can't handle itself and pass it on to an Origin server. In order for an Edge server to do its job, the DNS server in the remote location(s) must be configured properly.

Consider the above Edge server implementation at Example Co. The Origin server in Chicago has been installed for some time, and users in Tokyo and Paris as well as other locations around the world have been using it in production. There are a good number of Connect users in Tokyo and Paris and for this reason it has been decided to install an Edge server in these locations.

Note: The domain names and IP addresses given above are examples only.

Prior to the Edge server implementation, a user in Tokyo, Paris, Chicago or anywhere at Example Co. would open a browser and enter the URL http://connect.example.com to start a Connect session. There was (and still is) a DNS server in Chicago, Paris and Tokyo as well as other locations that all share the same DNS mappings. A DNS structure like this is called a "Centralized DNS system." Because the DNS system is "centralized" they all share the same mapping table; so no matter where a user is located, connect.example.com resolves to 10.7.215.10. Unfortunately this poses a problem once the Edge servers are installed.

After the Edge servers are installed, a user in Tokyo should be mapped to 10.7.145.11 (edge.tokyo.example.com) when they enter http://connect.example.com, not 10.7.215.10 (connect.example.com), and a user in Paris should go to 10.7.95.12. How can this be configured if a Centralized DNS system shares the same mapping table (connect.example.com always maps to 10.7.215.10 no matter where you are)? The answer is by using "Subnet Prioritization".

Solution

With "Subnet Prioritization" configured, the Centralized DNS system will return a list of IP addresses, the order of which is based on the location of the client (user). So in our example, a user in Paris that enters http://connect.example.com will get a list like 10.7.95.12, 10.7.145.11, 10.7.215.10 (Paris, Tokyo, Chicago), a user in Tokyo will get a list like 10.7.145.11, 10.7.95.12, 10.7.215.10 (Tokyo, Paris, Chicago), and any other user will get 10.7.215.10, 10.7.145.11, 10.7.95.12, (Chicago, Tokyo, Paris). This solves the problem for Connect. Now users in Paris and Tokyo are directed through their local Edge servers when accessing Connect, and everyone else goes directly to the Origin server.

If the DNS system is not "Centralized", meaning the DNS servers dont share the mapping table then "Subnet Prioritization" is not necessary: each DNS server can be configured individually.

You can find information about how to configure "Subnet Prioritization" on the Microsoft website.

There are two issuess to be aware of: