pardon me for the previous response. I could not resist!
This post of yours is a very important one as it expresses, from experience and in IETF wording, what I try to convey from another origin, experience, modelization, architectural logic and culture.
At 02:16 18/05/04, Paul Vixie wrote:
The table is round. Policies are discussed as a group but set individually. The result is a service which has never been "down hard", not ever, not for any millisecond out of the last 15 years. This is "strength by diversity."
This is exactly what French and now Eurospeak call "concertation". The very basis of the emerging European Constitutional culture based upon subsidiarity and granularity. Another less confusing word for English speakers, less related to French specific thinking, and corresponding to the level of the concerned issue is "intergovernance".
Careful design by whom? Organic compared to what? I assure you that f-root has grown by careful design. It's only organic in that we go where we're invited rather than having a gigantic budget that could be used as a leash.
This is what we call subisdiarity. To actively (helping when needed) respect the responsibilities of those depending on (not from) you. I am sure that as F-Root Manager you do not mess within your mirror sites management, but are always ready to help on need.
Check out <http://www.isc.org/ops/f-root/> and the list of mirror sites, and look for some sponsors you know, and call them, and ask why they sponsored f-root and whether they're happy about it. Then find someone in that region and ask them to do "dig @192.5.5.241 hostname.bind chaos txt" and tell you whether they're talking to a local f-root. What could scale better, or allocate resources more efficiently? (Central planning didn't help USSR.)
Right. The only problem "we" (myself to start with, but also several Gov such as Brazil, India, China, etc. etc. as expressed at WSIS and many many others) have is that if Root servers are not centraly planned, they broadcast the same centraly planed and edited file. Also that this central editing imposes constraints due to the 13 limitation. Apart from the political issue, this makes that file and the a-root a world economy, life, security, single points of failure. This is something that the "we" quoted above do not accept.
Who is "we", though? That's always the excluded middle of this debate. I know who I am -- a root operator. But who are "we"? And which of the million different answers to "who are 'we'?" would you like to see govern the choice of "who gets to decide how this stuff ought to work?" E.g., I'm sure, without even having heard it, that you wouldn't want the choice of "who decides?" governed by Dean Anderson's answer to "who are 'we'?"
There is a very good response to that. RFC 883. It says "we" are the users, in saying that no one will be forced to use DNS data he did not chose. It seems a realistic simple way to make the table totally round (or at least rounder): if no one ask for more than the today situation, it is OK. If some ask for more, let them do it. ICANN ICP-3 gives pretty good and reasonable rules about their experimentation and implementation constraints.
In counterpoint, it seems to me that any unified design will make the system subject to monoculture attacks or ISO-L9 capture, and that the current system which you call "unplanned and organic" (but which is actually just "diversity by credo") yields a stronger system overall.
Here is where I disagree: with the "core value" reading (cf. IETF description draft by Harald). You are right about what you say. But this is not to be a creed. This is to be architectural efficiency. This is pure cybernetics - cynernetics as the technical science of autonomous systems (where mathematics are for abstract systems and physics for inert systems). This would probably permit you to agree with Dean on a conceivable common framework where his concerns and your preriquisites would be addressed.
If you'd like to unify something, perhaps it could be DNS client behaviour and network-owner recursive caching forwarder design. And while you're at it, please outlaw those fiendish DNS-based load balancers. f-root should still be a 486DX2-66 like it was in ~1995, rather than fifty 1GHz pentiums, and the 500X load 10 years later is due to client stupidity, not population growth or backbone speed increases.
You are damned right! This is exactly what we try to build right now with the AFRAC project (the DNS root is _not_ the only one concerned, both as a root reference and in the way it is used or can be denied service). We are concerned by DNS, adressing, etc. data, but also by geosocietal and defense information: every information and source code necessary for tier and tier applications (everyone interoperating)
1. first target: distribution of the root machines through a root server matrix and core network - containing local root information to make it a need. Decrease of the pressure, risk containement, new data, new services.
2. second target : a user MITM providing "hardware, software and brainware firewalling". At root system level it means that the user is to cache his root system. The reason why he will do it is that his root system will _not_ be the default public root system. It will be his own version of it, adding his local, private space management and views. Once set-up, calling on the root system would actually pollute his root system, so he will not do it.
Private roots are not subject to DoS. They certainly permit to survive a few hours, days and even probably months. In adding all the root themes we can objectively consider today for ubiquist new services, plus a "first necessity" software kit and root, we are probably talking of an ASN.1 structure of less than 20 compacted K (comparable to anti-virus updates).
The figures I discussed in a previous memo, show that we could then come back to a "486DX2". However discussing of root server the way we consider them today would be quite meaningless.
jfc
PS. I do not consider here the problem of the loggers which is another (mainly legal) issue.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf