Bridging the Gap: Solving Common Business Connectivity Challenges with Hybrid DNS Architecture
Tags: aws, data, linux, cloud
Published: 2024-07-07 19:32:42

Before we dive in, I’d like to extend my special thanks to Adrian Cantrill for his exceptional training materials. More details at the end of the article.

## _A4L's Mission_

Animals 4 Life (A4L) is a fictional but passionate animal charity dedicated to protecting animals around the world. Founded in Australia, A4L has expanded its reach globally, leveraging technology to enhance its conservation efforts. With operations spanning multiple regions, A4L’s commitment to wildlife protection drives its need for a robust and interconnected IT infrastructure. This hybrid DNS architecture plays a crucial role in supporting their mission, ensuring that both their on-premises and cloud environments can work together seamlessly to safeguard wildlife everywhere.
In the dynamic metropolis of A4L, two distinct domains existed: the boundless cloud of AWS and the steadfast on-premises data centers. These domains, though powerful, struggled with communication. AWS-hosted applications needed access to on-premises data and vice versa, and they had to keep some data on premises for regulatory compliance. The inability to resolve domain names across these environments created silos (and if you follow Scrum, this ain’t good), hindering the seamless integration vital for A4L's operations.

Have a peek at the initial architecture: 


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f41g96d37636u1fjm1nh.png)


## Key Challenges presented by this architecture:

- **Isolation**: AWS resources couldn’t locate on-premises resources.
- **Complexity**: Manual DNS configurations were error-prone and inefficient.
- **Performance**: Inconsistent connectivity led to delays and reliability issues.

Here we can see how when trying to connect from the AWS side with the on premises side, no connection was established:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/csgu37hlo3ymuci87n7y.png)


And the same when trying the other way around:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f9w0fitjr4u6iqezxhnw.png)


## The Bridge which came to the rescue

Enter the hybrid DNS architecture, a powerful solution designed to unite these disparate worlds. Central to this architecture were AWS Route 53 Resolver and Direct Connect (I used VPC peering as Direct Connect is hard to set up and not worth for a fictional company), forming the bridge for seamless communication.

## The Architecture Unfolds:

**Establish Direct Connect**:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ahi01v3ssg5h3q4c0mu5.png)


   - **Direct Connect** provides a dedicated, high-speed network link between AWS and the on-premises data center, ensuring reliable and secure dedicated communication. Although expensive, and with high overhead requirements, seemed to be the perfect solution for joining this two worlds, as it provides a constant connection between our two worlds providing a consistent connection, which was one of our key issues. Therefore, going back to our initial key challenges, two of them were removed by the Direct Connect connection, leaving us to focus only on the DNS configurations: 
  

- **Isolation**: AWS resources couldn’t locate on-premises resources. - Fixed 
- **Complexity**: Manual DNS configurations were error-prone and inefficient.
- **Performance**: Inconsistent connectivity led to delays and reliability issues. - Fixed

However, after doing this, we can still see there is no DNS resolution: 


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hy40im8ljwamfjdj36bf.png)


2. **Configure AWS Side**:

   - **Route 53 Private Hosted Zone**: Managed internal DNS records within AWS.
   - **Route 53 Resolver Endpoints**:
     - **Inbound Endpoints**: Inbound endpoints are crucial because they allow on-premises DNS servers to send DNS queries to AWS. This means that resources within the on-premises environment can resolve domain names for AWS-hosted services. For example, our on-	premises application will need to access an AWS-hosted database or web service. Without inbound endpoints, these queries would fail, isolating the on-premises environment from the cloud.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9aegwvm8i6fsqc6xoea7.png)

 - **Outbound Endpoints**: they serve the opposite purpose. They enable AWS 				resources to query the on-premises DNS servers. This is essential for cloud-hosted 			applications that need to interact with on-premises services. For instance, our web 			application running on an EC2 instance will require data from an on-premises database. 		Outbound endpoints ensure these DNS queries can be resolved, allowing seamless 			communication between AWS and on-premises resources.

3. **Integrate On-Premises Side**:
   
   As a result of the previous step, **Our Application Servers** can now directly query AWS services, bridging the gap. In this architecture, both inbound and outbound endpoints work in tandem to create a bidirectional flow of DNS queries. This unified approach ensures that applications and services, regardless of their location, can resolve each other’s domain names, facilitating seamless integration and operation. This hybrid DNS setup is a cornerstone in achieving a truly interconnected and efficient IT ecosystem. Therefore, going back to our initial key challenges, the last remaining one was removed by the endpoint resolvers.

- **Isolation**: AWS resources couldn’t locate on-premises resources. - Fixed
- **Complexity**: Manual DNS configurations were error-prone and inefficient. - Fixed
- **Performance**: Inconsistent connectivity led to delays and reliability issues. -Fixed

Leaving us with this final architecture:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jhq1seymnpsztsrkhl4c.png)



## Unified Operations, two Kingdoms working as one:

With the hybrid DNS architecture in place, A4L saw transformative changes, some of these were:

- **Seamless Integration**: AWS and on-premises resources communicated effortlessly.
- **Centralised Management**: Streamlined DNS management reduced errors and administrative burdens.
- **Enhanced Performance**: Direct Connect ensured low-latency, high-reliability connections.
- **Scalability and Flexibility**: Supported dynamic and scalable DNS query handling.
- **Security and Compliance**: Ensured sensitive data remained protected through private connections.

## The Happy Ending: Who Benefits?

1. **Wildlife Protectors**:
   - A4L’s web servers in AWS could now seamlessly access on-premises databases, ensuring real-time updates on wildlife conservation efforts, improving chances on saving all animals, yay!

2. **Disaster Recovery Champions**:
   - Ensured consistent DNS resolution across environments, enabling robust failover strategies.

3. **Data Residency Stewards**:
   - Maintained compliance by keeping sensitive data on-premises while leveraging cloud resources.

4. **Innovators with Complex Networks**:
   - Facilitated seamless communication across microservices and hybrid deployments.

## Conclusion

The story of A4L's hybrid DNS architecture is one of bridging gaps and fostering unity between cloud and on-premises environments. With AWS Route 53 Resolver and Direct Connect as pivotal characters, the tale of seamless integration and operational excellence unfolds, promising a future where cloud and local resources work harmoniously together. This architecture not only solves the problem of fragmented networks but also paves the way for a new era of interconnected possibilities.

**Special thanks to Adrian Cantrill** for his exceptional training materials. Adrian is a top-notch learning provider who excels in teaching not just theory but also hands-on application. His courses are packed with practical projects that allow learners to apply what they've learned and navigate real-world business scenarios.