[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: initial thoughts

At 15:35 03/04/02 -0800, Paul Hoffman / IMC wrote:

At 9:04 PM +0000 3/31/03, Adam M. Costello wrote:

Will it scale?

Absolutely. As long as the zone's name servers can serve the records, there is no problem. Even if the database is kept on disk instead of in RAM, the response time on modern computers for even a gigantic zone is low relative to typical network delays. There are also other mitigating methods for huge zones, such as partitioning the responses on different servers at the same address. The VeriSign folks have already done a lot of research on this for the .com zone.

I would want to call for extreme caution here. VeriSign definitely has managed this. But is their experience fully documented? Is it reasonable to assume that an average cctld will be able to manage it? And are the scales the same? The .com zone contains one entry per registration only, and is already huge. Now assume that .com uses some table generating mappings. This will blow up the .com zone, potentially to a size of a completely different magnitude.

  The combinatorics are exponential.
I think the only way it would work well is if the authoritative DNS
servers (both the registry's servers that delegate the name, and the
registrant's servers that provide the data for the name) include support
for the grouping.  I guess you would supply the tables to the DNS
server, and it would perform the group-id computation whenever a request
comes in, then look for the group-id in the zone database.  This would
require a standard machine-readable format for describing the grouping
policy for a zone.

We disagree here. I don't see that requirement at all. As the managers of the current large zones have shown, you can have gigantic zone files.

Even at 'gigantic', there are still huge potential differences. The earth is gigantic, from a human point of view. Yet the solar system is much more 'gigantic'. And then there is the galaxis, and on top of that the universe.

You could also imagine that the registry, rather than the registrant,
chooses which member(s) will be visible, but I think it would be
difficult for registries to come up with rules that would please
everyone; it would probably be easier to let the registrant choose, and
simply store the list.

Speaking of "scaling", your suggestion makes scaling harder. That is, the registration process would have to include a step where the registrant chooses some things from a list. This is much more difficult than the registry saying "here's what you get, you can contact us if you don't like it". Well, of course they won't like it, but at least the process isn't blocked.

Well, in many cases, it would actually be very easy. The registrant inputs the label s/he wants, and that's what is entered, and the rest is blocked. Some kind of confirmation would be needed, of course.

Regards, Martin.