tag line

moving IT to the cloud with service not servers

Tuesday, 30 December 2014

Designing a Network for SaaS - Part 2


A whole range of factors have to be taken into account if you are planning to roll out a traditional server based network. In contrast the design objectives for a SaaS network are remarkably simple.
  • Resolve DNS as fast as possible. 
  • Get the data packet to the edge firewall as efficiently as possible.
Lets take each of these requirements in turn. Network design is covered in Part 3.

Resolving DNS.
In a SaaS network resolving DNS is particularly important since the majority of the resources are web based. SaaS services generate more DNS requests than legacy LAN based applications to the point where the user experience is heavily dependent on the speed of DNS requests. 

The standard deployment model requires at least two local DNS servers to resolve the addresses of internal resources. But in a basic SaaS deployment there are few (if any) internal resources that require DNS which brings into question the role of the internal DNS server. Without the requirement to resolve internal IP addressees it becomes advantageous use an externally hosted DNS server which is far more resilient and accessible than an internal service.



The problem of losing DNS if the internet connection is down is somewhat irrelevant if all the services that are referenced by DNS are external and accessed through the same connection. In reality the objection is mitigated by making the link resilient and by running a local DNS cache.

In the SaaS model the role of the internal DNS server is altered to act as a local cache for DNS requests.

The local DNS server should be configured as non-authoritative for any domain. As a caching-only server it does not contain any domain resource records. Instead, the server accepts DNS queries from client systems, resolves the name and caches the answer. This improves the responsiveness of the system by resolving DNS locally without passing requests out to an external server.

Client devices on the school site have DNS requests returned from the local cache while maintaining the ability to query the public DNS servers remotely.

If the school plans to implement a service such as Google Apps for Education (GAFE) the external forwarders should be the Google public DNS servers. Clients have the IP address of the local server as the primary DNS and the address of the Google server as the secondary DNS.

Google have produced a very useful Networking Guide that covers some of these concepts in more detail.

>>>>> Designing a Network for SaaS - Part 3