1

We've just migrated to a new internal DNS resolver, and discovered a limitation that impacts our ability to lookup specific records.

Our internal (private) authoritative domain is example.net.. We have a CNAME record for service.example.net. that resolves to name-1234567890.region.elb.amazonaws.com.

name-1234567890.region.elb.amazonaws.com. resolves to various A records, who's values are managed by AWS. We do not manage the public amazonaws.com zone, nor the records within this zone.

Our previous DNS resolver would "chase" CNAME records, so a lookup of service.example.net. might return this:

$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net.    300 IN  CNAME   name-1234567890.region.elb.amazonaws.com.
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.3
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.4

The answer includes the IPs of the A records that the CNAME points to. All good.

Our new DNS resolver does not "chase" CNAME records. The same lookup with the new resolver looks like this:

$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net.    300 IN  CNAME   name-1234567890.region.elb.amazonaws.com.

... note the missing A records. Attempts to contact service.example.net via ping, curl, python requests, etc. all result in "Unknown host" failures.

We're not able to change the behavior of our new DNS resolver. Is there some option in the linux kernel or some local DNS resolver to "chase" CNAME records from the client, the same way our old DNS resolver did at the server side?

For context, our new DNS resolver is GCP's cloud-dns, which documents this behavior.

Some additional context / comment answers:

  • example.net. is a private, internal managed zone in cloud-dns owned by us.
  • amazonaws.com. is a public zone, managed by AWS.
  • iirc, an outbound server policy with additional name servers will send all queries to those nameservers, overriding cloud-dns
  • iirc, ALIAS records are only available in public zones, not private zones.
  • service.exmaple.net. is a CNAME record in the private, managed cloud-dns zone example.net.
  • we don't have a presence in AWS, so cannot use route53.
Danielle M.
  • 131

3 Answers3

1

Instead of directly pointing to the internal ips of the load balancer, you need to point to the public dns name of the load balancer

name-1234567890.region.elb.amazonaws.com

So remove the a records and change the cname value to the public dns name of the load balancer

Turdie
  • 2,945
1

I wanted to provide an update on this question. Since discovering this issue, GCP started rolling out an experimental feature for cloud-dns that does chase public CNAME records. At the time of writing (Apr 2024) this feature needs to be explicitly requested from GCP support. I'm unsure of when it'll go GA.

Before that feature was made available to us, we got around the issue by creating a private forwarding zone for eg.: amazonaws.com in our cloud-dns, which forwards to public DNS resolvers (we use 8.8.8.8, 1.1.1.1, etc). This works, as CNAME chasing is enabled in cloud-dns between private zones. As amazonaws.com is now considered a private zone by cloud-dns, CNAME chasing requests now resolve normally.

Danielle M.
  • 131
0

For resolving aws records I would recommend looking into route53 from aws.you can let your internal dns server forward to route53 for example unbound is an dns revolver which can do that

Amazon Route 53 is a scalable and highly available Domain Name System (DNS) web service provided by Amazon Web Services (AWS). It effectively translates user-friendly domain names like example.com into IP addresses that computers use to identify each other on the internet.Here's an overview of some key features and concepts of Route 53:

  • Domain Registration: Route 53 allows you to register and manage domain names. You can purchase new domains or transfer existing ones to Route 53.
  • DNS Service: Route 53 acts as a DNS service provider, allowing you to manage the DNS records for your domain. DNS records include things like A records (which map domain names to IP addresses), CNAME records (which map domain names to other domain names), MX records (which specify mail servers), and more.Health Checks and Failover: Route 53 can perform health checks on your endpoints, such as web servers, and automatically route traffic away from unhealthy endpoints to healthy ones. This feature is often used for implementing failover and disaster recovery solutions.
  • Traffic Management: Route 53 offers traffic management capabilities, allowing you to control how DNS queries are routed based on various factors such as latency, geolocation, weighted routing, and more. This enables you to optimize performance and availability for your applications.Integration with AWS Services: Route 53 integrates seamlessly with other AWS services, such as Amazon S3, Elastic Load Balancing (ELB), and Amazon CloudFront. For example, you can use Route 53 to route traffic to your ELB load balancers or CloudFront distributions.
  • DNSSEC: Route 53 supports DNS Security Extensions (DNSSEC), which adds an extra layer of security to your DNS infrastructure by digitally signing DNS records.Overall, Route 53 is a versatile and reliable DNS service that provides the foundation for routing traffic to your applications and services on the internet. It offers advanced features for managing DNS, improving performance, and ensuring high availability.
Guido
  • 94