This addresses the dhclient part of the question.
A similar problem on another virtualization platform (KVM) seems related to this. In particular, the dhclient dying: in my CentOS 6 based virtualization host, with multiple physical network interfaces, bridges are defined to provide direct (non-NAT ) connectivity from the VM instances to the external network.
It resulted that the server had NetworkManager installed, which is incompatible with network bridges. It kept overwriting the /etc/resolv.conf with is wrong generated version ("mydomain.com" being my actual domain):
[root@myhost]$ cat /etc/resolv.conf
# Generated by NetworkManager
search mydomain.com
# No nameservers found; try putting DNS servers into your
# ifcfg files in /etc/sysconfig/network-scripts like so:
#
# DNS1=xxx.xxx.xxx.xxx
# DNS2=xxx.xxx.xxx.xxx
# DOMAIN=lab.foo.com bar.foo.com
This caused lot of trouble, although, remarkably, the server continued working well in the LAN, despite losing connectivity to any machine not listed in the hosts file - including the whole internet.
Disabling NetworkManager solved the issue. (a service network restart was needed). This is in fact, the recommended way to work - perform settings manually.
This seems to be unrelated to the martians issue, caused by a setting in the /etc/sysctl.conf - although this is a recommended policy (to log the martians), they result too often in false positives, flooding the logs.