>>>>> "Jay" == Jay Daley <td(a)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.
