On Thu, Jun 16, 2011 at 12:55 PM, Josh Patten <[email protected]> wrote: > I think the point of this post is being dodged. I'll break it down: the way > sipXecs services utilize DNS is wholly inefficient. While it may seem > trivial for small systems to have this many DNS queries this can become a > real problem with large installations regardless of a caching server. This > is not just a "make it log less" issue, this is a "quit making gobs of > unnecessary DNS queries" issue. > > Regarding future DNS implementations in future versions of sipXecs, the idea > is that with the ability to have tens of servers that remote branch > locations would have their own SIP proxy to handle local registrations and > SIP routing. There is currently no other way that I am aware of the force > traffic to stay local for these scenarios other than to use BIND views. > > On Thu, Jun 16, 2011 at 9:01 AM, <[email protected]> wrote: >> >> Number of queries: >> As Gerald says, install a caching name server, by default most Linuxes >> won't cache. >> (But to be honest, the DNS load is not high currently IMHO). >> >> Logging: >> The logging is happening too frequent and it should be able to "disable >> dns stuff" for services you don't use. >> I don't use TLS for example but my log file is full with >> >> "2011-06-16T02:04:06.845279Z":2776308:SIP:WARNING:first.epo.org:SipSrvLookupThread-22:B5EFCB90:SipXProxy:"DNS >> query for name '_sip._tls.third.epo.org', type = 33 (SRV): returned error" >> >> "2011-06-16T02:02:50.442031Z":2776125:SIP:WARNING:first.internal.epo.org:SipSrvLookupThread-22:B5EFCB90:SipXProxy:"DNS >> query for name '_sip._tls.second.internal.epo.org', type = 33 (SRV): >> returned error" >> Should these be added to sipx-dns, dns advisor and dns or are they not >> needed? >> >> These also either don't make sense or sipx-dns needs adjusting: >> >> "2011-06-16T02:02:48.196400Z":2776086:SIP:WARNING:first.internal.epo.org:SipSrvLookupThread-20:B60FEB90:SipXProxy:"DNS >> query for name '_sip._udp.rr.first.internal.epo.org', type = 33 (SRV): >> returned error" >> >> "2011-06-16T02:02:48.196443Z":2776087:SIP:WARNING:first.internal.epo.org:SipSrvLookupThread-23:B5DFBB90:SipXProxy:"DNS >> query for name 'rr.first.internal.epo.org', type = 1 (A): returned error" >> I have the correct _sip._tcp.rr records in place, according to sipx-dns >> thats all I need, but the log is complaining about a _sip._UDP.rr , but only >> for my first/main server. >> Also DNS advisor is not complaining about this record. >> >> And then there is also a >> >> "2011-06-16T02:02:50.428519Z":2776115:SIP:WARNING:first.internal.epo.org:SipSrvLookupThread-22:B5EFCB90:SipXProxy:"DNS >> query for name '_sip._tls.rr.other-domain.internal.epo.org', type = 33 >> (SRV): returned error" >> Where "other-domain" is another sipx cluster configured as unmanaged >> gateway. >> Why would something want to do TLS with an unmanaged gateway?......Figured >> it out...I left Transport protocol on Auto for this unmanaged gateway, not >> for the others I have. >> It says "Set to force the SIP transport protocol. If set to auto the >> transport is determined through a DNS query. " on the Gateway details in >> "Advanced settings". >> The "a DNS query" is more like "a lot of DNS queries", 124 in a good 12 >> hours top be exact, intervals between 1 and 8 minutes. >> And looking at my first logging problem, probably it's the same problem, >> only not cross-domain and not configurable, servers within one cluster will >> try to resolve TLS records >> and you can't disable this (or can you). >> >> Linux DNS subsystem failover >> OK, fast failover is good >> >> Simplified DNS Management from Administration Web Interface >> If sipX is DNS server then all could be "under the hood". >> For people that configure their own DNS maybe it is possible to create a >> sipx-dns function in the GUI that based on the configured servers and >> services creates the right output of all needed DNS records (but DNS advisor >> sort of does that already). >> Views however are not everybody's cup of tea, I don't know whether that >> should become mandatory. >> >> My DNS advisor is complaining a lot about my third XMPP only server. >> According to sipx-dns run like >> sipx-dns domain.internal.epo.org first.internal.epo.org/10.x.x.1 >> second.internal.epo.org/10.x.x.2 -x domain.internal.epo.org/10.x.x.3 >> I don't need >> _sip._udp.domain.internal.epo.org. pointing to third server >> _sip._tcp.domain.internal.epo.org. pointing to third server >> _sip._tcp.rr.first.internal.epo.org. pointing to third server >> _sip._tcp.rr.second.internal.epo.org. pointing to third server >> _sip._tcp.rr.third.internal.epo.org. pointing to third server >> >> According to DNS advisor I do need them, but I am running happily without >> them. >> >> Now it's weekend for me because I have to prepare our polder day coming >> saturday: >> >> http://www.schieveensepolder.eu/joomla/index.php/activiteiten/midden-delfland-dag-2011 >> >> >> Josh Patten <[email protected]> wrote on 16-06-2011 15:56:29: >> >> > I'm not just talking about logging...I'm talking about fixing the >> > reason why the services are logging DNS items that frequently in the >> > first place regardless of where the DNS server is located. TTL >> > values should be followed. The most efficient way to do this in my >> > opinion is for the service to query DNS at startup and then only >> > perform another query when another sipXecs service is restarted or >> > when the TTL is about to expire. >> > >> > On Thu, Jun 16, 2011 at 1:43 PM, Gerald Drouillard >> > <[email protected]> wrote: >> > > On 6/16/2011 1:20 AM, Josh Patten wrote: >> > >> DNS as a primary method for facilitating communication between >> > >> endpoints, sipXecs servers, and gateways has proven to be an >> > >> excellent >> > >> method of enabling load balancing and, to a lesser extent, redundancy >> > >> of sipXecs services. >> > >> >> > >> As it is currently implemented in sipXecs, DNS is the root cause of >> > >> many outages and issues. This is because DNS configuration for proper >> > >> sipXecs operation is complex for most network >> > >> engineers/administrators >> > >> and is very difficult for most telecom engineers to understand. This >> > >> will only become more complex as future versions of sipXecs will add >> > >> the capability for many more servers to be added to each sipXecs >> > >> cluster, each possibly being deployed at a remote site to be used for >> > >> survivability or load balancing. It has also been observed that >> > >> individual sipXecs processes are making unnecessarily large amounts >> > >> of >> > >> DNS queries which can result in network congestion and extra load on >> > >> the sipXecs cluster. >> > > I agree about the excessive log writing. Maybe one could get that >> > > info >> > > in debug mode. To reduce traffic then install a caching name server >> > > on >> > > the sipx machine. >> > > >> > -- >> > 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/ > > > > -- > 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/ > I don't think anyone disagrees DNS can be improved. I don't think this is being dodged by the discussion about logging either. It's absolutely about what happens to any system when DNS is at play. The more populated the system, the more problematic this can become. So change is needed and it's a good topic to bring up!
I think the problem we see with logging is part of the inefficiency, and while part of that is being addressed now, if you are going after logging (of dns) or dns itself, it's more like a chicken and egg thing to me. I don't care if you decide to boil the egg or fry the chicken first. In the end they both need to be cooked. Why isn't talking about the template and ttl's part of the dns efficiencies improvement discussion. I thought it was. Whether you load the DNS zone into memory in sipx service (it better be a bullet proof thing) and cache the zones locally, the ttl and failover stuff need to be addressed in general. As for the bind views idea, why not use branches for that? There was this idea called branches, which had a great way to deal with gateways and dial plan rules and 911 and all that, but not much has been done with it yet. Fix the proxy logging the erroneus dns queries, fix tls/registrar thing, fix the dns templates, fix the ttl's, fix the performance and efficiency of dns. Which is the chicken and the egg? Introducing bind views (but what about windoze dns, because microsoft simply won't support that at this time as far as I know) is perhaps the best way to deal with it but only on linux So if you are about to suggest bind views for everyone, how will this affect the MS admins who wont run dns on linux and can't support views? Maybe a way to do this onboard with "branches" would be a way to surreptitiously work the bind view management onboard into sipx, but I'm not sure that will satisfy everyone either. So if I am a subscriber and I register and I am assigned to BranchA couldn't I get a different set of results for a sip call and so at the same time couldn't any of my servers get one that is also BranchA? Perhaps. This is a great discussion to have by the way. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
