In article ,
Greg T wrote:
> Gidday,
>
> I realise this might be clutching at straws, but...
> I have a test domain set up here (mylocaldomain) with a DNS name
> "server" bound to multiple IP addresses.
>
> The relevant config lines look like this:
> server.mylocaldomain. 60 IN A 192.168.1.12
> server.mylocaldomain. 60 IN A 192.168.1.7
> server.mylocaldomain. 60 IN A 192.168.1.16
> server.mylocaldomain. 60 IN A 192.168.1.254
>
> This works nicely for load sharing. Sending a ping to
> server.mylocaldomain results in a response from any 1 of the above
> servers (seemingly random, I was expecting round-robin, but no matter).
>
> What I am wanting to know is whether DNS provides the capability to
> failover to the next IP address if one is unreachable. For example, if
> I unplug 192.168.1.254, and try sending a ping to server.mylocaldomain,
> a timeout on 192.168.1.254 would result in the request going to another
> server like 192.168.1.12.

Failover is the job of the application, not DNS - DNS just turns a name
(in this case) into a list of IP addresses. The order in which is lists
the addresses is rotated on repeated requests. DNS doesn't have any way
of knowing which IPs are reachable at any moment in time.

The application can (should?) be written to accept all these addresses,
not just the first, so that if the first address it tries to contact
does not respond, it can then move on and try the next one.

Cheers,
Tony
--
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org

Tony Mountifield wrote:
> In article ,
> Greg T wrote:
>
>>Gidday,
>>
>>I realise this might be clutching at straws, but...
>>I have a test domain set up here (mylocaldomain) with a DNS name
>>"server" bound to multiple IP addresses.
>>
>>The relevant config lines look like this:
>>server.mylocaldomain. 60 IN A 192.168.1.12
>>server.mylocaldomain. 60 IN A 192.168.1.7
>>server.mylocaldomain. 60 IN A 192.168.1.16
>>server.mylocaldomain. 60 IN A 192.168.1.254
>>
>>This works nicely for load sharing. Sending a ping to
>>server.mylocaldomain results in a response from any 1 of the above
>>servers (seemingly random, I was expecting round-robin, but no matter).
>>
>>What I am wanting to know is whether DNS provides the capability to
>>failover to the next IP address if one is unreachable. For example, if
>>I unplug 192.168.1.254, and try sending a ping to server.mylocaldomain,
>>a timeout on 192.168.1.254 would result in the request going to another
>>server like 192.168.1.12.
>
>
> Failover is the job of the application, not DNS - DNS just turns a name
> (in this case) into a list of IP addresses. The order in which is lists
> the addresses is rotated on repeated requests. DNS doesn't have any way
> of knowing which IPs are reachable at any moment in time.
>
> The application can (should?) be written to accept all these addresses,
> not just the first, so that if the first address it tries to contact
> does not respond, it can then move on and try the next one.
>

I thought it might be something like that. So this kind of setup isn't
really a goer for redundant web servers then.

Thanks for your reply,
Greg

In article ,
Greg T wrote:
> Tony Mountifield wrote:
> > Failover is the job of the application, not DNS - DNS just turns a name
> > (in this case) into a list of IP addresses. The order in which is lists
> > the addresses is rotated on repeated requests. DNS doesn't have any way
> > of knowing which IPs are reachable at any moment in time.
> >
> > The application can (should?) be written to accept all these addresses,
> > not just the first, so that if the first address it tries to contact
> > does not respond, it can then move on and try the next one.
> >
>
> I thought it might be something like that. So this kind of setup isn't
> really a goer for redundant web servers then.

It is fine for providing rudimentary load-sharing, but not for trying to
mask the failure of one of the servers.

You could put the servers behind something like a Cisco Local Director.
It would then balance the traffic between them, and notice when one goes
down. Your DNS would then point to the single address of the outside of
the Local Director.

But you'd have to be careful if the web servers maintain session state.

Cheers,
Tony
--
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org

On Sat, 27 Sep 2003 11:06:27 +1200, Greg T On
Sat, 27 Sep 2003 11:06:27 +1200, in comp.protocols.tcp-ip.domains you
wrote:

>Tony Mountifield wrote:
>> In article ,
>> Greg T wrote:
>>
>>>Gidday,
>>>
>>>I realise this might be clutching at straws, but...
>>>I have a test domain set up here (mylocaldomain) with a DNS name
>>>"server" bound to multiple IP addresses.
>>>
>>>The relevant config lines look like this:
>>>server.mylocaldomain. 60 IN A 192.168.1.12
>>>server.mylocaldomain. 60 IN A 192.168.1.7
>>>server.mylocaldomain. 60 IN A 192.168.1.16
>>>server.mylocaldomain. 60 IN A 192.168.1.254
>>>rvers (seemingly random, I was expecting round-robin, but no matter).
>>>
>>>What I am wanting to know is whether DNS provides the capability to
>>>failover to the next IP address if one is unreachable. For example, if
>>>I unplug 192.168.1.254, and try sending a ping to server.mylocaldomain,
>>>a timeout on 192.168.1.254 would result in the request going to another
>>>server like 192.168.1.12.
>>
>>
>> Failover is the job of the application, not DNS - DNS just turns a name
>> (in this case) into a list of IP addresses. The order in which is lists
>> the addresses is rotated on repeated requests. DNS doesn't have any way
>> of knowing which IPs are reachable at any moment in time.
>>
>> The application can (should?) be written to accept all these addresses,
>> not just the first, so that if the first address it tries to contact
>> does not respond, it can then move on and try the next one.
>>
>
>I thought it might be something like that. So this kind of setup isn't
>really a goer for redundant web servers then.


What you want is known as a High Availibility server, and they are
specific to the particular service you are providing (web server,
database, mail, etc.). Each has it's own management and coordination
requirements specific to that service.

As previously mentioned, DNS service is about names, not services.

Since you mention Web servers:
For Apache; see http://www.linuxvirtualserver.org
and http://www.backhand.org/mod_backhand/

A recent article on High Availability Servers on EarthWeb:
"Linux Clusters for the Mainstream Manager"

http://networking.earthweb.com/netsy...0954_3083551_1

TM> DNS just turns a name in this case) into a list of IP addresses.
TM> The order in which is lists the addresses is rotated on repeated
TM> requests.

Some content DNS server softwares rotate it. Others don't. Moreover, some
proxy DNS server softwares also rotate it, and others don't. Finally, any
proximity sorting in DNS clients themselves completely overrides whatever the
content and proxy DNS servers may have done.

In article <3F756CCE.2252FA4@Tesco.NET>,
Jonathan de Boyne Pollard wrote:
> TM> DNS just turns a name in this case) into a list of IP addresses.
> TM> The order in which is lists the addresses is rotated on repeated
> TM> requests.
>
> Some content DNS server softwares rotate it. Others don't. Moreover, some
> proxy DNS server softwares also rotate it, and others don't. Finally, any
> proximity sorting in DNS clients themselves completely overrides whatever the
> content and proxy DNS servers may have done.

Interesting, thanks! I'm curious about what kind of information a proximity
sorting DNS client would use to sort on, and from where it might get it.

Cheers,
Tony
--
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org

On Sat, 27 Sep 2003 11:06:27 +1200, Greg T
wrote:
>
>I thought it might be something like that. So this kind of setup isn't
>really a goer for redundant web servers then.

Depends on your requirements I guess. I tested 3 major web browsers
(IE 5.x, Netscape 4.7x, and Opera 6) on this issue about a year ago
and found that, if the DNS server returns multiple A records per query
like BIND does, web browsers aren't too bad at trying various IP's
until they find one that works. If the first IP chosen doesn't
respond, IE tried another after 20-25 seconds and Netscape did the
same after 40-45 seconds. Opera, however, seemed to stick with the
unreachable IP indefinitely.

So if the requirement is very high availability, DNS in of itself
probably isn't appropriate. If requirements are less stringent,
perhaps DNS alone is acceptable.

-Terry

TM> I'm curious about what kind of information a proximity sorting
TM> DNS client would use to sort on, and from where it might get it.

In ISC's BIND DNS Client library, this is done with information supplied
manually by the administrator via the "sortlist" directive in "resolv.conf".

In Microsoft's Windows DNS Client library, the information is taken directly
from the network interfaces by the DNS Client itself, and all that an
administrator can do is enable and disable the feature with the
"PrioritizeRecordData" property of the DNS Client service.

In article ,
Terry Baranski wrote:
> If the first IP chosen doesn't
>respond, IE tried another after 20-25 seconds and Netscape did the
>same after 40-45 seconds.

Of course, this behavior is only useful if you have users who are patient
enough to wait 25 or 45 seconds for the web browser to come back with
something. I suspect 80-90% of users would hit the Stop button before
that.

--
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.