We do use IP for NFS mapping, but our SUN storage device starts to cry if it can do a reverse lookup, and all of our main NFS storage is on the SUN device.

At that point, you’ve lost any flexibility from using DNS and actually introduced some rather nasty dependencies/recovery scenarios.

For what it’s worth, the NetApp RCU uses IP #’s when deploying NFS datastores.

I agree with @Tony about relying on DNS for “service tier 0″ storage applications. Chicken-egg scenarios are just one of the issues to face: what about DNS poisoning and network failures when the DNS server is more than 1 layer-2 hop from the reliant service end-point?

That said, still I find it best practice to use IP addresses for mount points in NFS and populate DNS and /etc/hosts as well. Since IP addresses only rely on the supporting layer-2 and layer-3 infrastructure to function (and no other service dependencies) it is the only way to provision NFS/iSCSI storage at “service tier 0.” Client end-points – dependent upon a host of other services like DNS, DHCP, file servers, etc. – can use DNS-resolved NFS volumes, but not “service tier 0.” These guys are likely to be the underpinnings of your root file services, DNS servers and DHCP hosts.

In short (and in my opinion), you can’t have critical storage (service tier 0) tied to DNS – it simply opens you up to unnecessary race conditions. That includes ANY primary storage in virtual infrastructures. Sure, your ISO image store, backup volume or template store can be tied to DNS – anything you can stand to be without access to for some reasonable period of time – but not your VM, swap or production data volumes.

Once IP configurations and /etc/hosts updates are part of the “service tier 0″ NFS configuration process, they won’t be forgotten: it’s process. If it’s a one-off “fix” you’re already in deep water…

By the way, dangerous to let this “secret” out of the bag – you’re spoiling the fun for the uninitiated! Once someone gets stung by bad DNS resolution, they will forever think twice about anchoring critical storage to it.

I’d hate to see a “green” consultant disregard the dangers only to leave a ticking time bomb for the end-user the next time an intermediate switch or server hiccups… This is a problem best encountered and successfully conquered in the lab… In fact, it ought to be something that is intentionally “pulled” on the trainee just to develop some respect for the potential problem it could cause.

BTW, I’ve had many questions about this from DIY clients in the past. It always seems to come up because host names are so easy to deal with and IP addresses are not thought of as physically tied to a service. I guess it’s easy coming from an ISP/DNS background to chalk it up this way:

How do Internet DNS servers work? In other words, how does a domain – call it myco.com – resolve when the authoritative DNS servers are dns1.myco.com and dns2.myco.com? Actually, at least one of these hosts (usually both) must be pinned to a host record in the root servers responsible for the domain registry. These records are resolvable regardless if dns1 and dns2 are reachable.

In a 100% virtualized infrastructure, there is no equivalent to a DNS root server (i.e. no physical server sitting outside the virtual hosts) to resolve DNS for NFS. For that matter, no iSNS hosts either (for the iSCSI and FC wonks out there). Any IP storage at “service tier 0″ needs to boot-strap these services with either “persistent” local records (like /etc/hosts) or by IP address directly.

Does all this create a special problem for “service tier 0″ configuration management? Yep. In such case, shrinking “service tier 0″ down to the smallest possible footprint would be wise, requiring a staggered start-up process: bring-up service tier 0, then all other service platforms according to priority and serviceability. For my infrastructures, switches, routers, storage and hypervisors that host mission critical workloads comprise “service tier 0″ and are prioritized in that order (OK, I like OSI approaches).

It would be interesting to hear how other pros have dealt with this issue…

nice “lab” btw….

NFS + ESX + DNS = disaster waiting to happen