Hello All,
Im writing to the list in response to IETF submission made by christian. This has created much debate on the DNSOPS mailing list[1] and has also seen another draft to be proposed[2]. I will start by saying I see merit in both drafts being proposed[3][4] and donĀ¹t necessarily see them as being mutually exclusive. However the discussions on the list seem to keep coming back to one question would it be feasible for you to retrospectively change the anchor of .onion to some other TLD. E.g. .onion.arpa. There is much speculation on this questions however it appears that the question has not been directly asked on this list.
Therefore I would like to ask the following.
- What would be the barriers both, technical and political, for tor to change the anchor it uses from .onion to something else (whatever that may be)? - If such a change where to happen what would be an acceptable timeline for new software to stop supporting the old anchor? - If the .onion is unsuccessful in its request to be reserver under the mechanism laid out in rfc 6761[5]. Would there be any motivation to change the anchor so that it conformed to a different policy and therefore allow operators and developers to prevent leakage of this name on the internet - Are there any privacy concerns caused by .onion names leaking on to the internet in the form of a DNS QNAME by software trying to resolve the name - If an organisation where to obtain the .onion name under the gTLD programme are there any privacy concerns considering the organisation could now answer the DNS queries mentioned above. I.e. If a user requested notatrap.onion without tor configured instead of getting no response the could be redirected to a site controlled by the new owner of the .onion domain.
Thanks John
[1]http://www.ietf.org/mail-archive/web/dnsop/current/msg10785.html [2]http://www.ietf.org/mail-archive/web/dnsop/current/msg11074.html [3]http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-01 [4]http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00 [5]http://tools.ietf.org/html/rfc6761