On Thu, Jun 16, 2011 at 12:01 PM, <[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/ > I don't necessarily agree with adding a sipx service to cache nameserver records. If it were designed properly perhaps, but this somewhat borders on bloatware. We've got DNS and caching DNS, so lets add a sipx specific service? I understand and agree with the premise, but there are other things I think should be worked out first, and here's why:
the tls lookups will stop if we add the records. If we add the TLS records the registrar fails. Why does the proxy compmain about it when it is not there if we are not using it (yet). When we do use it it should not affect the registrar service. There's already a JIRA for that so I'll leave that alone. Why does the proxy complain about the A record for the sipdomain.This one has always boggled me, because you can put DNS into manual and add it to get it to stop complaining, but this is a sel-defeating action if you roll out HA. I think the logic in the proxy to decide what should be there, and at what level it should be logged is a good idea, but if we are not logging it at a default level and the errors are still there, we simply make it more difficult to troubleshoot real problems. It also indicates a waste of system resources whether it is logging or not because it's computing this output and its not necessary. I think a better failover mechanism for DNS is warranted though. there have been enough discussions with HA users on "why does it take xx minutes" for my failover to work. When the failed server comes back online, why does it take so long to become active. Part of this is made better if DNS was configured properly, except the current templates don't have realistic values for HA (ttl) as I understand it. Why not create a different template that gets invoked if its an HA environment? TLS (and rr) stuff ought to be sorted out. I think the TLS stuff is on the carving block now, so to speak. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
