Multiple IPs to a DNS hostname...is this possible? 1

[EvanK]

We're trying to rebuild our network at work for fault tolerance, and I was wondering if its possible for our server DNS hostnames to answer to multiple IPs. Let me explain...

We actually have two pipes coming into our building, a DSL line that the individual users are on (71.xxx.xxx.xxx), and a T1 that the servers are on (66.xxx.xxx.xxx). We're going to have end users and servers going through a Cisco router, and the router should allow the servers to answer to both a 66.xxx IP and a 71.xxx IP.

The problem is, our DNS entries for the server only point to the 66.xxx IP, so if that ISP goes down, the DNS name fails to resolve, even though we can manually type in the 71 address. So my question again is, can we have multiple DNS records, one pointing to 71 and the other pointing to 66?

 

[monsterjta]

You can have multiple IP's per hostname, but not multiple hestnames per IP.

Hope This Helps,

Good Luck!

 

[anawrocki]

You could do this but it will not give you fault tolerance, only round robin type load balancing. In other words,in the event of a down path, you will have a 50/50 shot that they will get the IP address associated with the correct pipe.

You could put this in place with short TTLs so the in the event of an extended outage you could make a DNS change so that all goes to one or the other, and hope that the majority of the cached DNS out there abides by your short TTL (most will).

Radware, Big IP, and F4 make devices that will manage this type of solution in an automated fashion. Very Slick, Very Spendy.

One option I have not spent time proving may be to use NS records to point to two different DNS servers, one on each pipe, whichever one was accessable would than respond with a different A record for the up-path. The one on the pipe that is down would not be available to resolve names to the down path, so all should work fairly well. Again, it won't be perfect, but will be fairly reliable.

Keep in mind, that any open session will be toast if a path fails mid-session. To solve for that you need to do this via a routing protocol (BGP or some other vodoo).

 

[EvanK]

How about this, then. Our primary DNS server would be on a 66.xxx ip, and would serve up records with a 66.xxx address for each of our servers, while the secondary DNS server would be on a 71.xx ip, and would serve up records with a 71.xxx address for each of our servers. Coupled with a very short TTL (a couple minutes lets say), this would effectively ensure that an outage wouldnt keep anyone from accessing us any longer than the timespan of the TTL.

IE: if the 66.xxx server goes down mid-session, the end user need only wait for the TTL to expire, and then DNS would be looked up again. When the 66.x DNS server is found to be not responding, any requests should then move on to the secondary 71.x DNS.

Does that sound kosher?

 

[anawrocki]

That is it in a nutshell. I see no reason it would not work. I have worked with a Radware solution and have set the TTLs to 30 seconds. Like I said, it won't be flwless, and some ISPs may ignore your short TTL, but for the most part it will work well.

I am assuming this is for inbound web requests. Obviously for e-mail you can just set up redundant MX records for the redundant paths and that will work perfectly.