So I havent written anything in a while – being a sysadmin seems to take up a disproportionate ammount of time.

Today my anecdote comes from the land of bad IT practice – and what I have to say here might not seem to be bad practice at first glance, but bear with me.

We were approached by a client to transfer a domain to our server. Let us call it domain.com for the purposes of this discussion.

The sysadmin who handled domain.com previously had the following set-tup:

And on-site group of servers that is (currently still) served by a business-dsl line with a range of IP-Adresses allocated. Lets say that range was 196.1.1.3; 196.1.1.4; 196.1.1.8 and 196.1.1.20.

These adresses pointed to various services running on those servers, mail.domain.com, www.domain.com, sslvpn.domain.com and ssh.domain.com.

To sweeten the deal 196.1.1.3 also acted as a DNS server – in other words it had it’s own DNS host service running that would update IS servers with the name of where to point requests for www.domain.com.

When the IT guy left the company we were approached to transfer domain.com to our servers. This was done, but we ran into the following hitch: the DNS records for domain.com refused to update properly – the DNS server sitting at 196.1.1.3 was never updated and insisted that our records were inaccurate. We were essentially stuck with a rogue DNS server.

Eventually that was sorted out, and the domain records populated correctly. Next I get a senior member of our company storming into our office very agitated that his client (who is a large company, mind you…) could not receive mail, and that half of their site was broken.

Immediately I went to check on our DNS records on the server – and realised where the snag was. Upon request of domain.com’s move we were never informed that they have an exchange server set up on their lan.

I got on the phone with the poor sod who had to sit on site and figure out what the preivous sysadmin at the company did with his firewall rules to direct traffic to different servers.

Between the two of us we had to figure out:

1. How internal LAN traffic was forwarded to domain.com – the reason for this was that internally they still saw the old site.
2. What the IP adress of the domain.com mailserver was – I simply needed to update our DNS records to point to their mail server, but nobody at the company knew what the server IP was.
3. The IP adress for sslvpn.domain.com – when you logged in to a specific area on the website it redirected to this address to allow registered members of this company to access and edit records.

As of now we are still unsure what the correct mailserver address is.

The moral of the story?

• Document what you are doing – especially if you are setting up a complicated firewall. Trying to sort through firewall rules without any comments is very frustrating.
• Keep all involved parties in the loop – let the new hosts of your website know of all relevant services that are related to your site. Many sites have hyperlinks to services that lie on other servers – such as privately hosted databases. If we don’t know about them we will not point your traffice in the correct direction!
• Make sure you have a clear understanding of what your IT personnel are doing – in case one of them leaves you must be able to converse with your support team about what needs to be done.

In our case with domain.com we did not have a clear picture from the client about the setup at his premises – nor did the client it would seem.

We handled this like a normal domain transfer – and it blew up in everyones faces. If all the parties involved were aware of the onsite mail server, the specialised services and the domain transfer (apparently the contracted IT specialist was not even aware that we were taking over hosting of the domain) then things would have gone much smoother.

A few simple operational procedures can make all the difference in the IT world.

No related posts.