This is my first post in a couple of weeks. I’ve been busy tidying up a lot of loose ends in preparation for officially leaving my employer of 17 years. You know the kind of thing – carting out truckloads of office knick-knacks, posters, correspondence and coffee cups, archiving gigs of email, and finally giving back keys and cards.
In combination with Garry’s post on DHCPv4 and DHCPv6, I got to thinking about some of the services I had been responsible for or set up over the years, and the fact that the network team I am leaving is no longer responsible for those things. The advent of virtualization has seen endless debate over who is responsible for the networking where the line blurs. Does the server team manage the vSwitch or Nexus 1000v because it is in the server hardware, or does the network team do the networking? But this is not the first battleground over demarcation, and won’t be the last.
To take two examples, DNS and DHCP are fundamental services in the network. Without these two services working correctly in the enterprise, the network is dead. So who owns these services? Who should own them? I have always been of the opinion that as they are integral to the operation of the network, the network team should have responsibility for these services. When the team I was working in had responsibility for them, I guarded them jealously. Ah, the days of compiling fresh binaries of BIND and DHCPD.
However, as virtualization blurred the boundary between server and network, there was a technology that came along that upset the network team’s hegemony over DNS and DHCP. That was Active Directory. As this began to be deployed in the organization, along came consultants who convinced the management and the server teams that these services were now theirs. This was somewhat helped by the decentralized nature of our organization at the time. As new domain controllers took over, the BIND DNS servers were decommissioned, and each department gleefully gained control over “their” IP address space and no longer required the services of our DHCP server.
Of course, poor implementation (of the Microsoft products themselves and internal deployment) resulted in no redundancy for DHCP, so all of a sudden, “network” problems would be reported when a Windows DHCP service was corrupted, and people complained about servers not being accessible from the net as admins had used non-RFC 1123 characters in their DNS names. (I know, underscores are permitted in RFC 2782 and so on, but this was when NetBIOS names were prevalent – never mind, old person rant aborted). As I leave my employer now, services have been centralized, but DNS and DHCP have steadfastly remained in the server space, with the same consequences for users. After plenty of debate (and me pushing the issue), it seems that the mindset may be changing now, with some tentative investigation of dedicated DHCP and DNS appliances, but change will be slow. Of course, one of the big reasons for a re-evaluation of DHCP and DNS services is the rollout of IPv6.
Now, I know that as network engineers we often have enough (or too much) on our plates as it is, and many of us would be grateful if someone else is assigned one of our responsibilities. However, I would argue that there are some services which are integral to the operation of the network, and as such should be the responsibility of those that operate the network in the enterprise. DNS, DHCP, and NTP are the basics. If you aren’t assigned responsibility for these services, then you should cultivate a good working relationship with those who are, because at some point you will need to work with them, whether it be in troubleshooting or when you are doing design and address allocation for that upgrade or new building.
And finally, go read Garry’s post. And freshen up on how DNS works, too - learn how to use dig. Just because these things run on servers doesn’t mean they aren’t part of your network.
About Matthew Mengel
