> - I talk of real world when you talk of the current (unsecure and > overloaded?) implementation of the current DNS architecture.
In what way overloaded? Do you have any pointers? Proof? Data?
Dear Kurt Eric,
Let not play this, please. Either you think after careful personal study (or you believe) that the current system is the best solution the world needs, and that it only calls for some users to be more educated in using it - and we are on planets apart. This is fine with me, and the end of a non existing debate.
Or you think the DNS does not match the IETF "core values" in being centralized (I do not make that "core value" as described by Harald a creed, I think they are often outdated, but I fully agree they are a technical minimum). And, together with ICANN, you think IETF is the right place to respond ICANN's call for more (ICP-3). So you try to understand the problem and to imagine solutions. This is what we did. And I explain the solutions we are subsequently working on.
> 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.
Again, overloaded engine in what way?
I just report on our follow up on this premise. If you do not see it, I cannot help with details. Just with the alternative. Yu are the judge.
The DNS "engine" is made of all the root/name servers and resolvers.
- either you are satisfied with their present tools, organization, limitations and resulting service, then again I cannot discuss it.
- or you are not, and then the question is to know if your disatisfaction results from the used solution or from the way this solution is implemented.
IMO the problem is not with the solution (software) but with its architectural deployment and usage. This permits a smooth transition, using existing and proven building blocks and expertise. But I think that speed if the essence. One may also disagree.
> Then the agreed file Agreed by whom? In what way?
Let me elaborate quickly. The target is not to obtain a file which pleases anyone as today, but a file which reports on the TLD Managers entries. So, the point is not who does it but the number of identical independent results. What follows is for one single national service.
- National because of the legal and political aspects in many aspects (risk containment, sensitive information intelligence leaks, justice obligations, etc.).
- But subsidiarity applies to the regional, local, corporate, private granularities (I explained what this means in my first mail).
- this means that security and verification will probably repeated 20 to 50 times accross the world. Once a day in each country could mean every hour for global issues such as the DNS (the protocol is the same for every root information [time, radio frequencies, weather, hospital situation, etc])
The process we retained is to have at least four different independent data collection processes (whatever the processes, starting with a simple duplication of the NTIA file in the case of the DNS legacy root). The reason for at least 4 is to have at a majority if needed, even if one is down.
There must be five conditions for the result to be accepted (there could be more?)
1. there must be no reported alarm (nominal situation) on our monitoring system
2. all the results must be identical
3. there must not be an abnormally large difference with preceding copy (variance max to be tuned from experience) - to allow reasonable updates if permitted.
4. visual review by the four collection managers is positive
5. there must be no significant (similar to 3) with other partenering root files on common part of the root matrix.
If these 5 conditions are not met there will be an investigation and concerted agreement to be reached among collection managers, or a "no go" and escalation to Execom and to BoD (or Gov). These conditions (or more) can be made legal and imposed before a State endorses a Root Service for its own use and for legal transactions.
There is a possible alternative: the decision of the Government in case of national vital crisis. The role of the collection managers will be to advise how to reduce pollution in such cases - this may call for international concertation [exemple: the "ambassador lounge" at ITU (telephone is real time, no 48 hours delay). A doctrine is to be set-up as part of Digital Warfare (US say Cybernetic Warfare). Experience in Mines, Electronic or Nuclear Warfares shows this is possible.
> 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.
Why would I want to reduce the number of calls on my system? My system is doing just fine...
What is your system ?
In the case discussed the problem is the current increasing load on current servers. That load and that type of calls are inappropriate. The architecture is to be changed (all the more than it permits DoS). Keeping daily updated files of much larger size than the root file is carried by many people around the world more efficiently, more securely and with less of constraints to innovative usages.
But again, the very nature of the DNS permits such transition to be transparent. So if you love the current architecture, it is OK with me. As long as you do not pollute what we do and we do not pollute what you do there is no problem. This discussion only concerns those (with ICANN ICP-3) who want to experiment and work on the resulting experience, towards a better response to the people and Gov demands.
I just describe what we have started working on, with scarce resources, along those lines for more than two years. And what we target from then on.
jfc
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf