Getting the most out of your branch local connection
In our global world of business, organizations often have multiple branch offices spanning every country. Some of these branches are quite large with their own IT infrastructure and personnel, while some are very small with just a few employees. In the past, these branch offices were connected to the main office using MPLS or other connectivity in a hub-and-spoke topology. Today, however, many enterprises are adding local Internet break-outs to the branch offices to boost Internet connectivity speed. In addition, as many applications are now cloud-hosted, this provides redundancy without dependency on connectivity to the central office.
Many popular web applications, like Office 365, distribute their services to improve application performance, meet local regulatory requirements, and support content localization. When a user queries DNS to resolve the name of a service such as outlook.office365.com or www.google.com, the IP address of the origin server (or CDN proxy in front of this server) that is geographically closest to the user is usually returned during resolution. In theory, this provides the best performance and localization.
However, in order to get optimal DNS resolution, organizations need their DNS queries to flow through local Internet break-outs. One option for them is to deploy a local DNS Resolver in each branch. Many of these enterprises rely on Microsoft Active Directory Domain Controllers with DNS Services as the DNS infrastructure. However, deploying Microsoft Active Directory Domain Controllers in small branch offices requires having secure server closets and knowledgeable personnel to manage these servers. An alternative many enterprise choose is to configure the branch office network infrastructure to forward DNS queries to the DNS Resolver (on AD) in the main office, resulting in the suboptimal DNS resolution, since main office DNS Resolver returns DNS answers to the branch that are optimized for the main office IP. This means the centralized DNS model creates performance and localization penalties for the branch offices when using cloud applications.
How has Akamai worked to find a solution to this problem? It starts with our ever-improving Enterprise Threat Protector (ETP) Client. ETP Client 1.0 provided threat protection for only roaming users. The new Always-On feature in ETP Client 2.0 works on-net as well, performing DNS splitting at the device. This enables the client to direct DNS queries for internal domains to the corporate resolver in the main office, while also sending DNS queries for Internet web sites to the ETP DNS Service. As a result, Internet web servers closest to the branch are resolved locally, and end users can enjoy the fastest Internet connection from the branch office.
To enable this capability, the ETP Admin configures the organization’s DNS suffixes or IP addresses in Luna under the ETP/Utilities/Network Configuration tab. When this is done, the ETP Client will split the traffic for optimal user experience.
Now your users have the fastest access to cloud web applications! Learn more about ETP and the Client Connector by visiting www.akamai.com/etp
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by John Neystadt. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/AyTDeCZ9KFA/getting-the-most-out-of-your-branch-local-connection.html
