Greetings, there are a few days left to consider which of two problem statements will be used to continue the discussion on Special-Use Domain Names.
If you lack context, please read the last section. ## Current Actions Suzanne Woolf, chair of the DNSOP IETF WG recently proposed the WG to choose between two problem statements in order to revise or replace RFC6761. Interested members can read them and reply to the mailing list thread: "[DNSOP] moving forward on special use names". The deadline for reviewing the drafts is set to **September 25**. You should send your response directly to the DNSOP list. The drafts are: - <https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/> - <https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/> John Levine proposed to distinguish "Internet Names" according to their specificity: (quoting) * Names resolved globally with the DNS protocol, i.e. ordinary DNS names * Names resolved globally with an agreed non-DNS protocol, e.g. .onion via Tor * Names resolved locally with an agreed non-DNS protocol, e.g, .local via mDNS * Names resolved locally with unknown protocols, e.g. .corp and .home, the toxic waste names In GNU consensus we've been working with the second category, namely .onion, .i2p, .zkey, .bit, and the third category, namely .gnu and .exit. When reviewing the drafts, please look out for the preferred outcome (being able to reserve these names on **technical** grounds, via IETF processes.) ## Special-Use Domain Names of Peer-to-Peer Systems TL;DR Christian Grothoff presented the issue at IETF93. https://www.ietf.org/proceedings/93/slides/slides-93-dnsop-5.pdf In 2013, a group of people from various P2P free software projects gathered to produce an RFC aiming at reserving 6 specific Top-Level Domains using the provisions of RFC6761. The first draft of this document was published on November, 14, 2013. After more than a year and 4 draft revisions, it became obvious that we would not achieve our original goal of recognition of the involved P2P systems (GNUnet, I2P, Tor and Namecoin) in one block. See: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names Jake Appelbaum took on himself to spin off and create a draft only for .onion in collaboration with Alec Muffet. Although this broke our strategy of unity, it took advantage of a time constraint with the Browser Forum, a consortium of Web browser and SSL certification vendors who had put a hard deadline on the acceptance of issuing only known domain names in commercial certificates (to prevent some forms of abuse). Despite some flaws (e.g., users are expected to know that .onion is not a DNS name) it was successful in achieving IETF consensus and is now part of the Standards Track as RFC7686, making your Tor services valid candidates for commercial SSL certificates. IOW, you can ask Gandi to deliver one SSL certificate for your personal.example.com that is also available through Tor via https://omfg1ms0lucky404.onion/, but you cannot have this certificate include personal.example.corp that you use inside your organization (because .corp is not a registered TLD at IANA, but .onion is, even if it does not resolve via the DNS.) ONION was the last Special-Use Domain Name (SUDN) to go through the fuzzy procedure described in RFC6761. Other SUDNs, including .bit, .exit, .gnu, .i2p, and .zkey are waiting for the current process to meet its resolution. As always with IETF processes, anyone can participate, that is, if you have the time to read two dozen RFC documents, a dozen more SSAC documents, read the DNSOP list and take the time to reply. I still believe this is worth it, and someone should do it (preferably more than one person :), so we get recognition for these P2P systems. So I invite those of us who are acquainted with the IETF processes, or who want to, to get involved in supporting this effort. Thank you for your attention, == hk