When we are dealing with 'smaller' vs. 'larger' - what types of thresholds are we talking about.
i.e. does smaller mean less than 100 endpoints or does smaller mean less than 1000? From: [email protected] [mailto:[email protected]] On Behalf Of Michael Picher Sent: Monday, June 20, 2011 12:22 PM To: sipXecs developer discussions Subject: Re: [sipx-dev] Suggestion for DNS improvements within sipXecs Paul, I disagree with your assessment in (2). On smaller systems this may seem insignificant but on larger systems the load here is real... even with a caching dns setup (which is what is needed at a minimum anyway...). Mike On Mon, Jun 20, 2011 at 7:45 AM, <[email protected]<mailto:[email protected]>> wrote: Wow, a lot of discussion on this topic, I think now is the time to give this thread a new start. Let's inventorize improvements and issues, create JIRA's for them and then come up with solutions for them. Maybe I've got it (completely/partially) wrong, but this is my attempt to summarize the thread. A start, 1 to 4 are improvements IMHO, 5 to 7 are issues/JIRA's, should two be created for 6 and 7? 1) Bind views Bind Views are nice to implement branches, and if you want to use branches then DNS views are almost mandatory. We could even decide that they are mandatory, but I don't see what relation they have with DNS problems in the sense of resource utilization/load. So the whole views discussion should be part of the whole branch design. 2) SipX issues a lot of queries I think the load is not that high, but it's easy to make a linux box cache. To create a self refreshing cache is nice, but it means reinventing the wheel. The wheel will allow a higher topspeed, but I think sticking to the tried and tested "wooden wheel" caching DNS is a tremendous step forward. 3) HA optimization HA should be as fluent as possible. Do we need to lower TTL's ( what does it bring, it would mean dynamic DNS SRV records) or rely on DNS to give a list of servers for each service and let the clients/servers find an active box/service. 4) DNS server failover (on linux level) This can be optimized for faster failover 5) SipX resolving unused services SipX resolves tls records although tls is not used (already a JIRA: http://track.sipfoundry.org/browse/XX-9639) 6) SipX resolving records not listed in sipx-dns or/nor DNS advisor _sip._udp.rr.first.internal.epo.org<http://udp.rr.first.internal.epo.org> is an example 7) A record for domain needs to be there According to Tony, I have an A record that I need (for XMPP :) so can't confirm. etc etc [email protected]<mailto:[email protected]> wrote on 17-06-2011 16:06:00: > From: > > "Geoff Van Brunt" <[email protected]<mailto:[email protected]>> > > To: > > "sipXecs developer discussions" > <[email protected]<mailto:[email protected]>> > > Date: > > 17-06-2011 16:06 > > Subject: > > Re: [sipx-dev] Suggestion for DNS improvements within sipXecs > > Sent by: > > [email protected]<mailto:[email protected]> > > >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 to > > I agree, but for these users SipX needs to hand hold them. Many > Windows DNS admins only know the basics and have no idea what a > NAPTR record is (they are now available in 2008 R2). Having a sub > domain managed by SIPX is not terribly difficult, but they generally > have no clue how to set this up properly. MS has made DNS a no > brainer for Active Directory domains which is both a good and bad > thing. As mentioned in my early post a gui wizard would be ideal for > getting them both educated to the choices available, and to setting > up either one. > _______________________________________________ > sipx-dev mailing list > [email protected]<mailto:[email protected]> > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ _______________________________________________ sipx-dev mailing list [email protected]<mailto:[email protected]> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ -- Michael Picher eZuce Director of Technical Services O.978-296-1005 X2015<tel:978-296-1005%20X2015> M.207-956-0262<tel:207-956-0262> @mpicher <http://twitter.com/mpicher> www.ezuce.com<http://www.ezuce.com> ________________________________ 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/
