Each service does DNS lookups to locate the DNS domain, they don't seem to remember anything...
The server cares not about the endpoint's dns names as it uses their IP addresses from registration. The server is simply looking up other servers/services all the time. At a minimum every lookup by a service should remember the lookups for the TTL of the record. We always enable caching on bigger systems and it's not really network utilization we're worried about. The fact that each service has to do a lookup for everything all the time is a performance concern. While better performance is great, I'm really more concerned with dealing with the complexity of setting up DNS for the average Joe. We spend much of our time resolving DNS issues and quite frankly it's getting old. If we can make sipXecs more reliable by not relying on other systems or humans the overall solution will be more reliable. I'll re-iterate again... What the servers and services need for DNS is different than what the client devices need. If admins want to use DNS on sipXecs that's fine... if admins want to use DNS on their Windows servers that's fine (except that they don't support views, so they will have to do some DNS trickery to make it work... but it's still possible). However, it is my opinion that the servers should still rely on their own mechanisms to find the other servers and services. Mike On Tue, Jun 21, 2011 at 3:16 AM, <[email protected]> wrote: > First: SipX is not a DNS server, on bigger systems I think SipX should not > be burdened with the DNS server task. > Caching is (amongst others) an endpoint process, so that's fine. > > When you start to cache you reduce the DNS network load with more then 90%. > So if on bigger systems you enable caching on all SipX boxes then resource > util of DNS will be extremely low. > I also doubt if it would be possible to make a solution that would use less > resources, unless you reduce the amount of > name resolutions that SipX needs. > But until now I have not seen any information about the type of load that > is expected when building a larger system. > Is it because endpoints need to be resolved (IP's already known), is it > because of continuously re-resolving SRV records > (again, most information is already known within SipX) or what. > I would like to know how many queries you expect on a bigger system and > what type of queries it would be. > If the amount of records is somewhat sensible then a caching DNS would do > the trick. > If it is completely of the scale then the processes in SipX have to be > redesigned, but what is causing the amount of queries? > What is being queried that is already fact (SipX knows it's servers)? > > About the load of DNS queries: > DNS is such a simple process that it hardly takes resources. > In our company I had 2 cases of wrongly configured web servers were in one > case one web server managed to > do 1300 queries per second (for the same 2 names), every second of every > minute/hour/day. > I only noticed this because I take traces on my DNS server on an irregular > interval to see the top queriers. > CPU utilization on our DNS server hardly increased (when idle load is about > 8%, normal around 12%, > with these queries between 13 and 15 %). > In the other case the load was worse, but it was more then a few years ago, > I lost the facts. > > Paul > > Josh Patten <[email protected]> wrote on 20-06-2011 23:23:27: > > > I'd say less than 1000. When you start breaking the 500-700 seat > > threshhold you start seeing where small performance enhancements > > make a big difference. > > > On Mon, Jun 20, 2011 at 3:47 PM, Nathaniel Watkins < > [email protected] > > > wrote: > > 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:sipx-dev- <sipx-dev-> > > [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]> 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 > > 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] wrote on 17-06-2011 16:06:00: > > > > > From: > > > > > > "Geoff Van Brunt" <[email protected]> > > > > > > To: > > > > > > "sipXecs developer discussions" <[email protected]> > > > > > > Date: > > > > > > 17-06-2011 16:06 > > > > > > Subject: > > > > > > Re: [sipx-dev] Suggestion for DNS improvements within sipXecs > > > > > > Sent by: > > > > > > [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] > > > List Archive: > > http://list.sipfoundry.org/archive/sipx-dev/ > > > > _______________________________________________ > > 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 > > > > > 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/ > > > > > > > > -- > > Josh Patten > > eZuce > > Solutions Architect > > O.978-296-1005 X2050 > > M.979-574-5699_______________________________________________ > > > sipx-dev mailing list > > [email protected] > > List Archive: > http://list.sipfoundry.org/archive/sipx-dev/ > _______________________________________________ > 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/
