I could be wrong, but one issue I see is that zone data seems to be a part of configuration (there is some indirection with `flattenRecords`, but still). I real

I could be wrong, but one issue I see is that zone data seems to be a part of configuration (there is some indirection with `flattenRecords`, but still). I realize it's probably intentional in the name of simplicity, but this would prevent you from e.g. persisting received updates. I suppose I'm not the only weirdo out there who manages my DNS records with plain `nsupdate(8)`... Unless this contradicts your goals, I would say zone data should be independent from server configuration. Also, I could be wrong about the design again, but on a quick glance it looks that because `app.Records` map is keyed only by the record name it seems that it's not possible (or at least not trivial) to have multiple different types of records for the same DNS name. For example, most of my zones have at least SOA, NS, A, AAAA, MX and TXT (and DNSSEC stuff if the TLD supports it) at their root. I suspect the idea is that `config.Record` is an universal record that tries to encompass all possible data into one superstructure (e.g. it seems that it can represent and A and AAAA simultaneously), but I don't think this would scale well. And TXT records can be particularly messy - there could be a real need to have more than one for the same DNS name (e.g. SPF record AND "google-site-verification" record). All of this is based only on a Sunday evening quick cursory glance of an interesting project - so please forgive me if I got something wrong.