I'm using that approach for Reesd. Instead of a single dnsmasq instance on the host, I have one instance (actually a Docker container) for each logical group of containers. Containers can reference db.storage.local and different groups will actually talk to their own database. This is pretty cool for integration tests or spinning a new version of the group before promoting it into production.
Before that, I was using SkyDNS but I was not happy in having to maintain/reset the TTL.
Side note: when you use --dns on a container and commit the result to an image, that image will have the --dns value in its /etc/resolv.conf (meaning that you still have to run a DNS at that address or to provide again --dns to supply a new address).
The idea it that if I have a few containers that need to know each others. Say an application server `app` and a PostgreSQL database `db`. While conceptually I need to spawn only `app` and `db`, I have a script to actually spawn `ns` (i.e. dnsmasq), `app`, and `db`. That script will register the IPs of `app` and `db` into dnsmasq (as you describe in the post).
This means that I can run that script more than once on my laptop and have multiple triple (`app`, `db`,` ns`) side by side without fear of crosstalking between logical groups.
Before that, I was using SkyDNS but I was not happy in having to maintain/reset the TTL.
Side note: when you use --dns on a container and commit the result to an image, that image will have the --dns value in its /etc/resolv.conf (meaning that you still have to run a DNS at that address or to provide again --dns to supply a new address).