...

...

...

...

"Jay" == Jay Daley <td@nominet.org.uk> writes:

>> 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..... Jay> I'm not so sure that I agree with this. I think there is Jay> quite a lot to think about here and databases are not Jay> necessarily the best solution. Jay, I think you have misunderstood me. Or I didn't make myself clear enough. You're quite right. Using a database back-end for DNS service introduces a lot of interesting issues such as throughout, how replication gets done, consistency between the database and any in-core cache, the database becoming a SPoF, etc, etc. However the initial discussion was about restructuring the name space because large flat zone files were felt to be harder to manage than introducing second- or third-level domains. In that context the problem is essentially one of data management. Which would already be handled by the database that any sizeable registry will be using for their customer data. That said, I do believe that huge text files for zone files and name server configurations will eventually move to some sort of database back-end. This is the direction that most DNS implementations seem to be moving towards. Some TLDs have already adopted this approach and I'd be surprised if others didn't follow.