This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[dns-wg] Elimination of 2nd level ccTLD domain names
- Previous message (by thread): [dns-wg] Elimination of 2nd level ccTLD domain names
- Next message (by thread): [dns-wg] Elimination of 2nd level ccTLD domain names
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jay Daley
td at nominet.org.uk
Sun Oct 24 20:13:28 CEST 2004
Jim Jim wrote on 24/10/2004 04:46:51 pm: > 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'm not so sure that I agree with this. I think there is quite a lot to think about here and databases are not necessarily the best solution. The reasoning goes like this: - You don't want all of your database data replicated to each node, that would be pointless, just the data required to fill the zones. This is actually a very small fraction of the data we (and most registries?) hold. So you then end up with a database system on each nameserver for a relatively small amount of information and almost all of the functionality of the database is not used. - You then have to manage another system on each nameserver, and that brings with it a new set of dependencies and vulnerabilities, that you could just as easily do without. Out view has always been to minimise the number of unnecessary processes on any production nameserver. - Then of course there is the replication process. Some databases are good but IXFR is uniquely designed for nameservers. Having the replication process so closely tied to the database concerns me that problems with that process that require it to be fixed can lead to unneeded downtime on your main database. If each of your nameservers instances is going to have multiple heads then you might get better performance with a database backend serving all those heads rather than relying on nameserver replication, but I've not done the tests. Some of this is, of course, supposition so I would be interested to know if anyone else thinks using database in this way is simple. Jay
- Previous message (by thread): [dns-wg] Elimination of 2nd level ccTLD domain names
- Next message (by thread): [dns-wg] Elimination of 2nd level ccTLD domain names
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]