The containers system currently in production at dotCloud relies on a templating mechanism to setup a bunch of files before containers are actually started; namely:

• /etc/hostname
• /etc/network/interfaces
• ... some service-dependent configuration files ...
• /etc/resolv.conf

Almost all this templating magic can be waived a way or another (e.g., network configuration can be done "from outside" by Docker itself, instead of relying on inside-the-container distro scripts).

However, one item remains: /etc/resolv.conf. If we want the container to be able to do any kind of DNS resolution (and we probably do!) we need a valid /etc/resolv.conf.

Here are a few facts:

• if /etc/resolv.conf does not contain a "nameserver" entry (a fortiori if it's empty!), it will try to talk to the local DNS server (i.e. 127.0.0.1)
• the resolver behavior used to be override-able with e.g. RESOLV_HOST_CONF, but that was before the days of NSS
• /etc/resolv.conf can be itself completely bypassed by /etc/nsswitch.conf (the Name Service Switch master configuration file, which lets people enable NIS, LDAP, etc. for getpwnam, gethostbyaddr, and other resolving functions)
• AFAIK there is no default configuration for nsswitch.conf (i.e. if it's empty, the system will probably be unusable)

Its' safe that >99% of the systems out there are setup to use /etc/resolv.conf (with <1% with LDAP etc.), so the overwhelming majority of systems will work if we override /etc/resolv.conf. This can be done in multiple ways:

• if / is a writable (e.g. AUFS) filesystem, just overwrite /etc/resolv.conf
• if / is read-only, update the base image, so that /etc/resolv.conf will be a symlink to a writable place (e.g. /tmp/resolv.conf)
• bind-mount a pre-generated resolv.conf file over it (yes, you can bind-mount a file over another one!)
• make sure that /etc/resolv.conf doesn't exist, and setup "something" to listen on *:53 and relay DNS queries to a proper resolver

Generally speaking, the issue might arise with other configuration files. However, this should be fairly limited. There is a vast amount of knowledge out there about operation of disk-less UNIX systems, using e.g. read-only NFS root filesystems. Such methods exist since the 90s and all decent distros even have hooks to support read-only rootfs operation. I expect that exceptions would stem from brain-dead vendor binaries assuming some configuration file to be located in a hard-coded location (e.g. /etc/foo.conf or /opt/foo-1.0.42/etc/foo.conf).

For now, I tend to favor the bind-mount option, since:

• it doesn't involve AUFS
• it doesn't involve templating (the resolv.conf file ought to be the same for every container)
• it doesn't involve changing the base layer (as long as it contains a resolv.conf file)