DEV Community: Commons Host

Gaufre, a Gopher browser in your Web browser

Sebastiaan Deckers — Wed, 11 Mar 2020 00:35:14 +0000

Introducing Gaufre, a Gopher browser in your Web browser.

Launch the Gaufre web client:

https://gopher.commons.host

Commons Host

@commonshost

🧇 Gaufre, the Gopher browser in your web browser, gets a big update:
- Themes
- Dark/light modes
- Page alignment
- Custom proxy settings
Try it out! gopher.commons.host

22:20 PM - 09 Mar 2020

Most content types found in the Gopherverse are supported. Those includes:

plain text
menus
input fields
images
audio
video
HTML (sandboxed, no external requests!)
PDF
Binary downloads

For usability, it is designed with:

Responsive text scaling for phone, tablet, and desktop.
Themes with dark/light modes.
Delegating basic controls to the web browser (back/forward, bookmarks, reload, etc)

This client is also a proof of concept of two new experimental transport protocols that require no changes to the Gopher protocol.

Gopher over HTTP (GoH) - Lightweight proxy tunnelling of Gopher data over HTTP request/response.
Gopher over TLS (GoT) - Encrypted Gopher connections. Uses SNI to support virtual hosting by Gopher servers, and ALPN for forward compatibility.

About Gopher

The Gopher protocol dates back to 1991 when the Internet was mostly used to publish text based content. A competing service, the World Wide Web with its HTML and HTTP standards, soon took over this role and has kept growing ever since. Nevertheless, a small but passionate community keeps the Gopherverse alive.

Why?

Retro-computing fans continue to publish hundreds of ~~blogs~~ phlogs and other content on the Gopher network. Some see it as a fun way to experiment with network programming and server administration. To others Gopher is an escape from the ails of complex, modern websites. Gopher is free from commercialism, advertising, and tracking. The Gopher protocol is so simple that it does not support those features. Gaufre aims to make the Gopherverse accessible to a new generation of burrowers.

Video: The Web Is Broken Beyond Repair. The Alternative? GOPHER! (by DistroTube on Youtube)

Experimental Protocols

With Gaufre, two new protocol designs are introduced to help bring Gopher into the modern Web Platform, without disturbing its charming simplicity.

The Gaufre client runs client-side in your browser, where it is sandboxed for security reasons and can not access Gopher's raw TCP/IP sockets on port 70. The solution: Gopher over HTTP (GoH). Gaufre makes an HTTP request to a very lightweight Gopher over HTTP proxy, which relays the request to the intended Gopher server. The Gopher server's response is returned as raw Gopher data through an HTTP response to Gaufre. Because a GoH proxy does not need to parse Gopher content, it is very CPU and RAM efficient compared to traditional Gopher to HTML proxies.

Another limitation of the Gopher protocol is its lack of virtual hosting, meaning multiple domain names on the same IP address. This stems from an era where one server typically had one domain name or could receive multiple IPv4 addresses. Today IPv4 addresses are expensve and a server can have any number of domain names pointed at it, for example a CDN edge serving lots of different websites. The HTTP/1.1 standard solved this problem by introducing a Host: example.com header which allowed browsers to tell a web server which domain they were accessing with a given URL path and querystring. Since Gopher protocol has no headers, there is no clear way to extend the protocol and the community has adopted workarounds like using subdirectories instead of domain names.

Then there is the lack of encryption; normal in 1991 but unacceptable in today's world. This is a curiously similar situation to DNS, an even older protocol that has no built-in encryption. Recent innovations for DNS include DNS over HTTPS and DNS over TLS. The latter is what inspired Gopher over TLS (GoT): Accepting both plaintext and TLS-encrypted Gopher connections on the same port 70/TCP.

Using the TLS SNI extension, a GoT client provides the server's domain name to the GoT server. This solves our problems and provides two key features: Virtual hosting and encrypted connections!

Gopher over HTTP (GoH)

The GoH protocol makes it possible for any device or platform with an HTTP client to access raw Gopher traffic through a very simple proxy. It is not limited only to Gopher browsers like Gaufre. This is different from existing Gopher to HTML proxies which transform Gopher content into human-friendly but machine-unfriendly rich markup.

The Commons Host CDN project offers a public GoH proxy service, set as default in Gaufre. You can also run your own GoH proxy, on your own machine or network, for absolute performance and total control. With Node.js installed, run this to start a lightweight GoH proxy server:

npx goh

GoH specification and implementation: https://gitlab.com/commonshost/goh

Gopher over TLS (GoT)

The GoT protocol allows hosting of multiple domains on a single IP address, something Gopher cannot do otherwise. I have used this ability to create a Gopher CDN and hosting service, available at gopher://commons.host. It should even be possible, though I have not yet attempted, to place a GoT socket forwarder on port 70 which routes traffic based on the SNI servername to any (unmodified) Gopher servers running on different ports. A similar design, though without SNI and ALPN, was proposed last year by Solène using sslh_fork.

GoT is supported by the GoH proxy (acting as a GoT client). The first Gopher server to support GoH is gopher://commons.host and any static sites hosted on its CDN.

Use OpenSSL's built-in s_client tool to test GoT for yourself.

echo -ne "/\r\n" | openssl s_client -ign_eof -servername commons.host -alpn gopher -connect commons.host:70

GoT specification and implementation: https://gitlab.com/commonshost/goth

Happy Burrowing!

Please give Gaufre a try and enjoy exploring the Gopherverse.

Launch Gaufre: https://gopher.commons.host

Cover photo: Gophers are known for their extensive tunneling activities. Their underground networks resemble the honeycomb-like pattern of waffles. Gaufre is the French word for waffle. Credit: Airwolfhound

Dohnut 🍩 DNS to DoH proxy

Sebastiaan Deckers — Wed, 20 Feb 2019 08:01:18 +0000

TL;DR Dohnut easily upgrades all your network clients by proxying plaintext DNS to encrypted DoH.

The Commons Host CDN project recently launched a public DNS-over-HTTPS (DoH) service. DoH now operates across all 30+ edge servers of the Commons Host network, offering low latency in many locations worldwide. Uniquely the Commons Host network is grown by contributors who own and host low cost micro-servers using consumer-grade Internet connections at their homes or offices.

The DoH Internet standard, RFC8484, promises improved privacy and security for DNS. DoH encrypts all queries, protecting users against snooping or DNS response tampering by ISPs and rogue Wi-Fi routers.

Upgrading all of your network clients from plaintext DNS to encrypted DoH is not trivial. There is currently no operating system or router/hardware support. The only browser supporting DoH today is Firefox.

This is why a DNS to DoH proxy is needed.

Introducing: Dohnut 🍩

Dohnut acts as a local DNS server, either for one machine or for an entire local network. It proxies all DNS queries to remote DoH services inside encrypted, long-lived HTTP/2 connections.

commonshost / dohnut

🍩 DNS to DNS-over-HTTPS (DoH) proxy server

Dohnut

Dohnut is a DNS to DNS-over-HTTPS (DoH) proxy server. Dohnut improves the performance, security, and privacy of your DNS traffic.

https://help.commons.host/dohnut/

Dohnut works with any open standard (RFC8484) compliant DoH provider, including the Commons Host DoH service and many others.

Features

High Performance Auto-select the fastest DoH resolver. Continuously adapts to network and service conditions by monitoring the round-trip-tip of the DoH connection using HTTP/2 PING frames.

High Availability Allows using multiple DoH resolvers at once to provide automatic failover in case a service is unavailable.

Zero Overhead - Network traffic does not go through Dohnut so there is no performance penalty. Only the DNS queries (very little bandwidth) are proxied.

Lightweight - Multi-threaded architecture for fast performance on low-power devices like single board computers. Designed for Raspberry Pi and Odroid but compatible with anything that can run Node.js.

Full Encryption - DoH encrypts all DNS…

View on GitHub

Easy to Deploy

Deployment guides are currently available for Raspbian, Docker, Linux/systemd, and macOS/launchd.

A desktop client and a web dashboard are in the works!

Lightweight

Dohnut is built with Node.js to be cross-platform and fast. Running on just a $35 Raspberry Pi computer, Dohnut can easily handle a typical home or SME network with dozens of DNS clients.

Commons Host

@commonshost

Lamb Pi edge server, anyone? Working on a new tier of servers for the @CommonsHost #DoH #DNS network.

06:10 AM - 04 Feb 2019

1 5

Dohnut is also a great companion to the popular DNS ad-blocker Pi-hole. Dohnut acts as the Custom DNS Upstream server to Pi-hole. Pi-hole, as the DNS server to DNS clients on the network, does the ad-blocking, monitoring, and provides a local, low latency DNS cache.

Commons Host

@commonshost

🍩 Dohnut + #Pihole securing and ad-blocking for home & SME networks. Tens of DNS clients using only a #RaspberryPi 1.

07:59 AM - 20 Feb 2019

0 0

Auto-Optimising DNS Latency

Multiple DoH services can be used by Dohnut at once. Dohnut load balances between DoH services using two configurable strategies:

Best performance: Always send DNS queries to the fastest DoH resolver. Continuously monitors the round-trip-time latency to each DoH resolver using HTTP/2 PING frames. Set and forget; this mode automatically discovers when one of the DoH resolvers improves their latency to your network (e.g. deploying a new server near you).
Best privacy: Uniformly distributes DNS queries across all enabled DoH resolvers. This shards DNS queries so that a single DoH resolver only sees a slice of the total traffic.

Tip: Use Bulldohzer to measure lookup latency from your location to multiple DNS and DoH resolvers.

Experimental: Active Tracking Countermeasures

Privacy policies of public DNS resolvers vary. But there is always the unavoidable fact that resolvers must see your DNS queries. This is an inherent privacy risk when using a DNS-over-Cloud provider.

To deter tracking by DoC providers, Dohnut can spoof DNS queries. It does this at random times and using a realistic sampling of popular real-world domains. This makes it very hard for any DoC provider to tell, if they wanted to, which queries are really yours and which are just spoofed noise.

This does introduce additional traffic and load on public DNS services. This is intended as a privacy experiment.

Another concern with DoH is the increased surface for tracking at the HTTP layer. By muxing queries from multiple clients into a single DoH connection, Dohnut acts as an passive privacy mechanism. Dohnut can also randomise the HTTP User-Agent header based on real world browser usage data.

Feedback

Feedback on these ideas and their implementation is greatly appreciated. ❤️ Blog comments, GitHub Issues, Twitter, etc.

Cover photo by Ferry Sitompul

Bulldohzer 🚜 DNS & DoH performance testing

Sebastiaan Deckers — Sun, 03 Feb 2019 11:52:05 +0000

A few months ago Commons Host built and launched its DNS over HTTPS service in just 10 days. The service has proved reliable and performant, with users enjoying secure and private DNS service.

One challenge users face is finding the best DoH or DNS service. Public DoH & DNS performance reports are of questionable value. This is because performance for a test server in a big datacentre or at an Internet Exchange is not the same as on your own device on your own network.

So run your own performance tests.

Introducing: Bulldohzer 🚜

Bulldohzer is an easy to use DNS and DoH performance test. You can run Bulldohzer yourself to find the best resolver for you.

Bulldohzer does not require any installation. Test runs take just a few seconds. Reports are designed to offer a lot of detail yet be easy to understand at a glance. Output of raw JSON data is also supported.

$ npx bulldohzer

Note: The npx command is provided by Node.js which is the only dependency. You will need Node.js v11.4.0 or later.

If you can not measure it, you can not improve it.

Traditional DNS is heavily optimised due to decades of widespread use. Unfortunately it is susceptible to tampering and monitoring. DoH is a new and secure DNS protocol. DoH transports DNS over long-lived HTTP/2 connections. Because DoH is so new, some implementations are not yet optimised nor widely deployed.

Please try out Bulldohzer and share your results with DoH providers.

Cover photo by khaosproductions

Build your own URL shortener in 15 minutes

Sebastiaan Deckers — Sun, 20 Jan 2019 07:40:37 +0000

The Commons Host CDN platform recently introduced support for custom HTTP response headers and redirect rules. Let's use these features to build our own private URL shortener, with support for a custom domain name and Google Analytics tracking. Did I mention this is all free of charge and 100% open source?

Let's get started.

You could use an existing Commons Host site but this tutorial shows how to get started from scratch. These instructions are intended for Mac OS or Linux.

Project Directory

Start by creating the following project directory structure, then locally installing the Commons Host CLI and short tools with NPM.

short/                 // Project directory
| CNAME                // File
| commonshost.json     // File
| package.json         // File
\ public/              // Directory
  \ redirect/          // Directory
    \ index.html       // File

The project directory is self contained and does not make any global changes to your system. Create it anywhere you prefer, for example in your home directory (~).

Run these commands from a terminal to create the project directory.

$ mkdir -p short/public/redirect
$ cd short
$ touch CNAME commonshost.json public/redirect/index.html
$ npm init -y
$ npm install -D @commonshost/cli @commonshost/short

Domain Name and DNS

Set up your domain name.

Use either a free Commons Host subdomain, or your own registered custom domain name.

Option A) Free `*.commons.host` subdomain

Edit the CNAME file with your free Commons Host subdomain.

$ echo "your-sub-domain.commons.host" >| CNAME

Replace your-sub-domain.commons.host with any subdomain you like. This tutorial uses short.commons.host, so choose a unique name for your own URL shortening service.

No additional DNS configuration is required with a Commons Host subdomain. The DNS setup for all *.commons.host subdomains already has a wildcard CNAME record pointing to commons.host.

Option B) Custom Domain Name

Edit the CNAME file with your registered custom domain name.

$ echo "your-name.example" >| CNAME

Replace your-name.example with your actual registered custom domain name.

You must also create a CNAME record pointing from your-name.example to commons.host at your DNS provider's dashboard. That CNAME record will direct users to their nearest Commons Host edge server.

Note: With Cloudflare DNS you may encounter a redirect loop when using Flexible SSL (the default setting). Commons Host enforces full TLS and never serves unencrypted content. To solve this you can either:

Disable the Cloudflare CDN for your CNAME record by setting: DNS > DNS Records > Status > DNS Only
Or, leave the Cloudflare CDN enabled but configure the setting: Crypto > SSL > Full SSL

Configuration File

Save this JSON boilerplate as: commonshost.json

This contains the necessary custom header rule and a placeholder for the URL redirects.

{
  "hosts": [
    {
      "headers": [
        {
          "uri": "/redirect/{?url,}",
          "fields": {
            "Refresh": "2; {url}"
          }
        }
      ],
      "redirects": []
    }
  ]
}

Redirect Page

Save this HTML boilerplate as: public/redirect/index.html

To set up Google Analytics replace GA_TRACKING_ID in the code below with your Google Analytics tracking ID (e.g. UA-12345678-1). See the Google Analytics documentation for details.

Feel free to customise or remove any Commons Host branding. You have full control over your website.

<!DOCTYPE html>
<html>
  <head>
    <script async src="https://www.googletagmanager.com/gtag/js?id=GA_TRACKING_ID"></script>
    <script>
      window.dataLayer = window.dataLayer || []
      function gtag(){dataLayer.push(arguments)}
      gtag('js', new Date())
      gtag('config', 'GA_TRACKING_ID')
    </script>
    <title>Redirecting</title>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <style>
      body { text-align: center; font-family: sans-serif; }
      a { color: black; }
    </style>
  </head>
  <body>
    <main>
      <h1>Redirecting</h1>
      <p id="location"></p>
    </main>
    <footer>
      Powered by 🐑 <a href="https://commons.host" rel="noopener">Commons Host</a>.
    </footer>
    <script>
      if ('URLSearchParams' in window) {
        const params = new URLSearchParams(location.search)
        if (params.has('url')) {
          const to = document.createElement('a')
          const url = params.get('url')
          to.href = url
          to.textContent = url
          document.querySelector('#location').appendChild(to)
        }
      }
    </script>
  </body>
</html>

Sign Up to Commons Host

Create a Commons Host account via the CLI tool. This saves a token in ~/.commonshost that keeps you authenticated on this machine.

$ npx commonshost signup

Enter an email address, username, and password to create your account.

? Email address: sebdeckers83@gmail.com
? Username: seb
? Password: [hidden]
  ✔ Registering account
  ✔ Creating new authentication token
  ✔ Saving credentials

Shorten a URL

The short command creates a new redirect rule and prints the resulting short URL.

$ npx short https://en.wikipedia.org/wiki/Longest_words
🔗 https://short.commons.host/1302

The redirects section of your commonshost.json configuration file should now contain something like this:

"redirects": [
  {
    "from": "/1302",
    "to": "/redirect/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FLongest_words"
  }
]

Tip: Run npx short --help to see more advanced options. For example the --emoji option will generate random emoji for shortened URLs. 🤨

Deploy to Commons Host

$ npx commonshost deploy
To cancel, press Ctrl+C.

Detected options file: commonshost.json
To override, use: --options "path"

Deploying:

  Directory:    ~/short
  File count:   1
  Total size:   1.84 kB
  URL:      https://short.commons.host
  Options:  ~/short/commonshost.json

  ✔ Uploading

Finished! Enjoy your personal URL shortener powered by Commons Host.

Summary

To shorten another URL, just repeat the final two commands from within the project directory:

npx short https://some.really.long.url.example/foo/bar.html
npx commonshost deploy --confirm

Check the server documentation to learn how to customise your Commons Host site further, like setting up a 404 fallback HTML page.

Thanks to @donavon for the feedback on this tutorial.

HTTP/2 Server Push Diary

Sebastiaan Deckers — Mon, 07 Jan 2019 07:50:41 +0000

TL;DR Commons Host now implements an HTTP/2 Server Push Diary to solve the over push problem.

The server push diary is a Cuckoo Filter that tracks any assets which were pushed previously by the server on each connection. Subsequent attempts to push the same resource are checked against the diary and skipped by the server to avoid redundant data transfer.

Here is an example website with two pages sharing the same image and stylesheet dependencies.

A user (👨🏻‍💻) first visits one page and then another. The server (🤖) uses a Cuckoo Filter (🐦) as server push diary to prevent over-push.

Cuckoo Filters

The diary uses a Cuckoo Filter: An extremely space efficient and high performance data structure that makes it possible to track thousands of individually pushed resources, say an entire node_modules folder or set of database records.

The diary is a probabilistic data structure. Data stored can not be retrieved in its original form. Instead the diary can answer whether the same data was previously stored. This is a convenient test when the cost of a repeated operation (e.g. network transfer) far exceeds the cost of the filter (i.e. tiny amount of RAM and CPU).

The server can tune the probability of false negatives. The optimal values are a matter of speculation, so I'd like to see how far people decide to push (pun so intended) this feature. Currently the diary is set to a size of ~1000 entries at ~12 bits per record. This allows for hundreds of pushed resources with very few false negatives.

If this concept sounds familiar, you may have heard of Bloom Filters. The Cuckoo Filter offers efficiency improvements and most importantly allows removal of items. This is useful in the web context when cached items expire and become stale. A high performance implementation of the 2014 Cuckoo Filter research paper exists and has been ported to Node.js by Matteo Collina as cuckoofilter-native.

What About Cache Digests?

The Cache Digest HTTP/2 extension specification appears to be on hold, as far as I can tell.

Commons Host always supported Cache Digests using the Cache-Digest header or cookie. Browsers could send a Bloom or Cuckoo Filter representing their cache to the server. The server used this as a diary to avoid over-pushing. Sadly browser developers have yet to implement native support. Experimental implementations using Service Workers and the Cache API are technically viable but come with a fair set of developer considerations that have so far not proven popular.

Hopefully diaries, being automatically enabled and requiring zero developer effort, can help prove the merit of Server Push and Cache Digests. I believe they are elegant ideas, with solvable problems. We may yet see their success.

Amaravati, India 🇮🇳

Sebastiaan Deckers — Mon, 03 Dec 2018 15:21:29 +0000

A new edge server has joined Commons Host in Amaravati, Andhra Pradesh Capital Region, India. The hardware is contributed by Sai Ram Kunala (@sairam) and deployed on commodity fibre-to-the-home (FTTH), which is available in most Indian cities. For users in India this brings higher bandwidth and lower latency to the Commons Host static site CDN and DNS-over-HTTPS (DoH) service.

Photo: Panorama of Vijayawada, the most populous city within the Andhra Pradesh Capital Region (Source: Yedla70)

>2x Better DNS Latency in India

The performance improvement is especially noticeable with DNS-over-HTTPS vs unencrypted DNS.

Commons Host uses Geo DNS based routing to ensure traffic from users in India stays within India, resulting in optimal round-trip-times. Other providers, using Anycast IP addresses for their public DNS resolvers, appear to suffer from traffic routing to far-away Singapore.

These are latency measurements by Site24x7, a third-party ping service present in Chennai, India.

Provider	Address	Routed To	Latency	Distance
Commons Host DoH	`commons.host`	Vijayawada	14 ms	400 km
Google DNS	`8.8.8.8`	Singapore	34 ms	2900 km
Cloudflare DNS	`1.1.1.1`	Singapore	34 ms	2900 km
Quad9 DNS	`9.9.9.9`	Singapore	36 ms	2900 km

Note: These numbers show the baseline network latency. Cache hit ratios also affect actual DNS lookup times and vary by provider.

Freedom to Contribute

Many thanks to Sai Ram for his remarkable initiative. The deployment is the first with 100% independently sourced hardware. It is a symbolic milestone. Sai Ram simply found the Commons Host project website, watched the videos and read the blog, and purchased his own components based on the Little Lamb Mk I open hardware specs. Then he reached out to help grow the network.

This bypassed a bottleneck: centralised assembly and shipping of edge servers.

Taking ownership of the hardware acquisition means contributors like Sai Ram require neither permission nor resources from any centralised leadership. Simply deploy an edge server and make it available for activation on the Commons Host CDN.

Fundamentally Decentralised

Every country is a unique environment with different challenges and opportunities. Deploying servers around the world is an overwhelming endeavour when viewed from a centralised perspective. Even well funded and expertly staffed teams at large companies struggle to deploy hardware in many places that need it most. That means much of Asia, Africa, LatAm, and MENA is underserved.

The Commons Host approach is different.

Infrastructure: Physical ownership, funding, and hosting of edge servers by worldwide contributors. No single company owns the hardware. This strategy absorbs differences in local infrastructure, economies, laws & regulations, logistics, language barriers, etc.
Tools: All code for the service is developed as free & open source software (FOSS) by independent collaborators. Anyone can review it and contribute patches.
Management: Secure, remote configuration is handled through automation tools. Since local unauthorised hardware access is assumed, the software is designed for a more hostile environment than a typical data centre.

Decentralised physical ownership directs more human energy at solving the hard problems of infrastructure and logistics at a hyper-local level. Yet by pooling their effort, a better global service is provided to all.

Network Effect

In theory any of the edge server owners, alone or in partnership, can fork the code and manage their own network using the exact same FOSS tools. The project leadership is kept from becoming complacent by the threat of abandonment.

In practice, however, there is a shared incentive to maintain and grow a combined, global service. A splintered network would not offer the geographical reach of the cohesive Commons Host service.

What keeps Commons Host together is Metcalfe's law. Roughly speaking, the value of a network is the square of its size. The more nodes in the network, the more advantageous it is for new nodes to join the same network.

Similar mechanisms work for other collaborative projects like the Linux Kernel or Wikipedia. They started as a small and scrappy group of idealists but eventually bested large incumbents.

Udon Thani, Thailand 🇹🇭

Sebastiaan Deckers — Mon, 15 Oct 2018 03:26:44 +0000

Commons Host expands in Thailand with a new edge location to serve low-latency web and DNS traffic.

Thailand is the second largest economy in South East Asia. It has a population of over 68 million people, slightly more than France or the United Kingdom.

The new edge server is located in the north-eastern city of Udon Thani. Routing is conservatively configured to receive only traffic from within Thailand.

The server hardware and hosting are sponsored by Dr Alex, founder of Singapore based WebRTC specialists CoSMo Software. He is a long-time supporter of Commons Host who previously sponsored the Los Angeles edge server as well as my first in-person attendance to an IETF conference. Huge thanks for his support and mentorship.

Photo: Street view Udon Thani, Thailand (Source: Insights Unspoken)

Regional Peering Surprises

From Udon Thani the Laotian capital Vientiane is geographically closer than Thai capital Bangkok, respectively 60 km and 460 km. However network latency tells a different story.

Route	Distance	Round Trip Time
Udon Thani to Bangkok	460 km	12 ms
Udon Thani to Vientiane	60 km	25 ms

Map: Geographical distance (green) vs Network distance (red)

As another example let's look at the edge server in Udon Thani and two different ISPs in Singapore. One has direct peering, at an IX in Singapore, while the other does not. Without peering they must fall back to a carrier in Palo Alto, California; literally an ocean away.

Before this new edge server was deployed, traffic from users on this ISP in Thailand to the Singapore edge servers would sometimes travel halfway around the world.

ISP	ISP	Round Trip Time	Internet Exchange
Commons Host @ Udon Thani (Thailand)	StarHub (Singapore)	42 ms	Singapore
Commons Host @ Udon Thani (Thailand)	MyRepublic (Singapore)	218 ms	California, USA

Map: Network distance from Udon Thani to Singapore with peering (1,800 km in green) or via long-haul transit (26,000 km in orange)

Bypassing Internet Exchanges

Network providers physically interconnect at Internet Exchanges (IX). In this case the IX is located in Bangkok, so all traffic between Udon Thani and Vientiane does an additional ~900 km round trip.

The problem is even worse between smaller ISPs. Since there may not be much traffic flowing between them, direct peering agreements are sometimes not in place. In those cases traffic can only be exchanged via a mutual peering partner.

Simply by deploying more servers in many locations worldwide we can side-step the lack of peering between ISPs. Deploying smaller servers in larger numbers is the brute force way to achieve ultra-low latency. It eliminates expensive & slow transit traffic.

Being able to deploy small-scale edge servers is a key advantage of the Commons Host CDN model.

CDN Provider	Nearest edge to Udon Thani	Round Trip Time
Commons Host	Udon Thani	<1 ms
Cloudflare	Bangkok	~12 ms
AWS Cloudfront	Singapore	>40 ms

The ability to achieve lower latency is inversely proportional to the minimum size of an edge server deployment. Micro-servers < server racks < data centres.

Consumer ISP Port Blocking, Not So Bad After All?

When Commons Host first started one of the fears was that ISPs would never allow it. Fortunately that has been mostly overcome by simply purchasing a static IP and having a friendly chat with the ISP support desk.

To deploy the Udon Thani edge server on a consumer fibre connection required obtaining a static IP address. In theory a dynamic IP address would suffice, but in reality those tend to be private addresses (10.x.x.x or 192.168.x.x) behind an ISP-wide Network Address Translator (NAT) and therefore inaccessible to the rest of the Internet.

Once the static, public IP address was activated, the next obstacle was a mysterious blocking of ports 80 and 443, for HTTP and HTTPS respectively. A simple call to the ISP by Dr Alex resolved the issue. Turns out all we had to do was ask and they happily opened the ports, allowing the edge server to go live in Thailand.

People are mostly good; this is a victory of the commons.

How we built a DOH CDN with 20+ global edge servers in 10 days.

Sebastiaan Deckers — Wed, 10 Oct 2018 13:13:36 +0000

Just months ago the Commons Host static hosting CDN launched with a single edge server. Today there are over 20 edge servers around the world. The majority are inexpensive ARM-based micro servers hosted by volunteer contributors on commodity Internet connections, often Gigabit fibre. Others are virtual machines in cloud data centres which offers similar performance.

Illustration: Map of Commons Host CDN edge servers (live & WIP)

Because We Can

Kenny and I worked diligently on deployment automation. This allowed scaling the edge server count from single to double digits.

With these tools in place, we decided to build and deploy a completely new service in parallel on the same edge server network.

We chose to implement DNS over HTTPS, or DOH for short. DNS resolving is perfectly suited to the advantages and constraints of the Commons Host server network. Low latency due to global coverage, and minimal hardware requirements.

DNS, meet HTTP. HTTP, meet DNS.

Building an HTTP CDN requires learning about the Domain Name System (DNS). DNS is ancient by Internet norms; many years older than the World Wide Web or HTTP.

Standards like HTTP or DNS are the work of the Internet Engineering Task Force. This organisation provides an open, vendor-neutral discussion platform through public mailing lists. IETF also runs conferences, held 3 times yearly, rotating through the Americas, Europe, and Asia.

Photo: A session at the IETF 100 conference

At the 100th IETF conference, in Singapore where we live, a draft called DNS-over-HTTPS was presented and intensely debated. Attendees packed the conference hall. This was a meeting of worlds between DNS and HTTP experts. Even DOH's authors are respected leaders from both DNS (Paul Hoffman, ICANN) and HTTP (Patrick McManus, then Mozilla now Fastly).

I was fortunate to attend IETF 100 last year. The humbling experience left a deep impression. Implementing DOH would also be a personal tribute to this community.

How Hard Can DOH Be?

HTTP servers exist. DNS servers exist. So we just duct tape the two together? Well, basically, yes.

Driven by curiosity, Kenny wrote the first DOH implementation while brushing up on Node.js and reading the DOH draft specification, tabula rasa.

Over the next few days we rewrote and refactored the code. In the end we built a middleware called for Node.js web servers called Playdoh.

Screenshot: Playdoh GitHub repository

Playdoh relays raw UDP messages between a DOH client like Firefox and a traditional DNS server. Playdoh is 150 lines of DOH duct tape, with 300 lines of tests to make sure it sticks.

Deploying a DNS Resolver

To offer a global DOH service, each edge server needs to run its own caching DNS resolver. A resolver processes the DNS query and caches responses so that users benefit from faster future lookups.

We learned of Knot Resolver by talking to friends in the CDN industry. Knot Resolver is open source software developed by the Czech Republic DNS registry (CZ.NIC). Fun fact, Knot Resolver also powers the Cloudflare 1.1.1.1 public DNS service. Others recommended Unbound or BIND as resolvers. We may yet run those in a mixed network for heterogenous resilience.

It took a few days to tune the Knot Resolver configuration and automate its deployment. This involved remotely upgrading the operating system across all edge servers. A risky proposition involving custom vendor kernels for the ARM servers. With overseas unattended physical machines there is no option to press a reset button or flip a power switch. The only solution was to perform tireless careful testing in staging environments, using Vagrant/Virtualbox or on spare hardware. Eventually we ironed out subtle differences between the various server configurations.

This was much more time consuming and technically challenging than coding Playdoh. Our knowledge and experience continues to grow, as documented in the merge request description. Next time this will be easy.

So how is DNS traffic served by a DOH CDN?

Bootstrapping DOH CDN: Anycast IP vs Geo DNS

Users need to be able to easily configure their DNS settings and connect to a nearby DNS server for low-latency lookups.

Traditional public DNS services make use of an expensive Anycast IP network. Users are routed to one of many edge servers worldwide. They share the same IP address but announce different routes using BGP at Internet Exchanges. ISPs will route users via the shortest path. Sadly this is not easily accessible due to cost and administrative overhead.

They also opt for memorable IP addresses. Google owns 8.8.8.8, Cloudflare owns 1.1.1.1, Quad9 (IBM) owns 9.9.9.9, and so on. Their IPv6 addresses are less human friendly but the principle is the same.

With DOH the DNS resolver address is a familiar URL instead of an IP address. This URL contains a domain name so that the connection may be secured using a signed TLS certificate. E.g.: https://commons.host

So DNS itself is used to direct traffic to a DNS over HTTPS service. Chicken or egg? Not quite.

DOH works by bootstrapping the initial DNS lookup of the resolver's hostname. This DNS lookup is still handled by traditional DNS servers like those of an ISP or a local server. The HTTPS connection is then secured with a signed TLS certificate for that domain. Any tampering by a malicious (or faulty) DNS server at the ISP would simply result in a failed connection attempt. So there is no risk of exposing to the DOH client to tampered responses.

Diagram: DOH bootstrap sequence

Bootstrap procedure:

Browser performs DNS lookup for the Commons Host DOH server hostname using a standard, potentially untrusted, DNS server.
DNS server responds with the IP address of the nearest Commons Host edge server.
Browser establishes a HTTP/2 connection with the edge server. TLS certificates ensure an encrypted and authenticated connection.
Subsequent DNS lookups are tunnelled inside the HTTP/2 connection to keep them safe from snooping or tampering by third parties.

* Shown IP address is an example. Actual address is based on location and other performance metrics to determine the optimal edge server for a particular user.

What About Security?

Running a public DNS service is typically fraught with security problems. An open resolver, one that accepts DNS queries from anyone on the Internet, is a convenient traffic-amplifier for DDoS botnets and other malicious actors.

Amplification attacks work by spoofing the source address on a small DNS query, so that the large DNS response gets delivered to an unfortunate target. Attackers use public DNS servers to generate a multiple of their own bandwidth and aim it at a target while hiding themselves as originators. Most people would never want to run such a service, and in fact many ISPs block inbound UDP traffic on port 53 for this reason.

DOH eliminates the spoofing problem. The HTTPS connection requires a secure handshake so traffic can not be spoofed or misdirected. Any responses are always delivered to the correct source, making DOH safe from amplification attacks.

Living on the Edge

Running a public DOH service is much easier than a traditional DNS open resolver. Expect many organisations to offer such services.

One benefit of the Commons Host network is that anyone can sponsor and host an edge server. This brings the CDN edge on-premises, and a great way to run a sub-millisecond latency (i.e. LAN) DOH server. Doing so improves your DNS lookup speed while serving your local community. Get in touch if you are interested.

Using Commons Host DOH

Currently Firefox is the easiest way to use DOH.

Screenshot: Firefox Network Settings for DOH

In the Preferences screen, open the Connection Settings dialog.
Turn on the checkbox: Enable DNS over HTTPS
Enter the URL: https://commons.host

More DOH browser/OS support and bridging solutions will hopefully follow soon. Chrome seems to have a DOH implementation on the way.

One Last Thing: Custom Domain DOH Resolver

Commons Host supports DOH service on custom domains!

Deploying a custom domain on Commons Host is as easy as pointing a CNAME DNS record to commons.host using your domain name management provider.

Commons Host uses Geo DNS to point the domain commons.host to the edge server best suited for any user worldwide. Every edge server has its own public IP address. The edge web servers run the Playdoh middleware which processes DOH requests based on HTTP headers, while regular web requests pass through. The same domain and the same edge server can serve both web and DOH traffic.

Simply deploy a website with a custom domain and use your personal URL as the DOH resolver endpoint. For example: https://www.$yourdomain.com

The same goes for choosing a specific Commons Host edge server as your DOH endpoint. Each one is directly addressable by country code, airport code, and incrementing counter. For example: https://us-lax-1.commons.host connects directly to the Los Angeles edge server.

8 new CDN edge locations

Sebastiaan Deckers — Fri, 28 Sep 2018 07:36:10 +0000

The Commons Host content delivery network just grew by 8 locations.

🌎 America

🇺🇸 Atlanta, Georgia, USA
🇺🇸 Dallas, Texas, USA
🇺🇸 Newark, New Jersey, USA
🇺🇸 San Jose, California, USA

🌏 Asia

🇸🇬 Singapore
🇯🇵 Tokyo, Japan

🌍 Europe

🇩🇪 Frankfurt, Germany
🇬🇧 London, United Kingdom

Supported by UIlicious, powered by Linode

This big bump in network reach is thanks to a generous in-kind contribution by UIlicious cofounder Eugene Cheah (@picocreator). UIlicious is a modern web development tool to automate user journey testing.

Eugene offered his support at the very first announcement of the Commons Host project. After fully automating deployment, and several re-designs of the GeoDNS-based global server load balancing (GSLB), these edge nodes were seamlessly added to the Commons Host network.

The new servers are virtual machines. They are located in all datacentres operated by cloud hosting company Linode. Top-tier datacentres are well connected to Internet exchanges where many ISPs and carriers meet, offering afforable connectivity and scalable performance. High bandwidth and low latency. Perfect, right?

First World Problems

Therein lies the first world problem. These datacentres are located in highly developed countries generating 37.8% of the global economy (2018 nominal GDP, IMF).

Bandwidth consumption in these markets is high. Very high. Fastly reports peak traffic of 5.2 Tb/s during the 2018 SuperBowl. They claim typical sustained rates over 3 Tb/s. Other big, mostly American, CDNs claim similar figures or more.

Even if cloud servers like Linode's could reach sustained bandwidth of the claimed 1 Gbps, which they really don't, it would take thousands to handle peak loads.

In reality it would also take dozens to hundreds of locations to directly peer (aka physically connect via fibre cables) with as many ISPs as possible. Cloud vendors simply do not offer this service today. Still too often negotiations between CDNs, carriers, and ISPs take place at peering conferences, an expensive and slow process only afforded the largest companies.

This has led to enormous concentration of the Internet between a handful of giant tech companies. The consequences are being dealt with across the world, as people consider the inherent threats to their privacy, freedom of speech, and democracy.

Third World Solutions

Centralisation of another kind lies at the heart of the lagging Internet hosting infrastructure in developing economies. The cause is often political and regulatory, caused by limited market competition, the result of lingering telecom monopolies.

Created in South East Asia to solve regional problems, the approach Commons Host takes is to side-step the centralised bottlenecks. Small, affordable ARM-based micro-servers are deployed at business or consumer fibre connections around the world. Commodity fibre network speeds, at least within the same ISP or state/country, are often better than cheap VPSes like Linode's. And the variety of edge locations is practically any home or office in the world.

This means latency is lower while bandwidth-per-server does not need to be as high as centralised CDNs. And peering is a natural consequence of being housed on an actual ISP, rather than bureaucratic negotiations at internet exchanges.

Hybrid CDN: Best of Both Worlds?

The unique strength of Commons Host is the ability to combine datacentres across Europe, America, and other regions, with a vast network of micro-servers deployed worldwide.

Designed for this scale, everything in deployment and management must be fully automated and made as easy to use as possible.

Based on these principles, Commons Host offers a great hosting platform for truly global static web hosting, with more to come very soon.

Los Angeles, United States of America 🇺🇸

Sebastiaan Deckers — Fri, 07 Sep 2018 12:09:38 +0000

Go West, young CDN.

America, birth place of the Internet, joins the Commons Host CDN with an edge server deployed in Los Angeles, California. As the largest city in the most populous state, this is a great location for low latency static site hosting.

Photo: Los Angeles, by Jelle Bleyenbergh (Flickr)

Millicast WebRTC CDN

This edge server is sponsored by WebRTC specialists CoSMo Software. Its polymath founder Dr Alex is a WebRTC industry insider and long time supporter of the Commons Host project. WebRTC enables open-standards based media streaming in browsers and devices. (More exciting news to follow!)

Hosting of the server in LA is provided by Millicast, a WebRTC-powered live streaming CDN offering incredible sub-500 milliseconds latency for large scale broadcasts. Millicast is a collaboration between CoSMo and Xirsys as provider of TURN cloud services.

Photo: Selfie by Richard Blakely, CEO of Xirsys and cofounder of Millicast, with Commons Host µPoP server. 🤙🏻 for scale.

Together we serve, divided we scale.

This deployment is a small start, literally and figuratively, into the American CDN market. Obviously, many established American tech companies already provide competitive hosting and edge delivery services.

But what Commons Host offers is seamless extensibility into any location around the world. This offers better performance, cost savings, and unique operational capabilities.

The ability to extend the Commons Host CDN by deploying your own edge servers on-premises is made affordable and effortless thanks to open source software and hardware.

Join the Commons, deploy today!

Vilnius, Lithuania 🇱🇹

Sebastiaan Deckers — Fri, 20 Jul 2018 09:33:23 +0000

The Commons Host CDN has placed its first footprint in Europe with a point-of-presence (PoP) in Vilnius, Lithuania. This takes the network beyond its South East Asian roots.

Photo: Sergei Gussev (Flickr)

The PoP, a Little Lamb Mk I micro-server, is sponsored and hosted by Zygis, an early days supporter of the Commons Host project. His expert advice over the past months has been very encouraging and significantly accelerated the rollout.

Photo: Zygis showing off sheep swag in Vilnius (selfie)

Automation with Ansible

The main challenge with this deployment was the physical inaccessibility of the server. The initial PoPs in Singapore and Kuala Lumpur were deployed by hand: visiting on-site to install and configure the system. However it would not have been cost effictive to travel from Singapore to Lithuania to deploy a single server.

This was a job for Ansible, a Configuration Management (CM) automation tool. Over the past two months Kenny Shen and I collaborated on the complete automation of Commons Host PoP deployments.

Photo: Kenny Shen operating next-level hacker keyboard

We now have the ability to set up, secure, and monitor the servers remotely. All code is available in the commonshost/ansible GitLab repository. Contributions welcome!

More to Come

This newly created tooling will be the foundation for many more deployments, both physical machines as well as cloud servers.

The Vilnius PoP serves currently all Commons Host traffic for Europe, as directed by the Geo DNS load balancer. This is really not as much as it sounds like, yet.

Over the coming months more effort will be made to promote the service to developers. To support the growing demand, additional PoPs will be deployed. As more servers are added to the network, the global traffic load will be better dispersed and optimised for low latency. Exciting times.

Cần Thơ, Vietnam 🇻🇳

Sebastiaan Deckers — Fri, 20 Jul 2018 07:28:45 +0000

The Commons Host CDN expands with a point-of-presense (PoP) in Cần Thơ, Vietnam. This is the largest city in the Mekong River Delta region of 17 million people. Just 150 km away is Ho Chi Minh City (HCMC), a metropolitan area of another 13 million people.

This massive population is drastically under-served by conventional CDNs, many of whom lack local infrastructure or peering agreements with incumbent ISPs.

Photo: Panorama of Cần Thơ by Chung Wei Tat at Hotel XOAI the FOSSASIA HQ

A Different Market

There is limited bandwidth going in-and-out of the country. While local datacentres do exist, they typically come at a hefty premium over similar infrastructure in more saturated markets like the United States. Commons Host is still just a tiny, free & open source service, so expensive datacentre co-location is out of the question.

That is where Commons Host takes a novel approach using open hardware and commodity fibre internet connections.

Open Hardware

The Little Lamb Mk I micro-servers, based on the Odroid HC-1 platform and running open source Node.js software, are ideal for hyper-local deployments.

Critical financial assistance came from Tien Nguyen, CTO at Wego, who purchased the server to support the CDN effort.

Commodity Fibre

Consumer fibre internet access is widely available in most Asian cities, including Vietnam. So the Commons Host PoP is connected via commodity broadband. The tiny power consumption means that a basic UPS has been enough to deal with intermittent electricity grid outages, resulting in 100% uptime over the first 3+ weeks of operation.

The physical hosting is generously provided by Hotel XOAI, also known as the FOSSASIA HQ. Several kind members from the FOSSASIA community stepped up to help. Firstly, Chung Wei Tat handled the logistics, i.e. packing the small server in his carry-on luggage. Then, Daniel J Blueman remotely handled testing and configuration of the network. Protip: Stay at Hotel XOAI for what is probably the best hotel wifi in Vietnam.

Changing the Game

Being able to affordably deploy many PoPs, across ISPs and cities, is ideal for CDNs in these markets. And for the local ISPs having a PoP on their network keeps traffic local which helps them avoid expensive transit fees. As the Commons Host CDN service gains traction, more and/or larger PoPs can be easily deployed to scale capacity.

Work has started to translate all the Commons Host website content and developer documentation. Part of deploying PoPs in new regions is helping local developers learn how to adopt it to better serve their users.

Many thanks to Tien Nguyen and the FOSSASIA community. Team work makes the dream work.