• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 580
  • Last Modified:

How do I redirect one FQDN to another FQDN?

One of our clients (lets call them Anon), have their DNS records hosted with a third party (lets call them DNSAnon). We (lets call us ALTDNSAnon), host the actual web server for Anon, and have two physically different SHDSL links entering our premises.

Each of the SHDSL links are provided by different vendors, and we have different public ip's assigned to each link. At any one time, we use one link as the primary, and the other as a secondary. In the event that the primary fails, we physically connect to the secondary. As that link has different public IP's we then have to get DNSAnon to change the IP addresses accordingly.

The main issue is that DNSAnon's DNS servers can then take up to 6 hours to propagate the changes which is too long. Our DNS servers propagate much quicker as they are directly hosted at a higher level in the DNS chain.

What I want to do is have some sort of redirection to our DNS entries from DNSAnon. For example, staging.anon.com.au which currently points to an IP address needs to point to staging.altdnsanon.com.au. This way I can make a simple change to the record for staging.altdnsanon.com.au which will propagate within 20 minutes or so.

There are a couple of contstraints;
1. Anon, don't want to move their DNS entries to us, so the primary records must stay with DNSAnon.
2. We can't use BGP as the links come from independent providers; if they were the same provider we could use BGP to solve all our problems.
3. Anon can live with 30 minutes of DNS propagation.
4. Anon can not live with up to 6 hours of DNS propagation.

Any ideas or suggestions would be much appreciated.
1 Solution
Idea #1: Is the DNS propagation delay caused by caching on other DNS servers? If yes, try setting really low TTL (e.g. 60 seconds) on the DNS records that you want to be able to modify quickly.
Idea #2: In Anon's DNS create CNAME record for staging.anon.com and point it to staging.altdnsanon.com
zacnutzAuthor Commented:
Thanks Filip.

To answer your question, yes, the propagation is due to caching. I had already thought of lowering the TTL's but as this is out of my control, I wanted to find as many options as possible before I went back to DNSAnon and asked them to do this.

In response to idea 2, I'll look into this and see if it's an option in our case.

Cheers, and thanks again.

Featured Post

Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now