At TCPWave, we understand the challenges shown below and we have an enterprise grade cloud DNS solution that leverages the Cloud DNS provider’s DNS service for external DNS instead of deploying compute nodes in the cloud to serve external DNS.
This management is performed using encryption and RESTful APIs. A powerful CLI toolset is provided for the DNS administrators to perform simple and complex tasks. Rules are enforced in the TCPWave IPAM using templates. Intelligent DNS Data Integrity checking algorithms in the TCPWave IPAM query each DNS cloud provider, the VPC hosted DNS instances and the on-premise DNS appliance using a REST API method. If a delta is found between the TCPWave Management and the cloud DNS data, a REST Call is made to the to the appropriate system to add the missing update. Say goodbye to UDP based zone transfers.
The possibilities on whom to sync and when are endless with TCPWave IPAM. A powerful scheduler allows the DNS administrator to come up with intelligent workflows such as:
Overcoming the challenges listed above becomes simplified with the TCPWave IP Management Solution. Sunset the excel spreadsheets, PERL scripts, SOAP APIs and the technologies from the 90s. Embrace the cloud with security using our RESTful API technology.
Cloud Computing is out of its infancy and enterprises have embraced it for its cost effectiveness and the agility that it brings to the IT. Cloud computing helps reduce the server footprint in the data centers and leverage the services from the cloud providers. Using the cloud model, enterprises can build fast and pay for the resources based on usage. Extending the data centers into the cloud reduces operating expenses in the enterprises and it makes a traditional system administrator’s activity redundant. The time taken to bring up a compute node with the desired software is performed in a matter of a few minutes in the cloud versus days/weeks in the customer owned data center with a traditional system administrator building a server from scratch. Similarly, provisioning networks, subnets, ACLs and tasks associated with storage provisioning and allocation are simplified by embracing the cloud provider’s model.
As enterprises extend their data centers into multiple clouds and as the demands for resources in the compute, network and storage space exponentially increase, the DNS administrators find it challenging to catch up with the rapid demand and to keep up with the pace. In addition to this, if the data center is extended into multiple Virtual Private Clouds (VPCs) such as a mixture of Amazon’s AWS, Google, Rackspace and Microsoft’s Azure, it becomes challenging to manage DNS records in each VPC and constantly update the central DNS database. The traditional IPAMs do not understand these DNS challenges in the cloud.
A private cloud model using multiple cloud providers. Let’s assume that Amazon’s AWS and Microsoft Azure are chosen by an enterprise. Each cloud provider’s VPC needs a local cache DNS server with site specific configurations so that a local cache can query the VPC hosted DNS Root/Standalone Master and resolve names that are available with each respective VPC. In addition to this, each local VPC cache requires a selective forwarding to the public Internet to resolve specific Internet names. The AWS VPC cannot communicate directly with Azure’s VPC for security reasons. Deploying a slave DNS instance in each VPC requires a UDP port opened on the firewall to permit zone transfers from the enterprise’s internal network to the cloud hosted slave and this typically does not get a nod from the security team. Also, Azure’s VPC entries should not be visible in AWS and vice versa. It’s getting complicated, right?
An enterprise wants to use a hybrid cloud model and wants to have Amazon and Google for resiliency. When a new virtual instance is provisioned in Amazon’s AWS, the Route 53 DNS needs to see an automatic update using the elastic IP provided by Amazon’s AWS using a business friendly name. The Internal DNS of the enterprise needs to get updated using the corporation’s internal naming convention with the private IP of the compute node so that users can get into the virtual instance from the internal network. Finally, Google’s external DNS needs to see an update so that the Internet facing application is available when Amazon’s Route 53 sees a DNS outage for any reason. This sounds even more complex!
An enterprise needs to have a streamlined management of their external DNS. Multiple external DNS service providers are chosen to ensure redundancy. Each external DNS service provider has DNS DDOS attack mitigation tools and a wide spread anycast network globally. The enterprise does not want to do a capital spend and host their own DNS servers in the externally facing Internet. Each external DNS service provider has their own dashboard and a learning curve is associated with each provider’s toolset. Each of these service provider’s authentication mechanism for the Web Interface to perform DNS management may or may not communicate with the enterprise’s LDAP/Active Directory. As personnel leave the corporation, the managers find it challenging to verify the list of employees that can manage the enterprise’s external DNS. If the external DNS provider does not have an audit of changes performed by the employees, a disgruntled ex-employee / a leaked admin credential can bring down the enterprise’s external DNS.