This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/dns-wg@ripe.net/
[dns-wg] Re: ORSN-SERVERS.NET
- Previous message (by thread): [dns-wg] Re: ORSN-SERVERS.NET
- Next message (by thread): [dns-wg] Re: ORSN-SERVERS.NET
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jay Daley
jay at nominet.org.uk
Thu Oct 28 18:44:48 CEST 2004
Jefsey I have read this message several times and I still do not understand it. I have an eerie feeling that we might live in parallel universes. However, I have attempted a sensible reply. "JFC (Jefsey) Morfin" <jefsey at jefsey.com> wrote on 28/10/2004 13:21:23: > > Jay, > I will try to review this key point for the internet development. > > what ORSN does is risk containment. Suppose the ICANN/NTIA root is hacked. > The ORSN file is not affected. This provides a protection. Now, obviously, > if the delay in updating the ORSN file is too long it is going to pollute > the namespace with old data. This is why trouble shouting calls for a > report on possible differences. Such report must be taken both ways: > - a way to know that ORSN is outdated > - an alarm that the ICANN/NTIA root may be hacked. This is plain nonsense. Are you saying that ORSN examines any changes made in the root zone by hand and then contact the TLD manager to make sure those changes were correct? If not then how does anyone know if it has been hacked? > > This kind of issue has been identified by the dot-root project of a DNS > test bed we carried last years. This has lead us to work on local roots > concepts and eventually on the authoritative root matrix (which is not > documented, but implemented in reality through the additional name servers > entered in the top level through ccTLD db.files for example). Are you saying there is a whole group of ccTLDs who have added ORSN to their configs? If so then who? > > This also lead to the AFRAC project (http://afrac.org) to unlock root files > (like the ICANN/NTIA root file) as this is true for any other application > root file, through contextual root files for what we named "externets" (ie > an external global view of the internet). For example, a Japanese externet > can be all the users and hosts which freely chose to belong to it. End to > end relations may then be limited to these externet members (only people > able to read Japanese). You can belong to many externets. In the case of a > nation, we identified that a national externet is a regalian duty. I have looked up regalian in the dictionary and I am completely lost. What do you think it means? > > What does that mean? > > It means that many things may happen which affect your sure national use of > the DNS. In 99.99% of the case that you use an US, a French, an European or > a East-Timor root server is the same. But in critical occasions you will > want to use a nameserver which will follow the rules which protect your > skin. What rules would they be? > We developed this kind of thinking in parallel to the White House - > [weird stuff snipped] > This eventually lead to the http://whitehouse.gov/pcipb > national strategy, the first visible impact we all know is the DoD IPv6 > commitment. This is all extremely odd. Can you point me to a particular page in that huge mass of documents that has some direct relevance to ORSN? > > [really weird stuff snipped] > > This means that every Gov has a regalian duty, not to load the ICANN/NTIA > file, but to copy it like ORSN does. This copying must be carried with a > take-over procedure to cope with a special national situation. A critical > problem may be local. What is the difference between a copy and a copy (sorry loading)? > [more weird stuff snipped] > Jay
- Previous message (by thread): [dns-wg] Re: ORSN-SERVERS.NET
- Next message (by thread): [dns-wg] Re: ORSN-SERVERS.NET
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]