All New Authoritative and Resolver DNS servers
The last DNS resolver and all of the DNS authoritative servers have now been migrated to new hardware, the resolver having being migrated approx 6:10am this morning. There’s other work I’d like to do on the DNS, such as internally documenting any differences between our own and the Team Cymru Secure Bind template , or adjusting our configuration to match. At first glance perhaps specifically with regards some of the more minor types of logging (lame servers etc), but this a minor secondary project that will have to wait (I keep a list of these for when a miracle occurs and I have spare time).
The question on how to create IPv6 DNS records for clients was a concern but interestingly a draft RFC was published in September that covers exactly this topic. There’s also work to be done with regards to IPv6 enabling the auth and resolvers however I’ll talk about something a bit more exciting this week, which is namely our first IPv6 user networks for testing
IPv6 on the OUCS Offices Network
The political process for enabling IPv6 on the OUCS Offices network is coming to an end. The ICTST team provide the unit level IT support for OUCS, and I’ve been querying approval for a limited IPv6 deployment on the OUCS offices network. My hope is that enabling this early on will encourage IPv6 testing among some of the core services teams – I’ve already had queries from NSMS and the Systems Development team. It sounds as if this will be approved so I’ve also been checking with the security team to ensure they’re happy with the deployment going ahead since on the local network we have to be able to track misuses down to a host/person just as any other unit would.
I’m not sure full blown IPv6 on the network would cause much issue in terms of application/service support since at least some of the Windows workstations appear to be already using the JANET 6to4 service to connect to IPv6 enabled services without either our assistance or the users knowledge. While there are firewalling considerations to be careful of, this connectivity is something I’m not going to complain about since it’s quite useful (in terms of testing/verifying) to have IPv6 based connections occurring from our users to IPv6 enabled services.
The plan is that if ICTST give approval we will first enable IPv6 for only one machine (the network will not have router advertisements on it initially, so it will be statically configured), we’ll then generate some standard harmless network traffic from it. At this point we stage a security response when the machine is said to have been compromised and the networks and security teams check our normal logging and security tools to ensure we can track the host down and take actions to block it. This should uncover any quirks or deficiencies in our logging or toolsets. To make the test valid the machine will be a single stack (IPv6 only) since it’s the IPv6 logging and tools we need to check.
In preparation we’ve already upgraded Netdisco to the latest CVS version which can handle IPv6. IPv6 name resolution doesn’t appear to work in the latest CVS but this doesn’t hinder us at all and looks fairly simple to fix. If I get a chance (another task for the list) I will investigate and may submit a minor patch for consideration.
IPv6 on the Mathematical Institute Network
I believe it’s now been two years since I approached the Mathematical Institute and asked if they’d be willing to take part in a IPv6 trial. They’ve been far too polite by not pointed out the passage of time (which I originally optimistically stated would be months) but today we’ve supplied them with an actual native IPv6 connection for testing.
This is quite early for us in terms of the services we provide being IPv6 capable so there’s a fair few limitations, as a result this is clearly not a production deployment. However I wanted to get at least one interested customer on the IPv6 service as soon as possible so that they can start bringing up issues that might be obvious to themselves that we haven’t thought of – for instance due to local contact with common applications that might have odd quirks.
So the provided connection in brief:
- Initially it’s just a /64 out of the eventual /56, it’s suitable for familiarisation with IPv6 until a IPv6 unit firewall is prepared
- We don’t have a clean solution for DNS changes at the moment, this is being worked on
- As mentioned last week, the university IPv6 firewall needs replacing with a production system
- stateless DHCP and Router advertisements are provided
- Advertised via the stateless DHCP, a single IPv6 DNS resolver is provided (later this will be replaced with the production service)
In security terms and from our immediate teams perspective things are politically easier for us than if it were the OUCS offices network – if a compromised address can’t be tracked to a host/user by the Mathematical Institute we’ll have to cut the development IPv6 feed off. This rather simple situation for us isn’t especially helpful for the local ITSS however, so I’ll prepare a suggested toolset for IPv6 adoption to assist. For instance the already mentioned NetDisco (CVS version) will provide the information required. Not everyone has the time to setup new services so I’ll also check if perhaps NSMS could offer a local unit controlled version of the toolset on their new ‘FiDo‘ device since it would have network presence in a unit as part of the wake on lan facility/green IT. It might be too heavy a load for that device but Netdisco can be split into parts (web interface, database, probe) so we’ll see.
Next months work
It’s probably time to redo my predicted IPv6 related work for the next month since for one reason or another it’s drifting off course from last months prediction.
- Subject to ICTST approval, deploy IPv6 to teams that request it for desktop systems in OUCS
- Assist the Mathematical institute with their IPv6 connectivity
- Deploy IPv6 on the new Networks Technology Group Service Network in order to enable more services (this is complex and may take most of the month)
And the 101 more minor tasks that don’t seem IPv6 related at first but are part of the critical path and are large tasks
- Finish migrating our network monitoring host (Nagios etc) to new hardware/network
- Migrate our internal database server to new hardware
- Come up with a solution for a production IPv6 capable university firewall for the interim period between now and the scheduled backbone upgrade in 2 years time