How about ISC-style like for BIND? * https://bind9.readthedocs.io/en/latest/reference.html#configuration-file-grammar https://bind9.readthedocs.io/en/latest/re

How about ISC-style like for BIND? * https://bind9.readthedocs.io/en/latest/reference.html#configuration-file-grammar https://bind9.readthedocs.io/en/latest/reference.html#config... * https://wiki.debian.org/Bind9#File_.2Fetc.2Fbind.2Fnamed.conf https://wiki.debian.org/Bind9#File_.2Fetc.2Fbind.2Fnamed.con... * https://www.zytrax.com/books/dns/ch7/#overview https://www.zytrax.com/books/dns/ch7/#overview I've been experimenting with NSD (and Unbound) recently, and their configuration is JSON-like. There seem to be some 'arbitrary' attributes that are treated as "top-level": > At the top level only server:, key:, pattern:, zone:, tls-auth:, and remote-control: are allowed. These are followed by their attributes or a new top-level keyword. The zone: attribute is followed by zone options. The server: attribute is followed by global options for the NSD server. […] * https://nsd.docs.nlnetlabs.nl/en/latest/manpages/nsd.conf.html#file-format https://nsd.docs.nlnetlabs.nl/en/latest/manpages/nsd.conf.ht... It seems to be good/best practice to indent the sub-attributes of the 'top-level' attributes to know where the 'stanzas' for each top-level start and end. The white space has no significance. While I like the functionality of NSD/Unbound, I lean toward liking the use of braces (curly brackets; {}) à la BIND to explicitly denote stanzas and statements, even if one also uses indentation for human consumption.