>> If this distinction was made at the registry level (as well as >> others), this might help break things into more manageable chunks. Can you please explain? I must be missing something. Is anyone saying that large, flat zones are somehow unmanageable? Sure, doing this with BIND for huge zones is clumsy. However the trend seems to be for using database back-ends to feed the name servers: BIND-DLZ, UltraDNS, ATLAS, ANS, PowerDNS, etc, etc. A database is the right solution for this problem when there's lots of data to look after. Most registries are already using a database for their customer data so it should be a no-brainer to couple that to their name servers. Just think of all the legacy perl and SQL scripts that could be eliminated..... I don't understand why partitioning the name space is going to help. The same data management problems will remain. IMO, they are a function of the amount of data that's under management, not the number of zone files that data gets stored in. Unless of course you're suggesting there should be discrete registries for second- or even third-level domains.