On 15 Jun 2015, at 17:58, Lei Guo <lei...@huawei.com<mailto:lei...@huawei.com>> wrote:
Updating DNS dynamically may generate security concern in enterprise production environment, even Yarn has its own DNS server. We hit this trouble about 10 years ago for a Linux service management tool we built. Especially when some organization have the DNS server maintained by infrastructure team, and the service management tool is owned by application/platform team, this will be a blocking issue. YARN doesn't have its own DNS server yet. And yes, DNS is at risk of creating conflict. Note that docker's etcd is a DNS server, and of course modern printers and any OSX laptop is running mDNS, which is a multicast DNS protocol. The discussions I've been having with Sanjay Radia, have come around to 1. configure Bind, rather than trying to implement our own DNS protocol. 2. have the DNS server not relay unresolved addresses. It'd be for registry resolution only. 3. Maybe make it a pure ZK -> DNS binding, rather than just yarn-registry only. This would make it even more broadly useful (and ZK would make a nice HA DNS service) 4. keep it optional FWIW many of the big Hadoop clusters all run caching DNS servers locally as it reduces load on the main infrastructure DNS servers, and removes them as a point of failure. -steve
