Domain Transfer, WHOIS Privacy, DNSSEC, and the Absence of Push-ups

Annual Domain Transfer for Profit

Since my first domain name in 2006, I have purchased several domain names for my various websites. A few years ago, I discovered a secret in the domain registration business: many registrars offer a cheaper price for domain transfer than domain renewal, as a means to attract new customers. Therefore, if I transfer my domain every year to a different registrar, I would pay less than renewing the domain at the same registrar.

DNS services for a domain used to be associated with the registrar. When I transfer a domain away, the DNS server of the old registrar would stop responding to queries regarding my domain, and the DNS server of the new registrar does not yet have any records about the IP addresses of my web server. Therefore, a domain transfer would usually cause the website to become inaccessible for a day or two. Typically, I post a tweet when a domain transfer is about to happen, so that my readers could know why my website is down.

Nowadays, I'm using Cloudflare DNS for most of my domains. Cloudflare DNS server is independent from the domain registrar, so that my website continues to resolve correctly throughout a domain transfer, as long as neither registrars modify the name server delegation records. In case the new registrar automatically updates the delegation records to their DNS servers, I have to quickly login to the control panel and change it back to Cloudflare, which would then cause a brief downtime of the website. Having done so for many years, I am accustomed to this process.

Transfer of

Intel iGPU VAAPI in Unprivileged LXC 4.0 Container


I recently bought a DELL OptiPlex 7040 Micro (paid link) desktop computer and wanted to operate it as a dedicated server. I installed Debian 11 on the computer, and placed it into the closet to be accessed over SSH only. To keep the host machine stable, I decide to run most workloads in LXC containers, which are said to be Fast-as-Metal. Since I operate my own video streaming website, I have an LXC container for encoding the videos.

The computer comes with an Intel Core i5-6500T processor. It has 4 hardware cores running at 2.50GHz frequency, and belongs to the Skylake family. FFmpeg is happily encoding my videos on this CPU.

As I read through the processor specification, I noticed this section:

  • Processor Graphics: Intel® HD Graphics 530
    • Processor Graphics indicates graphics processing circuitry integrated into the processor, providing the graphics, compute, media, and display capabilities.
  • Intel® Quick Sync Video: Yes
    • Intel® Quick Sync Video delivers fast conversion of video for portable media players, online sharing, and video editing and authoring.

Use NFD nightly with Mini-NDN

Mini-NDN is a network emulation tool that enables testing, experimentation, and research on the Named Data Networking (NDN) platform. It uses container technology to emulate a small-to-medium NDN network topology. Each container represents a network node, in which it runs NDN Forwarding Daemon (NFD), NLSR routing daemon, and other NDN programs. Virtual Ethernet adapters are added between containers to simulated network links.

During the recent 12th NDN hackathon, I worked with my buddy Saurab Dulal to improve Mini-NDN. One of our achievements was a shiny new Mini-NDN installation script. The new script can install NDN software binary packages from named-data PPA, which saves time significantly compared to the alternative of compiling from source code.

However, a drawback of named-data PPA is that, the binary packages available there are only updated after each NFD release, which occurs a few times a year. If it has been several months since the release, the PPA packages would be ancient. They would not include the latest features, improvements, and bug fixes in the NDN codebase.

If you want to use up-to-date NDN software, but do not want to wait for the software to compile from source, I can offer another option: install the weekly automated builds from NFD-nightly. This article explains how to do that.

Operating System

NFD nightly APT repository

This article contains instructions of NFD nightly APT repository, which provides automated builds of NDN Forwarding Daemon (NFD) and related software.

This article was latest updated on 2021-10-30 to reflect latest changes.


To install NDN software from NFD nightly APT repository:

  1. If you have previously installed NDN software from named-data PPA or source code, you need to delete them to avoid conflict. See switch between installation methods section below.

  2. Visit webpage, choose your operating system and CPU architecture, and you'll get a setup command.

    Run this setup command in the terminal, which adds NFD-nightly as a package source.

  3. Update package lists:

    sudo apt update
  4. Install desired packages, such as:

    sudo apt install nfd ndnping ndnpeek infoedit

    You can see available packages on webpage.

NDN Video Streaming on the ndn6 Network

The ndn6 network, my own global scale Named Data Networking network, came back earlier this year. I moved my NDNts video streaming app into the ndn6 network, to reduce dependency on the NDN testbed. How well is it performing?


In my last article "NDN video streaming over QUIC", I used Chrome browser's experimental QuicTransport feature to perform video streaming over Named Data Networking. The analysis revealed that QUIC transport was generally performing better than WebSockets in this application, according to metrics including video resolution and startup latency.

Web technologies are constantly evolving. QuicTransport was in Origin Trial status at the time, but it was discontinued as of Chrome 91. WebTransport was introduced in its place. The main difference is that, WebTransport uses HTTP/3 as the underlying network protocol, while QuicTransport uses QUIC datagrams.

Since HTTP/3 runs over QUIC, I expect no performance difference between the two. I promptly registered for the WebTransport Origin Trial, and updated my gateways and NDNts libraries to use the new API.

Return of the ndn6 Network

In 2014, I installed NDN Forwarding Daemon (NFD) router on a tiny 128MB virtual machine. I named this node ndn6: IPv6 NDN router, because the virtual machine, purchased from the original Low End Spirit forum for €3.00/year, was an IPv6-primary service. I idled this router for three years, and then shut it down in 2017.

I created NDNts: NDN libraries for the modern web in 2019. Since then, I have been publishing my own content over Named Data Networking, most prominently the NDN push-ups. NDNts does not require a local forwarder, so that I operated video repositories by directly connecting to a nearby testbed router via UDP tunnel. Shortly after, I started experimenting with QUIC transport, which involved deploying several NDN-QUIC gateways to translate between NFD's plain UDP packets and Chrome's QUIC transport protocol.

One day, I realized: my content is sent to the global NDN testbed, and then retrieved back to my servers for delivery to browsers over QUIC. My video repository in Buffalo and NDN-QUIC gateway in Montreal are quite close to each other, but the packets are taking a detour to Boston, increasing latency by at least 10ms. Also, since I statically assign a testbed router for each application, a downtime of that router would bring my application offline as well. I thought, instead of operating isolated applications and gateways, I should setup my own NDN network.

Setting up a new NDN network is no small feat. NFD and NLSR implement forwarding and routing, but I also need to:

  • Decide on a topology between different routers.
  • Assign a name prefix to each router.
  • Install and update software in each router.
  • Generate configuration files for NFD and NLSR, and modify them as the topology changes.
  • Monitor the network and know about ongoing problems.

Today I Learned: openat()

fopen and open

In C programming language, the <stdio.h> header supplies functions for file input and output. To open a file, we usually use the fopen function. It is defined by the C language standard and works in every operating system.

Working at a lower level, there's also the open function. It is a system call provided by the Linux kernel and exposed through glibc.

Both fopen and open have an input parameter: the file pathname, as a NUL-terminated string. These two functions are declared like this:

FILE* fopen(const char* filename, const char* mode);

int open(const char* pathname, int flags);

Stardate 1302.8

Stardate 1302.8, San Francisco.

Just as I'm ready to shut the doors of yoursunny summer host sales office and spend the weekend with my snake collection, a customer rushed in. The customer shouted hurriedly: my storage server in Midwest Eurasia is involucrated, routing announcement is withdrawn, all my family memories are gone, can you help?

I opened my sleepy eyes, downed a bottle of Red Bull, and immediately started helping this customer. I sent a robot to the garden where her storage server was located, and provisioned a new storage server in our luna location. Within seconds, the robot found the original server and plugged into its USB port, and her precious data were being cloned to our infrastructure. At the same time, I was busy engraving a golden key card that contains a private key to decrypt the data.

15 minutes later, data restoration was complete, and I opened up the portal room. The customer swiped the card, a colorful cloud appeared on the portal. Inside, there's a faint wall of text:


Deep Atlantic Storage: Streaming Bits

I'm bored on 4th of July holiday, so I made a wacky webpage: Deep Atlantic Storage. It is described as a free file storage service, where you can upload any file to be stored deep in the Atlantic Ocean, with no size limit and content restriction whatsoever. How does it work, and how can I afford to provide it?

This article is the third of a 3-part series that reveals the secrets behind Deep Atlantic Storage. The first part revealed that the uploaded file is sorted which drastically reduces its storage demand, and introduced the bit sorting algorithm. The second part covered how to process the upload in the browser using Web Workers. Now I'd continue from there, and explain where I store the files and how I offer downloads with reasonable costs.

Storage in the URL

Deep Atlantic Storage sorts the bits in every uploaded file. After sorting, each file can be represented by two numbers: the number of 0 bits, the number of 1 bits. Given these two numbers, the sorted file can be reconstructed.

I could make a database or use one of those fancy NoSQL thingy to store those numbers that represent the files, but I prefer my websites stateless so that I don't need to take backups. Therefore, I decided to encode those numbers in the URI.