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/
