After the deployment if IPv6 to the cluster, I’m hoping to set up several other technologies including squid caches, local hosting of the master dns zones (stealth primary), and ultimately an ssl endpoint.

Squid needs to be tested with all the software and tools that are running, mainly things like phpBB, MediaWiki, and WordPress – I really don’t want to get rid of all the IP tracking for things like banning users from posting. MediaWiki should be OK with it though, since that’s what Wikimedia use for front-end caching along with Varnish. WordPress is mainly read-only, with a bit of moderated commenting, but by far the most used system is phpBB – not on my site, but on other sites hosted by me.

I might just end up leaving the DNS records pointing directly to the backend server, but Squid pass-through would be good for getting hit stats etc.

One of the other sites I’m hosting seems to be building it’s own software, and I’m unsure what IP retrieval they’re doing for that – but they’ll need to keep an eye out for X_FORWARDED_FOR.

I want to set up my own nameservers so I can manage DNS from within Puppet, and hence from any machine which has the puppet repository on it. Another reason is to get an internal TLD running, so I will finally be able to use internal-only addresses and force systems to use the internal networks, rather than potentially leaving and re-entering the network.

SSL is an interesting one because of the way the network is set up. To make things a lot easier for management, we use name-based virtual hosting bound to a single IP address. The name of the site is provided to the web server as part of the HTTP headers, so the web server only knows what site to serve when it has received this header. However, with name-based virtual hosting, the certificate that needs to be served to the client depends on which site is loaded. Unfortunately, the correct certificate needs to be sent before the web server retrieves the headers. It’s a bit of a problem.

Thankfully, the solution to this should come with a technology known as SNI – Server Name Indication. It’s an extension to SSL/TLS and provides the “hostname” of the server as part of the handshake so the server can respond with the correct certificate. The problems aren’t completely solved though – while most modern browsers support SNI, there are some combinations which don’t work (namely those browsers which use the Operating System’s version of OpenSSL), including Safari and IE on Windows XP, and the default browser on Android 2.x.

Before deploying this, I want to monitor how many users I have who will be presented with a certificate problem when browsing various sites, and see if the number of users is small enough to make it worth the problems.