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*<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
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
