Other countries in Europe already do this, at least including Belgium, Netherlands, France, and Germany.

Denmark, Sweden, Italy, Spain, Portugal, etc. They all followed the example that I set with .nl in 1986. Some now work with a mixture of 2nd and 3rd level domains.

Nevertheless, given the size of the population of the expanded EU, I don't see how this kind of scheme will scale well to handle potentially hundreds of millions of people.

I don't think there's any need for that. What would private persons gain by registering <myname>.eu instead of <myname>.<ccTLD>? Adding something .co.eu (which the EU policy already rules out) or .com.eu wouldn't really alleviate the perceived problem.

I don't think you necessarily need to go to a US-style city.county.state.us mechanism

That's counterproductive: moving from one city to another, which is quite common for private persons, would imply a new domain name...

but I think a three-level domain scheme would definitely be advisable.

It might be worth considering, but advisable? Not in my view. Piet

At 1:05 PM +0200 2004-10-24, Iljitsch van Beijnum wrote:

For instance, see http://www.nominet.org.uk/Statistics/RegistrationStatistics/ Around 90% of all registered .uk domains are .co.uk domains.

Anyone know what the distribution of company sizes are for those registrations? I ask because, at least in Belgium/France/Netherlands there are two overall types of companies that you can create -- SA/NV and sprl/bvba. Pretty much anyone can create an sprl/bvba company, but there are some pretty hard requirements you have to fulfill before you can legally incorporate as an SA/NV. If this distinction was made at the registry level (as well as others), this might help break things into more manageable chunks. This is just one idea, of course. I'm sure that there are many others which might be interesting, if only you'd give people a chance to discuss them before shutting them down. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

>> 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.

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

At 4:23 PM +0300 2004-10-25, Yiorgos Adamopoulos wrote:

Actually you do not have to run a database instance on every node where you want to run a DNS server. Why not have the Database system produce the zone files for the nameserver of your taste (be it NSD, tinydns, BIND, etc) and then rsync to the actual servers?

Well, for NSD, using large zones will cause it to eat memory exponentially. It pre-calculates all possible questions and all possible answers before it loads the zone(s), and then creates a jump table. I remember at RIPE 44 that we got a report from the folks up at SUNET, who had tried using NSD to serve the ccTLDs they handle, and even though it was a monster machine with many gigabytes of memory, that still wasn't enough. BIND will probably be better in this respect, but I doubt it's going to be manageable, either. If you're bound and determined to go with a completely flat namespace for what will be the largest TLD in the world (Europe already has more citizens than the US, more citizens online than the US, and a faster growth rate than the US), then I think you have no option but to go with a database back-end for operations as well as maintenance. Sure, in a few years the Chinese or Indians may take over the #1 position (since both countries have unbelievable growth rates and over one billion population each), but that's still several years away and they can always look at whatever solution Europe has pioneered to handle these extremely large ultra-flat zones. Of course, your operational database could be trimmed to just the absolutely necessary information and loaded non-real time from the maintenance database which does include all the desired information, but that's still going to be a big database. I doubt that you're going to have any practical option but to use ANS from Nominum. NSD certainly isn't going to cut it, PowerDNS certainly won't cut it, I don't think that BIND will have the necessary high-reliability interfaces, and I don't know of any other large-scale database back-end nameservers (dlz-bind is a nice toy, but certainly won't be able to scale to this kind of level). That is, unless you want to hand everything over to someone else to operate as a service for you -- like UltraDNS. Oh, wait -- they bought the business from Nominum, who was using ANS for their customers, and UltraDNS almost certainly still using ANS today.... -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

At 6:14 PM +0200 2004-10-25, Piet Beertema wrote:

Why do you keep ignoring the existence of ccTLD's in Europe?

What on $DEITY's green earth makes you think that I'm ignoring the existence of ccTLDs in Europe?!? I have been talking about nothing *but* ccTLDs in Europe, and how this flat namespace model will not continue to scale.

Plus the fact that a generic, worldwide and *flat* TLD like .com still hasn't grown such as to become unmanageable?

It has grown to the point where it is not manageable. It was unmanageable a long time ago, and things have been going further down the toilet ever since. And you're going to have a problem that will be an order of magnitude larger than .com. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

On Mon, 25 Oct 2004, Brad Knowles wrote:

Oh, wait -- they bought the business from Nominum, who was using ANS for their customers, and UltraDNS almost certainly still using ANS today....

# perl fpdns.pl udns1.ultradns.net udns2.ultradns.net fingerprint (udns1.ultradns.net, 204.69.234.1): UltraDNS v2.7.0.2 -- 2.7.3 fingerprint (udns2.ultradns.net, 204.74.101.1): UltraDNS v2.7.0.2 -- 2.7.3 jakob

On Mon, Oct 25, 2004 at 04:29:39PM +0200, Brad Knowles <brad@stop.mail-abuse.org> wrote a message of 63 lines which said:

It [NSD] pre-calculates all possible questions and all possible answers before it loads the zone(s), and then creates a jump table.

It is not entirely true since version 2.0 (ns2.nic.fr runs 2.1.2). It was the original algorithm but it was changed to accomodate DNSsec where a default reply of NXDOMAIN (for every domain not found in the jump table) was not a proper reply. See http://www.nlnetlabs.nl/nsd/

I remember at RIPE 44 that we got a report from the folks up at SUNET, who had tried using NSD to serve the ccTLDs they handle, and even though it was a monster machine with many gigabytes of memory, that still wasn't enough.

ns2.nic.fr is a secondary of ".nl" (the largest zone it serves) and of many in-addr.arpa subdomains and ccTLDs. It serves twelve millions records. Here it is (see VSZ and RSS for its memory consumption): USER PID %CPU %MEM VSZ RSS TTY S STARTED TIME COMMAND nsd 209888 1.7 18.4 669M 564M ?? R 15:26:03 0:22.27 /usr/local/sbin/nsd -a 192.93.0.4 -a 2001:660:3005:1::1:2 -n 4

Brad,

I think that's the scale of problem that is facing us with a flat .eu zone, and far more rapidly than anyone here is giving credit.

my impression is we're about to enter an infinite loop. Your view of how fast and how large a EU TLD may grow seems rather ``optimistic'' and is probably not shared by many in this group. While still you might be right, we would now have to discuss growth rates based on market potential etc. But then, I don't see where having this discussion on this particular list would lead us. -Peter

On Mon, Oct 25, 2004 at 04:29:39PM +0200, Brad Knowles <brad@stop.mail-abuse.org> wrote a message of 63 lines which said:

Well, for NSD, using large zones will cause it to eat memory exponentially.

Here is the NSD maintainer's analysis: http://open.nlnetlabs.nl/pipermail/nsd-users/2004-October/000276.html

Brad Brad wrote on 24/10/2004 02:58:15 pm:

At 1:05 PM +0200 2004-10-24, Iljitsch van Beijnum wrote:

...

For instance, see http://www.nominet.org.uk/Statistics/RegistrationStatistics/ Around 90% of all registered .uk domains are .co.uk domains.

Anyone know what the distribution of company sizes are for those registrations?

We have not been asking for those details for long enough to have a firm answer. In addition we suspect there is some distortion caused by companies that put themselves down as private individuals in order to opt-out of the whois. Maybe in a year or so we might be able to start publishing those figures, after we go through a major data restructuring exercise.. BTW we breakdown the organisational type into 13 different categories! Jay

On Fri, Oct 22, 2004 at 12:40:58AM +0200, Lasse Jarlskov <lasse@jarlskov.dk> wrote a message of 19 lines which said:

I always thought that ccTLDs could only be assigned if they are on ISO-3166-1. Indeed thats what http://www.icann.org/icp/icp-1.htm says.

And before that, RFC 1591. But both these documents do not handle the case of disappearing countries (see .SU and .YU). Most Internet users want stable names and therefore would not agree with the disparition of a domain.

Yet, acording to http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/lis... EU is not on that list.

Rules always have exceptions :-) In Europe, see .AC, .GG, .IM and .JE, which are in the root but were never in ISO-3166 (I always mention this when people say that things were better with Jon Postel).