Tony, I think we also need to think about these server and client DNS needs as different items. We've lumped server needs and client needs together to simplify our teaching of DNS... but in reality the needs of the servers and the needs of the clients are different.
For instance, the clients do not need to know about RR records. The servers do not need to know about NAPTR records, etc. So if a Windows admin wants to use their windows server for their phones, that's fine. But inter-server and inter-process communications are different. If the servers can control their own destiny, they are more reliable than if you have some other admin blow away the RR folder under the sip domain because they don't know what it is. Mike On Thu, Jun 16, 2011 at 1:56 PM, Douglas Hubler <[email protected]> wrote: > Agree w/ Tony on a lot of his points. Let's fix the easy things first > and later, if we want to shave some more performance, consider caching > dns in the application layer with what would have to be a rock-solid > implementation. > > On Thu, Jun 16, 2011 at 1:27 PM, Tony Graziano > <[email protected]> wrote: > > 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. > > Having dns views seems so elegant that it seems we cannot, not > implement that. We'll have redundant voicemail before long and the > thought of find every place in the FS code that does a dns query to > consider a "branch" concept would be an enormous burden. Some windows > guru will find a workaround i'm sure. > > y, great discussion. if nothing else, i now know local dns caching > server is mandatory for non-bad things. > _______________________________________________ > 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/
