Simply-Domain

Living Document,

Editor:
Sjoerd van Groning (Muze)

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 20 October 2022, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

Humans want simple names for Internet resources. That is why we are using domain names. With Simply Solid Domains, we strive to make it simple to access content, with long paths, content identifiers (CID) and protocols not supported by browsers. We do this by storing protocols and location in a TXT field, using DNS as key-value store. The proxy is also able to decode content between protocols. This way every browser/user can access the content with a simple name.

1. Introduction

This document outlines in detail how a user can configure DNS to make content available. The client uses a custom/short URI. The publisher can use a protocol which the browser might not support. Publishers can serve content stored on a long URI. The proxy will fetch the content and serve it. When implementing this standard, it would be great to make it easy to implement new protocols.

1.1. Advantages:

2. Definitions

proxy
A proxy, fetching the desired content conforming to this specification
destination
The public path to the destination where the users wants to fetch the content from
uri
Uniform Resource Identifier, used to describe the protocol and (real) content location. For most protocols user here, this is a URL (Uniform Resource Locator)
priority
Number, used to determine from which uri a resource is fetched. This is an optional field

3. Setting DNS records

To instruct the proxy to fetch the correct content, the publisher must set two DNS records.

A-record on hostname, pointing to an IP of a proxy

TXT-record on _dnslink.hostname containing one of the following forms: "dnslink= " or with optional priority "dnslink= "

If there is no then the priority will get a default value of 20.

For example, we want the user to go to https://www.resource.com/presentation.html. Our proxy is located at the ip 1.2.3.4 and the real content is located at: 
https://www.example.com/user/alice/projects/project54/container/presentation.html

The we must create an A-record and a TXT-record

www.resource.com A-record 1.2.3.4
_dnslink.www.resource.com TXT record "dnslink=https://www.example.com/user/alice/projects/project54/container/ 20"
For example, we want the user to go to https://www.resource.com. Our proxy is located at the ip 1.2.3.4 and the real content is located at: 
ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

The we must create an A-record and a TXT-record

www.resource.com A-record 1.2.3.4
_dnslink.www.resource.com TXT-record "dnslink=ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi 20"

4. Serving content

4.1. Requesting the content

A user enters the URI in the browser. The browser will perform a dns lookup, retrieve the A-record (with the ip of the proxy).

The browser will perform a HTTP request with the proxy, where the significant fields are listed below:

GET /presentation.html HTTP/1.1
Host: www.resource.com

4.2. Getting TXT-record from DNS

First thing the proxy needs to do, is fetch the corresponding TXT-record(s) on _dnslink.hostname and this will look as follows:

dig +short TXT _dnslink.resource.com
"dnslink=https://www.example.com/user/alice/projects/project54/container/ 20"

4.3. Verify protocol support

Next action the proxy needs to do is check whether it can support the protocol. If the protocol is not supported, either for technical (no code for fetching/transforming) or administrative, need to put out an error message.

405 Method not allowed
415 Unsupported Media Type

4.4. Lowest priority first

When there are multiple TXT-records with the same destination, only supported records with a supported protocol are taken into account and the TXT-record with the lowests priority should be chosen.

The intention is you have a fallback website on a different protocol/location.

4.5. Fetch content

Now we can fetch the content. This is protocol-dependant and can be complex for some protocols.

For https, in our example this could be:
GET https://www.example.com/user/alice/projects/project54/container/presentation.html

4.6. Deliver the content

Now that we have the desired content, we can send it to the client as requested. This will be as http(s).

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119