So last week was more steady progress, here’s the rundown of what I’ve been doing and will be doing next week.
DHCP servers maintenance
The new DHCP servers arrived and a base install was completed for both hosts (our new-ish teammate performing one of the installs). This week should see them racked up in their appropriate cabinets and the testing beginning. I’ve already prepared a plan for a deployment day but I’ll go back over it and do a dry run near the end of the week. We might be able to replace these in the Tuesday JA.NET at risk period on the 1st Feb depending on how well this week goes.
Off site servers
When moving a DNS warmspare offsite I hit a snag in that one of our off site locations belongs to another section and for various rather odd physical reasons we’ve run out of space at that site and it’s going to be disruptive to the site providers to fix the issue. We can’t complain too loudly (our section gets hosting there as a favour) so instead we’ve decided to take the three servers to another remote site but the dismantling, travel and re-racking might take up half a day.
DNS Warmspare
I’ve another DNS warmspare to install and deploy, I might do this before moving the off site servers so that I can rack it up at the same location.
IPv6 Firewall
The testing network is setup without any IPv4 and ICMPv6 is forwarding across the Firewall. I need to setup a sending and receiving host of some kind, I need to setup the failover configuration and then test the failover behaviour. This needs to be higher priority than the DNS and DHCP work due to political/management time frames.
DNS Web Interface
The DNS interface that local IT officers used has had a bug fixed (Warts and all: originally reported in September – sorry I had to prioritise) where there was case sensitivity in a created DNS record, causing an issue in CNAME records being rejected by the web interface at creation time. It’s hard to believe that the bug has been there since the interface was originally written over a decade ago but it has. The reporter mentioned it should just be a case of ‘strtolower’ or similar on the users input, which indeed sounds a sane assumption – for instance I can’t stand web applications that make me manually format whitespace in a postcode instead of the lazy programmer writing something to do it on the backend and how hard can it be to lower case user input?
Sadly the dns interface is 4k+ lines of code with no comments, no Perl ‘strict’, ‘warnings’, HTML in with the code, single letter variables and all variables are globals (in the Perl sense, not the PHP sense). The interface also seems to use deliberate user input case sensitivity in certain places and due to the way the data is trackedby the application, might delete all your CNAMEs if the case sensitity fix is incorrectly implemented, which I luckily discovered when testing on our dedicated test data. Anyway, it appears to be fixed now.
Since I was working on it I’ve also done some additional minor work so that the success and error messages uses our modern CSS styles to make them stand out – we get a lot of RT helpdesk queries to the team from people that have missed the error message the interface was trying to tell them since it didn’t visually stand out.
[edit] This went wrong – I tested on data that included no MX records. The interface handles aliases and MX records in the same process and in production decided it would delete and recreate all MX records whenever the edit page was a submitted – this caused some issues. I think I’ll have to document the interface as having a case sensitive bug and leave it for another decade.
I reverted the case sensitivity fix but left the interface visual changes in (I try to do separate SVN commits when fixing different issues so if needed the specific changes can be rolled back quickly)[/edit]
Possibility of [www.]ox.ac.uk having a AAAA for the Global IPv6 Day
Last week I made initial approaches the three groups that make up the www.ox.ac.uk provision. We’ve meeting arranged for Friday 28th to discuss the politics and technicalities. Another (friendly rival?) university has already informally mentioned they will be IPv6 enabling their main site address for that day. I don’t know about respective plans for lboro.ac.uk and soton.ac.uk but knowing their staff I suspect they’ll be prime suspects for taking part.
Broken IPv6 websites for Testing
For some a testing scenario I’ve setup two broken websites. Both of the follow sites should work fine if you’ve an IPv4 only host. If your host is dual stacked then the behaviour I suspect you’ll see is documented below. An IPv6 only host should get neither site.
http://broken-ipv6.oucs.ox.ac.uk/
This site has working IPv4 connectivity but IPv6 connections are being silently dropped by a firewall as a simulation of a misconfigured server.
On a dual stack client that favours IPv6 you should see a long delay (~20 seconds?) followed by success.
http://broken-aaaa.oucs.ox.ac.uk/
This site has working IPv4 connectivity and a correct AAAA DNS record exists but the webserver is not configured to listen on the IPv6 address as a simulation of a transitioning or otherwise misconfigured server.
On a dual stack client you may seem to be instantly connected to the host, the web browser trying IPv4 after getting the refusal on IPv6.
I’m not sure the site names are perfect but they’ll do. These sites aren’t to prove any point, they just exist and are there for technical behaviour confirmation on different hosts/software. If you use these, please sanity check the behaviour before each formal testing session in case one day I’m no longer here and someone discovers these sites and mistakenly ‘fixes’ them.