It's vaguely possible we'll pursue this eventually, but I doubt it, and any such support is years away.

I don't think DNS is well-suited to the problems you describe. Generally, I think the unpredictable TTL behavior of DNS makes it undesirable for most operations where you have significant control over the response chain. In both situations, it would be better to point wildcard DNS at a loadbalancer and have the loadbalancer know or go look up the correct request destination and route the request there.

This fixes a lot of problems: stuff will work instantly, you can fix stuff instantly (or control the TTL policy for caches), you can switch traffic between releases instantly instead of bleeding it between them gradually as client TTLs expire, you can serve a meaningful response when a sandbox or service doesn't exist, etc.

In the past, I also vaguely entertained DNS as a tool to help with bootstrapping problems. At Facebook, the equivalent of Almanac was called "SMC" ("Service Management Console"), and boostrapping it was complex because the SMC, cache, and configuration layers were intertwined. But I tend to think more careful design is a better solution here, particularly after having deployed the cluster with most of the same mechanisms and none of the boostrapping problems.

Another possible advantage of DNS is simpler access from non-PHP clients, but I think a JSON plain HTTP interface is more promising here, and in modern Phabricator the Conduit API is simple enough that this is reasonable (the older flavors of the API required more work, but the modern one is cURL-able).

I'm just going to close this since I currently don't anticipate ever integrating Almanac with DNS, and if we do such integration is years away.