IBM announced a cloud-based service that is expected to help enterprises decrease the risk of DNS outages and protect corporate assets across multicloud environments.
The service, called IBM Cloud Sync, offers continuous, bidirectional synchronization and policy translation between IBM’s NS1 Connect package and the cloud provider’s DNS servers. NS1 Connect’s DNS services can make dynamic decisions about where to send an internet request, based on availability, performance, time-of-day and many other calculations. It also supports traffic-steering technology that distributes DNS traffic across the network, according to IBM.
With IBM Cloud Sync, customers can synchronize DNS zones, records, and traffic-steering data in real-time with multiple DNS cloud providers. In addition customers can automatically back up their DNS settings across multiple cloud providers, so that if unexpected events occur, they can restore services quickly to minimize downtime and protect data. Cloud Sync uses authentication and authorization controls when synchronizing and backing up DNS data.
While the service is intended to be multivendor, the initial release only supports AWS and its Route 53 DNS service.
According to an AWS statement: “Synchronization of DNS data between servers and across cloud providers is typically done using DNS Zone Transfer (XFR). In the absence of XFR support, network teams must either build and maintain custom scripts manually or resign themselves to vendor lock-in. IBM Cloud Sync reinforces Amazon Route 53 infrastructure and DNS availability, leaving customers time to focus on delivering innovation and business value, not managing infrastructure.”
IBM Cloud Sync translates and synchronizes DNS zones and records (including vendor-specific DNS records such as ALIAS), dynamic metadata such as traffic steering and health check probes, which makes it easy to implement redundant DNS solutions or retain advanced features like traffic steering, AWS stated.
“In addition to this DNS synchronization, you can publish DNS configurations to your Amazon Simple Storage Service (S3) bucket. As you implement DNS changes, the S3 bucket will automatically update. The ability to store multiple configurations in your S3 bucket allows you to choose the most appropriate restore point if required,” AWS stated.
Also, when XFR transfers are unavailable, many teams rely on manual scripts or custom tooling to align DNS configurations across environments — approaches that are error-prone, dependent on job synchronization and difficult to maintain, IBM stated.
IBM Cloud Sync currently requires an NS1 Connect Managed DNS account to synchronize configurations to/from Amazon Route 53. Customers can use an NS1 Connect free edition account for this purpose, although a paid license may be required if query volumes exceed the free edition thresholds, according to AWS.
Future releases of IBM Cloud Sync are expected to support Microsoft Azure, Google Cloud, Cloudflare, and other premium DNS services, according to IBM.
Translating network configurations and data from one cloud to another is a heavy lift. Cloud Sync from the IBM NS1 Connect portfolio is a promising solution for solving this engineering challenge, wrote Shamus McGillicuddy, vice president of research with Enterprise Management Associates in the white paper, “Network Config Synchronization Across Multi-Cloud Networks Application Resilience and Security.”
Enterprises told EMA that their top priorities for network data synchronization across clouds are: DNS configurations and data (56%), firewall configurations and rules (54%), subnet and VLAN configurations (51%), and NAT configurations (48%). Multi-vendor complexity is at the heart of synchronization difficulty, and that complexity is growing. For instance, 59% of enterprises have three or more cloud networking providers (including both cloud providers and network software vendors) and 57% expect that number to continue growing, McGillicuddy wrote.
“An organization might make progress by standardizing on a third-party firewall vendor across their clouds, but they’ll still use the native networking services of each of their cloud providers for six or seven other network functions, such as load balancing, routing, subnets, and DNS. In other words, network vendor sprawl is hard to eradicate in multi-cloud environments,” McGillicuddy wrote.
