How can I manage all of my domains with minimal configuration?

Unless I'm misunderstanding the question, I do this regularly with BIND, and it seems to be fine as long as each zone is absolutely identical.

On my primary nameserver, I have named.conf entries that point to the generic zonefile, eg

zone "example.com" {
        type master;
        file "primary/example.GENERIC";
};

zone "example.co.uk" {
        type master;
        file "primary/example.GENERIC";
};

and then a zonefile primary/example.GENERIC which says, eg

;; Start of Authority
@       IN      SOA     ns.teaparty.net. dns.gatekeeper.ltd.uk. (
                        2004091201      ; serial number YYYYMMDDNN
                        28800           ; refresh  8 hours
                        7200            ; retry    2 hours
                        864000          ; expire  10 days
                        3600 )          ; min ttl  1 day
;;
;;      Name Servers
                IN      NS      ns.teaparty.net.
                IN      NS      ns2.teaparty.net.

And I'm not aware of any problems with these zones at all. I'm open to being told that I've misunderstood the question, or that my domains in fact don't work, but until then I think it works for me.

Note that you cannot pull the same trick on the secondary; each zone will require a different file to be stored in. But since the contents of that file will be populated and kept up-to-date by zone xfers from the primary, this isn't a huge deal.

There are a number of shortcuts you can use to make your life easier:

If you use Bind or similar software that uses files to store the zone data: point your zones to the same file for example:

zone "example.net" {
    type master;
    file "/etc/bind/zone/default.zone";
};

zone "example.org" {
    type master;
    file "/etc/bind/zone/default.zone";
};

Because you can make use of certain DNS shorthands you can create a universal zone file:

$TTL 1h      ; default expiration time of all resource records without their own TTL value
@  IN  SOA   ns1.example.com. username.example.com. ( 
                               20140218131405 ; Serial number YYYYMMDDHHMMSS
                                        28800 ; Refresh     8 hours
                                         7200 ; Retry       2 hours
                                       604800 ; Expire      7 days
                                        86400 ; Minimum TTL 1 day )
@             IN  NS    ns1.example.com.      ; ns1.example.com is a primary nameserver
@             IN  NS    ns2.example.com.      ; ns2.example.com is a backup nameserver
@             IN  MX    10 mail.example.com.  ; mail.example.com is the mailserver
@             IN  MX    20 mail2.example.com. ; the secondary mailserver
@             IN  A     192.0.2.1             ; IPv4 address for the bare domain
              IN  AAAA  2001:db8:10::1        ; IPv6 address for the bare domain
www           IN  A     192.0.2.1             ; www.domain
              IN  AAAA  2001:db8:10::1        ; IPv6 address for www.domain - note by starting the line with a blank it becomes the continuation of the previous record and this IPv6 record applies to www
wwwtest       IN  CNAME www                   ; wwwtest is an alias for www

This makes use of the fact that the hostnames in zone files that don't end with a dot . are always expanded with the $ORIGIN which in turn is implicitly set to the zone name. And @ is short-hand for the $ORIGIN.

Rather than maintain individual zone files by hand, enable a method interact programmatically with your name servers.

I've used PowerDNS which allows for a RDMS as a back-end which fit in very well with the LAMP stack we were using at the time. Cloud Services like Amazon Route 53 also expose web-API's.

But even venerable Bind also supports dynamic Update which is a method for adding, replacing or deleting records in a master server by sending it a special form of DNS messages. The format and meaning of those messages is specified in RFC 2136.

Dynamic update is enabled by including an allow-update or an update-policy clause in the zone statement. For more info check the Bind Administrator Reference Manual.

Short Answer

If you're looking for a "zero configuration" setup in BIND, it doesn't exist. Setting up a root zone (.) seems like a good idea, but it's not, and you need to find a solution that doesn't involve breaking DNS to suit your needs.

Long Answer

We've been getting variants of this question several times in the past year.

The answer is pretty simple here: you can't set up a single zone definition. Any software that lets you define or otherwise synthesize multiple SOA records in this context is broken software, and doing broken things is not on topic for ServerFault. You either need to choose DNS software that makes this management simpler for you, or you need to come up with a different strategy that does not involve this particular shortcut.

There are definitely some tricks you can use to make life easier...using BIND as an example, it's fairly commonplace to define multiple zones that all reference the same template zone file. This is perfectly legal and validation software will find nothing wrong with it: see MadHatter's answer. Most people pass over this solution because it's still "too much work" to add a zone declaration every time a new domain is acquired, but there is no "configure it once and walk away" option for this kind of hosting.

Newer versions of BIND support an option called allow-new-zones that will let you dynamically create zone definitions on the fly via the new rndc addzone functionality. You might want to take a look at this and see if it fits your needs.

Other than that the suggested solutions, your options are somewhat limited. Sometimes you're just stuck with doing the work if the software doesn't do things the way you want it to.