It is possible to have multiple A records pointing to the IP. It is also possible to have multiple NS records pointing to multiple A records with the same IP. From a management point of view this is a bit unwieldy. Future changes will be more difficult because you will have lots of places that you have to make lots of changes.
A much better idea is to create ns1.maindomain.com and have ns1.maindomain.com listed as the NS record for each domain. That is to have ns1.maindomain.com as the NS records for ns1.domain1.com, ns2.domain.com and so on.
The first name after the word SOA is MNAME, the name server that is authoritative for the zone -- e.g., the name of your name server itself.
The second name, RNAME, looks like a domain name but isn't. It's the string you get if you replace the "@" character with "." in the email address of the person responsible for the zone. (Hopefully your email address doesn't have a "." before the "@".)
For both of these names (and others in zone files) the zone name itself is implicitly appended unless the name ends in a period: foo means foo.example.com, while foo. means foo. A common mistake is to write foo.example.com, which bind publishes to the world as foo.example.com.example.com, when you should have written foo.example.com..
The parentheses allow you to write a resource record that spans multiple lines in your text file. One of the examples you supplied puts the opening parenthesis between the MNAME and the RNAME, while the other puts it after the RNAME, but there's no functional difference.
"IN" specifies the "internet" class, which is the default, so you can leave it out.
Recommended grammar: Follow the wikipedia example and use a tool like dig or dnsq to show what your name server is actually telling the world, instead of spending too much effort second-guessing how bind is parsing your zone file.
Precise grammar: BIND source code. (Only if you're really trying to be pedantic -- not necessary if you're just trying to make your zone file work.)
Official grammar (or at least the internet equivalent of official):
Every zone should have an SOA. If you serve that zone ("authoritative" or not) you should have SOA along with all the other records in the zone. Practically speaking, if you're writing a zone file, put an SOA in there -- and if you're copying the entire zone file from someone else, so you'll get the SOA that way, so you don't need to worry about it.
Best Answer
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.confentries that point to the generic zonefile, egand then a zonefile
primary/example.GENERICwhich says, egAnd 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.