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/dns-wg@ripe.net/
[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 ]
Jim Reid
jim at rfc1035.com
Sun Oct 24 17:46:51 CEST 2004
>> 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.
- 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 ]