I'm not thinking that you'd need to manage 2 sets... I think the communications servers should manage their own sets and you could still do your own thing. IMHO for best reliability it is best to "control your own destiny".
So for me, for ultimate reliability (ie., lessen chance of a Windows network admin not knowing what the 'rr' folder is for), DNS on the communications server resolving the SIP domain. I've been burned way too many times by too many people who have no clue about DNS who are actually managing DNS. You can always create a sub-domain (ie., voip.yourdata.domain) and then to a FWD lookup in your Windows server to the Linux DNS... With domain aliases in the system you can add yourdata.domain if you want t If we think about what has hindered adoption of sipXecs more than anything or caused more problems than anything it's people not having a clue about DNS (why do you think most Asterisk admins use IP addresses?). Anything we can do here to simplify DNS and at the same time make the system more reliable and faster will be a win at the end of the day. Trying to educate the world on DNS is getting old. Mike On Thu, Jun 16, 2011 at 5:02 PM, Nathaniel Watkins < [email protected]> wrote: > I may be in the minority on this group...however... > > I would guess that many organizations already have a solid windows based > DNS/active directory setup. I have a total of one linux box on my network - > while it may be my favorite box...I need sipXecs/phones/gatways/etc. to be a > part of my network - not the other way around. So I think whatever the > solution, it needs to work with the DHCP/DNS provider of my choice... > > I don't want to manage 2 sets of books... > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Worley, Dale R (Dale) > Sent: Thursday, June 16, 2011 3:12 PM > To: sipXecs developer discussions > Subject: Re: [sipx-dev] Suggestion for DNS improvements within sipXecs > > You have to be careful about the architecture of all this. > > In the original version of the code, it stepped through the operations > mandated by RFC 3263. > This led to the obvious results, such as, it wouldn't look for A records > for the domain name if it found SRV records. > > The problem with this strategy is that it requires several round-trips > between the sipXtackLib routine and the DNS server, which takes a bit of > time, even if the server is on the same host. > > The code was modified to make all possible queries in parallel. This > results in a useless queries in almost all circumstances, but it makes the > overall process faster, as all of the round-trips are done in parallel. > > Logging has another paradox. In principle, there's no reason to log a > warning just because a certain class of DNS records is not found for a > domain name, as it's a routine circumstance. > But in practice, when one is tracing a failed call, one wants to know "Did > it get the DNS records for this domain name?" Failed DNS lookups (or > invalid domain names) are a common cause of failure, and the person > diagnosing the problem has a hard time knowing if the DNS succeeded or > failed (long after the fact) if a note isn't put into the log file when a > DNS lookup turns up empty. > > Dale > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > This message and any files transmitted with it are intended only for the > individual(s) or entity named. If you are not the intended individual(s) or > entity named you are hereby notified that any disclosure, copying, > distribution or reliance upon its contents is strictly prohibited. If you > have received this in error, please notify the sender, delete the original, > and destroy all copies. Email transmissions cannot be guaranteed to be > secure or error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. Garrett County > Government therefore does not accept any liability for any errors or > omissions in the contents of this message, which arise as a result of email > transmission. > > > Garrett County Government, > 203 South Fourth Street, Courthouse, Oakland, Maryland 21550 > www.garrettcounty.org > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > -- Michael Picher eZuce Director of Technical Services O.978-296-1005 X2015 M.207-956-0262 @mpicher <http://twitter.com/mpicher> www.ezuce.com
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
