your points would be well taken if we were talking of the same thing (you will note that I was very carefull quoting ICP-3). When was the last time IETF discussed the way to respond ICANN's ICP-3 call? (what I am try doing). There is a resulting difference of perspective.
- I talk of real world when you talk of the current (unsecure and overloaded?) implementation of the current DNS architecture.
- I do not want to fix the DNS, I want to free me from it: it was not designed to support the current load and it is not managed in a way the Govs will ultimately accept. So, trying to patch the broken current usage to make it work as before is of no real interest. At least IMHO. [I have a user' side point of view].
The problem we face is an old and too large unique system with a robust yet overloaded engine. With all the problems which come with it. We have to split the zones of usage and risks. Either it is planned by IETF or it is done by the users. I suggest it is done together.
The novelty of Titanic were waterproof compartiment. Yet she sunk. The world has an unique DNS zone today.
Let me review the points where we fully agree and how.
On 21:34 18/05/04, Måns Nilsson said:
--On Tuesday, May 18, 2004 18:01:05 +0200 jfcm <info@xxxxxxxx> wrote: > 1. first target: distribution of the root machines through a root server > matrix and core network - Yes, this is already done. It works, even if it is not top-guided as you envision.
I do not envision it as top guided. What we plan is a service of a few separate machines, collecting the national root matrix data (meaning: all what is national and above) and concerting towards a unique version, among themsleves and with other national equivalent agencies. (NB. this concerns DNS among many other real time distributed mutually managed directories).
Let take an example, there is a unique time in nature. Yet there are many reference clocks in the world, and that does not work badly.
Then the agreed file will be made available to 10 to 250 regional master root severs (one by local business area - probably paid by cities - to support the addition of the local data),. We do not think DNS control and machine power, we think surety, security, stablity, distributed servicing. Ultimately this means probably a national coverage of 1000 machines With the same global and national data.
> containing local root information to make it a need. Decrease of the pressure, risk containement, new data, new services.
This is unnecessary and prone to failure.
Right. But this is as unnecessary as liberty.
Prone to failure? OK, but failure on what ? Today the big failure is that we are not free to chose and to develop. The system is not RFC 883 compliant. I cannot chose my data. The root system is not IETF core value compliant, decision is not on the edges.
Anyway, you can chose the directory system you want. If you do not like it you do not use it. The only rule is (well worded in ICP-3) not to pollute others' space. The DNS root is a 15 K (compressed) file you can update every three months without losing access (but for some ccTLD like mine because ICANN does not want to enter a third/forth secondary) and RIPE does not want to respond ...
> 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.
Which part of the present caching resolve server does not provide this service today? Aren't you reinventing the wheel here?
:-) We do not speak of the same thing here. You only refer to the 15 K root file and to the 20 years old way to use the internet.
If you want people to change their poor habits, you can only propose them better ways for you as part of better services to them. Cache is of no use for them, it is of use for you. Let clarify what you want, and what they want. Let not just continue an old solution because you did not think of something new and better.
You want to reduce the calls to your system, right? Let stop the "cache" idea which is something of _your_ system ibn theirs, and propose them an update of _their_ system - like anti-virus updates (ever heard that anti-virus run huge 50x1G systems? And let discover what a user system can bring more to its user owner. So when the user has started using and enjoying _his_ system, you will obtain what you want.
> 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).
Private roots are subject to confusion, mis-directed micromanagement by local admins, overly sensitive to local politics, split-vision of what must by design be unified, and endless user frustration. I have tried this in a large corporate network, and it was, even there with a clear chain of command, a horrible mess. Never, ever again will I take anything like it outside a lab (except to kill it)
We are not talking of the same thing. You talk of a system where you have admins. Bloody centralization :-) Are you asking GWB everytime you want to call a friend on the phone ? This is what some people do on the DNS and we want them to stop. Calling on the rrot is like calling an operator. Do you do it often ? I is not the nightmare of creating, training and managing an Operator Corp with local branches.
How many times a year do you call an operator ? How many times a year do you think you really need to update your root file?
> 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.
You have a strong passion for doing something to fix the DNS system. I suggest you channel this passion towards trying to fix all the b0rkened clients (cf. the studies of root server load refered to earlier here) before you try to impose breakage onto the well-functioning root server system.
I am sorry. But I have a strong passion for restoring the name space the way we created it and the way the users need it, as par of the many tools and services necessary to support networked interoperations. The DNS concept is good and can partly do it, if it is not centralized. The root server load is purely an architectural illness. That illness is due to the fear of pullution. For years IETF and ICANN saw the question as "do we want to risk pollution or do we want to risk critics from civil rights and from open roots opponents?"
The question today is "do we want to risk a total collapse of he network and a forced quick and disorganized innovation or to eventually accept that innovation is necessary and to smoothly work towards it", according to ICP-3 which calls on IETF fro experimentation ? Again IETF does not respond. Fixing the broken architecture is the only way to fix the broken clients - unless you get a cop behind every user (and it will not work because there will be too many cops plus too many clients).
Take care. jfc
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf