<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I think the key thing here is to understand the impact on the telephone system if DNS services go away and to plan accordingly. DNS is already providing a critical component of the campus IT service infrastructure, but tying a DNS failure to a phone system failure likely wont compute on many levels. If there aren't several layers if redundancy built in to your DNS solution, this may be the time/reason to suggest it. Minimally, the management team that owns the service(s) must be aware if the new dependency. This is most important when planning extended outages in the DNS service for patching/upgrades/hardware maintenance. </div><div><br></div><div>That being said, still not 100% sure on exactly how a DNS outage will affect service. </div><div><br></div><div>We enabled it because of our hope to implement SIP technologies soon which rely heavily on DNS. However, we were sure to continue using IP addresses where possible, e.g. server names. </div><div> </div><div>Lelio</div><div><br>Sent from my iPhone...<div><br></div><div>"There's no place like 127.0.0.1"</div></div><div><br>On Mar 19, 2013, at 9:51 AM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com">avholloway+cisco-voip@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div>The Cisco Voice products have come along way in the last few years and can do some pretty amazing things. I would think something as basic as DNS would be trivial for these products.<br><br></div>Perhaps the best practice to remove the DNS dependency is a bit dated. But how are we ever going to know how well it performs at large scale and under heavy load if everyone is adhering to the best practice? If the product officially supports it, and Cisco will support your solution, then I say use it.<br>
<br>On the flip side, this wouldn't be the first documented best practice item that has gone untouched for years, in which customers are going against the grain.<br><br></div><div><div style="margin-left:40px">E.g., In UCCX the default maximum number of executed steps is 1,000, and we are told to never touch this value. However, in my experience, this number is increased in production environments quite often, and thus the best practice is intentionally ignored.<br>
</div><br></div><div style="margin-left:40px">"The customer should not change the “max number of executed steps” parameter unless instructed by TAC."<br></div><div style="margin-left:40px"></div><div style="margin-left:40px">
<i>Source: <a href="http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_9_0/reference/guide/UCCX_Best_Practices.pdf">UCCX 9.0(1) Best Practices</a></i><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cisco-voip mailing list</span><br><span><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a></span><br><span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br></div></blockquote></body></html>