Would that caching dns daemon be "nscd"? (included in every distro).
I had some problem with it in the past and don´t like it, but it´s major function is to turn a workstation capable of self-caching DNS and NIS queries. andre On 4/11/06, Joseph Tanner <[EMAIL PROTECTED]> wrote: > I've had this problem too. It would get so bad, that it wouldn't even > answer incoming calls, and if I tried to dial out via pstn, I would > have hung up before it got around to dialing (which it would > eventually do, unfortunately). > > A short-short term solution was to install bind, and use it as your > primary nameserver. Hopefully it'll cache dns queries long enough to > survive an outage. > > A slightly better (in my opinion) solution would be to code a pure > caching dns server, whose sole purpose is to look up specific domains > and resolve them to their ip address. It'll record the result, and > will check every so often (once a minute, hour, day, whatever) and > update its results. If it cannot get an answer, it keeps using the > last known ip address. If anyone knows of a really bare-bones, > standards-breaking dns server that would say, check a flat file > database each time a request is made, we could run a daemon that would > check the domains we need to resolve; if no answer is received, we > just skip that line. That way the daemon will be sitting there > waiting for a dns answer, and not asterisk. > > The best solution would be to "fix" asterisk (I say "fix", as I'm sure > many will say it's not broken, that's fine). If your internet > connection fails, there's no reason to have internal calls and calls > in and out of your pstn lines failing too. Personally, I have a > toll-free line that runs over voip, and if it can't reach my server, > it'll fall back and dial a landline I have. In this case though, if > my internet connection is down for an extended period of time, even > those calls won't make it through. > > Joseph Tanner > > On 4/11/06, picciuX <[EMAIL PROTECTED]> wrote: > > > > because, a this time, the sip stack doesn't have asynchronous DNS... so ALL > > the sip code is stucked waiting timeouts for DNS queries (that are long > > timeouts). > > When you try to dial a LAN device, the sip code is trying to resolve your > > voISP service providers' addresses. > > We workaround this putting all external sip peers in a separate file, say > > "sip_peers.conf", included in sip.conf with "#include filename". > > Then, a daemon on the box try to resolve well-known addresses on well-known > > DNS servers on the net, every 5 minutes. If the demon fails ALL the > > well-known DNS queries, it assumes no internet connection is available: then > > it renames sip_peers.conf, and ask asterisk a "sip reload". So all external > > sip references are out, and sip still continue working for internal phones. > > Needless to say, when connection come up again, the daemon do the opposite > > thing. > > > > hope this helps > > > > > > 2006/4/11, Brent Torrenga <[EMAIL PROTECTED]>: > > > Out internet connection was out this morning. It seems that the SIP > > > extensions on our LAN were affected. Behavior like: > > > > > > Call comes in over POTS to a TDM400P, there is a delay then before the > > Cisco > > > 79[46]0's start to ring. > > > If we were lucky enough to get a call through, then we could not transfer > > > the call, or place the call on hold, or park the call. > > > Outbound calls seemed to have a delay between the time they were dialed at > > > the SIP phone and when they were connected. > > > > > > I know this has been brought up before, in fact there is a bit of a > > > discussion going on now about DNS SRV (in sip.conf, set srvlookup=no, or > > put > > > all the phone ip's on /etc/hosts). But what is really causing the issue > > > here? Yes, it is DNS, or something related to DNS, but why does that have > > > anything to do with * trying to make a phone ring on the LAN? > > > > > > I would think that by using qualify=yes for any outbound voip trunks we > > > avoid an issue of trying to call out is the net is down, but why are any > > > operations on the LAN affected? > > > > > > > > > Sincerely, > > > > > > Brent A. Torrenga > > > [EMAIL PROTECTED] > > > > > > Torrenga Engineering, Inc. > > > 907 Ridge Road > > > Munster, Indiana 46321-1771 > > > > > > +1 219 836 8918 x325 Voice > > > +1 219 836 1138 Facsimile > > > www.torrenga.com > > > > > > _______________________________________________ > > > --Bandwidth and Colocation provided by Easynews.com -- > > > > > > Asterisk-Users mailing list > > > To UNSUBSCRIBE or update options visit: > > > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > > > > > _______________________________________________ > > --Bandwidth and Colocation provided by Easynews.com -- > > > > Asterisk-Users mailing list > > To UNSUBSCRIBE or update options visit: > > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > -- Andre Ruiz <[EMAIL PROTECTED]> Curitiba, PR, Brasil _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
