Hi, I include below the last of the 8 sections which are included in the attached piece. I offer this to the DNSOP list for consideration in the existing 4 proposals for special names registration.
I hope that people will read the full text, though you will be bored by (and possibly complain about) the first section. I welcome all comments/complaints. The entirety is 1172 / 200 / 3 (words / lines / pages). Regards, -- Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk -- last section -- More Commentary and Even More Personal Opinion I believe that the grothoff and appelbaum drafts are the first cases of testing the mechanism for the use of the special names registry. I also assume that the registry was created to be used for more than its initial propulation with things like .local and .invalid. Additionally, I agree with some members of the DNSOP community that names matter. "my-product.invalid" is not a good way to start a venture. Should .alt be available "my-product.alt" is far preferrable as confirmed by a member of the I2P community both at the Interim meeting and in later mailing list communication (str4d). Indeed, that person claims that .alt would have been used if it was both available and understood. I have little concern for the corp request, but it gains weight by having potential operational impacts in the DNS space. As mentioned I could not find a draft and thus have no knowledge of its technical nature. I think that the key decision is appelbaum. It meets all criteria which I list above. If this request cannot be processed effectively, that lack of efficacy throws into question the entire nature of RFC6761. As stated, I assume that RFC6761 was well considered and that the registry was intended to be ammended. IMHO, the appelbaum (.onion) proposal meets all possible standards for approval. Finally, I wish to support the .alt proposal. I believe that it is wise to create a "reading neutral" space for the creation/testing/deployment of alternate name space communications technologies, and in this regard I will quote Bruce Schneier from his presentation at IETF 88: "Second, target dispersal. We were safer when our email was at 10,000 ISPs than when it's at ten. Fundamentally, it makes it easier for the NSA and others to collect. So anything to disperse targets makes sense."
An Insanely Brief History of DNS In the beginning a set of non-country specific top level domain (TLD) names are allocated (.net, .com, .org, ...) and handed out to a collection of companies to provide registration. Additionally, a set of county code TLDs is handed out to country based organisations to allocate names with the countries (.au, .ca, ... .za). Name registration proceeds according to these fixed top level domains through the registrars who are authorised to provide registration. It is determined that a process for the registration of new top level domains is appropriate. Thus, it may be possible to register .tld or .impossible. Additionally, a process to forward declare that certain domain names are special and shall not be able to be registered is declared in February 2013 (RFC6761). Pervasive Monitoring On 2013-11-06 the Internet Engineering Task Force (IETF) at IETF 88 declares that pervasive surveillance is an attack on the internet. The IETF then forms and charters multiple working groups (WGs) to create responses that mitigate the pervasive monitoring threat Overlay Networks From at least 2003 (12 years ago) a collection of organised groups produced applications that used non-DNS based name resolution for internet communications. The three examples which are later referenced are GNS (GNU Name System), TOR (The Onion Router) and I2P (Invisible Internet Project). All of these systems created a network which does not use DNS name resolution but does use other internet communications protocols as standardised by the IETF. Their reluctance to use the DNS for name resolution is possibly due to its unencrypted public leaking of name searches. The IETF working group DPRIVE are mandated to produce solutions to that problem. DPRIVE was chartered on 2014-10-17 (more than a year after IETF 88, and certainly well after GNS, TOR and I2P). Special Names On 2015-01-24 draft-grothoff-iesg-special-use-p2p-names-04 is published and requests the classification of special name status for 6 TLDs associated with the 3 overlay network projects listed above. On 2015-04-14 draft-appelbaum-dnsop-onion-tld-01 is published which requests special name classification for only the one .onion TLD which is associated with the TOR project. Both of these drafts precisely follow the process specified in RFC6761 for claiming special name classification, and are clearly acceptable within RFC6761 as they distinguish their differences from the standard behaviour in the 7 categories which RFC6761 specifies must be listed and described. Parallel Issues As the above drafts are considered by DPRIVE and DNSOP (an IETF working group on DNS operations) two other considerations enter the mix; the special name registration of .alt (draft-ietf-httpbis-alt-svc-02) to create a legitimate place for these types of overlay networks to be created/tested/deployed in the future, and the special name registration of .home, .corp, and .mail (with the later addition of .lan). I could find no official draft for the latter and use the short name 'corp' to refer to it below. [DNSOP] Interim DNSOP WG meeting on Special Use Names On 2015-05-12 a meeting is convenced by DNSOP to consider the above special names applications. What follows is an extremly brief (and thus heavily edited and biased) unofficial summary of what the author gleaned from that meeting: * the IETF (and specifically DNSOP) does not wish to be a clearing house for special names consideration. From this flows the desire for an objective, measurable method for determining validity of special names claims to expidite the process and reduce verbage. * DNSOP wishes to make claims individually, rather than in bulk. Thus, the grothoff draft is rejected (or at least unprioritised) on this basis * There are two parallel assessment conditions: will action or inaction cause detriment to the operation of the internet at large (i.e have significant impact on any major component of the internet -- in which DNS is one), and does the application have technical merit. In the second condition the concern replicates that of RFC6761 itself, in which it states that if the application has no effects on the 7 listed categories and could be achieved by the standard registration process, that should be pursued. * the .alt registration creates a future path for non-DNS name resolution systems and this in turn provides a path for DNSOP to not have to re-consider the potentially complex discussions involved in special name registration for non-DNS name resolution overlay networks. i.e "they started with .alt and all seems well managed/operational, so fair play by them". A Categorisation of Request Below I categorise the 4 requests (grothoff, appelbaum, alt and 'corp') according to issues that were raised in the Interim DNSOP WG meeting described above: * uses non-DNS as a name resolution mechanism or not (non-DNS?) * single claim (one TLD only) (1?) * is deployed, operational and managed or not (Works?) * issuance of request will protect the privacy of end users or not (Priv?) For each category I respond with Y (Yes), N (No), or NA (Not applicable/ cannot be known). Request non-DNS? 1? Works? Priv? grothoff Y N Y Y appelbaum Y Y Y Y alt Y Y Y* Y corp N** N Y Y * Works if defined and then people start deploying to it ** Local DNS resolvers should respond, but not the root More Commentary and Even More Personal Oppinion I believe that the grothoff and appelbaum drafts are the first cases of testing the mechanism for the use of the special names registry. I also assume that the registry was created to be used for more than its initial propulation with things like .local and .invalid. Additionally, I agree with some members of the DNSOP community that names matter. "my-product.invalid" is not a good way to start a venture. Should .alt be available "my-product.alt" is far preferrable as confirmed by a member of the I2P community both at the Interim meeting and in later mailing list communication (str4d). Indeed, that person claims that .alt would have been used if it was both available and understood. I have little concern for the corp request, but it gains weight by having potential operational impacts in the DNS space. As mentioned I could not find a draft and thus have no knowledge of its technical nature. I think that the key decision is appelbaum. It meets all criteria which I list above. If this request cannot be processed effectively, that lack of efficacy throws into question the entire nature of RFC6761. As stated, I assume that RFC6761 was well considered and that the registry was intended to be ammended. IMHO, the appelbaum (.onion) proposal meets all possible standards for approval. Finally, I wish to support the .alt proposal. I believe that it is wise to create a "reading neutral" space for the creation/testing/deployment of alternate name space communications technologies, and in this regard I will quote Bruce Schneier from his presentation at IETF 88: "Second, target dispersal. We were safer when our email was at 10,000 ISPs than when it's at ten. Fundamentally, it makes it easier for the NSA and others to collect. So anything to disperse targets makes sense." Regards, Hugo Connery
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
