You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

5.7 KiB

Raw Permalink Blame History

Domain Names — Non-DNS Types

IFA Proposal No. 2
Title: Domain Names — Non-DNS Types
Status: Draft
Type: Standards Track
Created: 2015-05-31

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This document is released into the public domain.

This document was authored by Hugo Landau.

Table of Contents

Introduction
Non-DNS Item Types
Changes to Processing Rules
Newly Deprecated Item Types
Changelog

Introduction

This document extends the Domain Names specification, IFA-0001. It specifies additional item types which are not DNS mappable at the time of writing. Currently, these types are used to express endpoints for various darknet technologies.

Non-DNS Item Types

"tor": Used to specify zero or more Tor hidden service addresses.

The value for this item SHALL be one of the following forms:
- An empty array. This denotes that hidden service connectivity is not available via the current object. This is the default semantic if the "tor" item type is not present.
- An array of one or more strings. Each such string SHALL contain a Tor onion address, including the ".onion" suffix. (Note that the value MUST NOT be an URL.) The string MUST NOT have a trailing dot.
  
  This form denotes that the current object is mappable to any of the Tor hidden services with the given addresses. Client implementations should select an address in a similar fashion to the selection of IP addresses; sort the addresses randomly and try them in order until all addresses are exhausted.
- A string. Where this form is encountered, it SHALL be substituted with an array containing that string and be processed as though that was what was encountered, as per the above form.
Examples:
```
"tor": []                                                    // No hidden service available
"tor": "qaneqo4kcreewkvq.onion"                              // One hidden service available
"tor": ["xo920axk34lannrw.onion"]                            // One hidden service available
"tor": ["ganeqo4kcreewkvq.onion", "xo920axk34lannrw.onion"]  // Two hidden services available
```
The following example forms are NOT valid:
```
"tor": "ganeqo4kcreewkvq"
"tor": "ganeqo4kcreewkvq.onion."
"tor": "http://ganeqo4kcreewkvq.onion"
"tor": {}
```
"i2p": Used to specify zero or more I2P eepsite addresses.

The value for this item SHALL be one of the following forms:
- An empty array. This denotes that I2P eepsite connectivity is not available via the current object. This is the default semantic if the "i2p" item type is not present.
- An array of one or more strings. Each such string SHALL contain a base32-form I2P eepsite address, including the ".b32.i2p" suffix. (Note that the value MUST NOT be an URL.) The string MUST NOT have a trailing dot.
  
  This form denotes that the current object is mappable to any of the I2P eepsites with the given addresses. Client implementations should select an address in a similar fashion to the selection of IP addresses; sort the addresses randomly and try them in order until all addresses are exhausted.
  
  The address MUST be of the base32 form and MUST NOT be a friendly name like "example.i2p".
- A string. Where this form is encountered, it SHALL be substituted with an array containing that string and be processed as thoug that was what was encountered, as per the above form.
Examples:
```
"i2p": []    // No eepsite available
"i2p": "vbcc75tfgauz5qc6tlggfduudeva755sncjyuv5sfjhy7o2ltuqq.b32.i2p"   // One eepsite available
"i2p": ["vbcc75tfgauz5qc6tlggfduudeva755sncjyuv5sfjhy7o2ltuqq.b32.i2p"] // One eepsite available
"i2p": ["vbcc75tfgauz5qc6tlggfduudeva755sncjyuv5sfjhy7o2ltuqq.b32.i2p",
        "idphjncvywzvcjur2zeep2a44s5dxduzv7iytgihg7vdx3x5hnkq.b32.i2p"] // Two eepsites available
```
The following example forms are NOT valid:
```
"i2p": "vbcc75tfgauz5qc6tlggfduudeva755sncjyuv5sfjhy7o2ltuqq"
"i2p": "example.i2p"
"i2p": "vbcc75tfgauz5qc6tlggfduudeva755sncjyuv5sfjhy7o2ltuqq.b32.i2p."
"i2p": "http://vbcc75tfgauz5qc6tlggfduudeva755sncjyuv5sfjhy7o2ltuqq.b32.i2p"
"i2p": {}
```
"freenet": Provides a Freenet freesite key.

The value for this item SHALL take the form of a string containing a Freenet freesite key, e.g. "USK@0I8g...xbZ4,AQACAAE/Example/42/".

Changes to Processing Rules

There are no changes to item suppression or other processing rules.

Newly Deprecated Item Types

The following item types are deprecated by this document and SHOULD NOT be used.

"i2p": The format proposed previously does not appear to make sense and includes extraneous fields. Since no actual implementations of that format are known, it has been deprecated in favour of a format more uniform with the "tor" item type.

Disclaimer

Some item types described in this document may be subject to change in the future, as the requirements of the darknet technologies targeted become clearer. Permanent support for the item types described herein is not guaranteed.

Changelog

20150531: Initial revision, factored out from IFA-0001.

5.7 KiB Raw Permalink Blame History