The problem is those pesky TTLs.  I believe the big resi providers (ie:
Sympatico & Rogers) are manipulating them, so even though you have yours set
to 1 hour or whatever, your customers who get their DNS via their providers
will be given something that's almost a week old.  I'm not sure if they've
stopped this practice or not, but last time I checked, that's the way they
operated.

Of course to get around it, you could easily ship your devices with your DNS
servers set, but most of that info is user configurable so they could bork
it on you.

- Ian

On 6/14/06, Nabeel Jafferali <[EMAIL PROTECTED]> wrote:

Simon:

Although it is true that DNS is cached and round-robin DNS would cause a
50%
failure of calls in case one of the servers failed, DNS SRV is a different
animal.

"Smart" SIP endpoints know to look at all SRV records and the RFC provides
for priorities, so caching the DNS entry is not an issue.

Nabeel

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Simon P. Ditner
> Sent: June 14, 2006 3:31 PM
> To: [email protected]
> Subject: Re: [on-asterisk] Redundant/Spare setups in the real world
>
> Well, DNS records are meant to be cached and aren't designed
> to be changed instantaneously. Expecting DNS changes to be
> reflected on the internet in realtime isn't realistic, so I
> wouldn't advise relying on it for failover.
>
> On 6/14/06, John Lange <[EMAIL PROTECTED]> wrote:
> > I believe could do significantly better by using SRV records.
> >
> > http://www.voip-info.org/wiki/view/DNS+SRV
> >
> > This way you would never have to manually bind IP addresses to the
> > second machine. If it went down it would be more or less
> transparent
> > to the users.
> >
> > On the other hand you'd still have to manually move the PRI over.
> >
> > Running the PRI to a 3rd box or to a media gateway would partially
> > mitigate this but is still a single point of failure.
> >
> > John
> >
> > On Wed, 2006-06-14 at 14:21 -0400, Chad Osmond wrote:
> > > All this talk about Asterisk and failing has me curious.. What do
> > > you use in the "real" world for dealing with failures?
> > >
> > > For example, we have 2x 1U Servers, with A102 cards from Sangoma.
> > > Config's, voicemails, and other files are kept in sync with Rsync.
> > >
> > > In the event of a failure, we take the 1st server
> offline, move the
> > > T1 to the 2nd server, and change the IP of the second server.
> > > This lets us do upgrades easily as well. Once the server
> is running
> > > for a week or two, the old server gets a new kernel, updates, and
> > > usually a new Asterisk at this rate.
> > >
> > > What do you do in your installs to prevent against failure?
> > >
> > > I know there are some automated fail over T1 boxes, but I haven't
> > > seen the need for it..
> > > How often does a PRI go down?
> > > How often does a backhoe cut your copper feed to your
> building, (not
> > > enough to have redundant CO feeds probably)
> > >
> > > Chad
> > >
> > >
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional
> > > commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> > commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to