As a rule of thumb, an application server should never face the Internet directly, unless of course Nginx (or OpenResty) is being used as such. This is not only for performance reasons, although this is not much of a concern anymore with modern runtimes such as Go or Node, but mostly for flexibility and security reasons.

Here are some key points to consider :

At this point, Nginx is a proven and battle-tested HTTP server

This allows keeping the application as simple as possible : Nginx will handle logging, compression, SSL, and so on

In case the application server goes down, Nginx will still serve a 50x page so visitors know that something is wrong

Nginx has built-in load-balancing features, it also allows running several application servers on the same IP address

Nginx has built-in caching features (with on-disk persistence)

Nginx has rich rate-limiting features, which are especially useful for APIs

Lastly, one aspect which tend to be forgotten these days is the importance of server logs. While in some cases it might be an accepable solution to use Google Analytics or Piwik, for measuring APIs traffic however, there is no better option. For a modern real-time log analyzer, I heartily recommend GoAccess.

Given NetBSD focus on portability, it’s only logical that pkgsrc is also available on systems other than NetBSD, including Darwin (Mac OS X). Here are some notes showing to bootstrap pkgsrc in unprivileged mode, which means that everything can easily be installed in the user home directory.

Before starting, we need to install Xcode Command Line Tools to get a working compiler.

Using binary packages

Final words

After running Fink in 2009 on my Mac mini, and then Homebrew since late 2011 on my MacBook Pro, it’s nice to explore alternatives especially since they are not mutually exclusive. It’s in fact a nice idea to combine pkgsrc and Homebrew to get the best of both worlds and access to even more packages.

Lastly, for a comprehensive searchable database of packages, please check the excellent pkgsrc.se.

As an experiment, I’ve been using fpdns (version 0.10.0 on FreeBSD/amd64) to fingerprint DNS servers authoritative for the top 1 million domains (according to Alexa).

At first, I had plans to use adnshost to resolve name servers first and then feed the resolved list to fpdns, in order to speed up things and avoid fingerprinting the same host several times. Unfortunately, it seems adnshost doesn’t work that well on large batches and I experienced numerous timeouts and crashes.

Over the past few years, I have been exploring various options for doing local DNSSEC validation. Validating locally is necessary in order to avoid DNS answers being forged on the path from the ISP resolvers (or from open validating resolvers) to the local network.

If validating on servers and laptops is a solved problem, doing so on mobile devices such as phones and tablets is still an open question. For these use cases, having a validating resolver running directly on a router is convenient. As it turns out, it’s a pretty simple two steps process to achieve this with OpenWrt.

Disabling Dnsmasq DNS component

Dnsmasq is used within OpenWrt as both DHCP and DNS server, but we only want to use its DHCP component and let Unbound perform DNS resolution.

Installing and configuring Unbound

/etc/init.d/unbound
Syntax: /etc/init.d/unbound [command]
Available commands:
start Start the service
stop Stop the service
restart Restart the service
reload Reload configuration files (or restart if that fails)
enable Enable service autostart
disable Disable service autostart

We start Unbound and enable autostart at boot time :

/etc/init.d/unbound start
/etc/init.d/unbound enable

We also need to fetch (or update) the root anchor manually :

opkg install unbound-anchor
unbound-anchor-a"/etc/unbound/root.key"

Configuring Unbound to validate answers :

# If you want to perform DNSSEC validation, run unbound-anchor before
# you start unbound (i.e. in the system boot scripts). And enable:
# Please note usage of unbound-anchor root anchor is at your own risk
# and under the terms of our LICENSE (see that filein the source).
auto-trust-anchor-file: "/etc/unbound/root.key"

We can easily verify that our local Unbound instance is answering queries :