There is a debate in our company regarding if DNS changes should be a function of Change Mgmt. I'm curious about your feeling in this regard. Is there an "official" ITIL stance regarding DNS changes and Change Control?

I understand that you are discussing it and that there must therefore be some people for and against submitting DNS changes to your overall Change process.

I would personally see it as a change as you are altering a part of the Configuration. However, that does not mean that a CAB needs to be convened every time a change needs to be applied. You could very well draw the boundaries of a Standard Change for that. As long as the standard change is documented, that the procedure is controlled, measured and followed, there is no reason to believe it wouldn't work properly.

But also, you can try that and see if it works. If you see that you are getting incidents that you can trace back to those changes, then re-assess and try something a little different.

For instance, you could also consider that it may be a specific change for which you only want a CAB composed of 2-3 people cherry picked and that they will only meet on an ad hoc basis. Define the procedure in a Change Model. That will make it a bit more formal, but not as formal as other changes.

DNS changes if they screw up can not only screw up your own company but others as well.

SO they need to be managed and controlled - in an appropriate manner.

So if the DNS change fits in the corporate definition of a change request that does not require a CAB - Standard and Normal ITIL - then use then otherwise come up with a way to manage them

ALSO: BE advised that one of my DNS gurus says tha any DNS change once done takes about 24 hours to propogate through the entire internet.
I say this because some people demand DNS changes within 1/2 of making the request. And then complain when the change has not had time to propogate

Locally the DNS change is usually immediate.. but think outside your own AS and it takes times._________________John Hardesty
ITSM Manager's Certificate (Red Badge)

In most enterprises, DNS changes are definitively under Change Control, as it changes a critical operational configurations that drive how your enterprise work. Ask yourself this: "If I change a DNS entry, can something break in production?" The answer is, "yes". The primary purpose of Change Control is to coordinate the types of Changes that can impact your Production environment.

We do these as a Standard Change - i.e.we know the risks, the process can be put into a procedure (set of steps to implement), and this allows the techies to make changes where needed without impacting the service unduly (done Out Of Hours).

- new DNS entries are considered standard changes and are not routed through CM/RM.
- modification & removal of DNS entries are subject to RFC and CAB review as they imply impact to systems which have not been cleanly updated to reflect the new names.

That being said, we are very slow about removals for fear of impact...

Not sure if any of you use NetDirector (www.netdirector.org) - it's essentially an open source CCM tool. It has role-based access control to enforce segregation of duties and it has an embedded database that keeps track of all changes - what was done, who did it, etc.

Limitations are it only works with Linux and Solaris. It has service modules for Apache, BIND, Samba, Email, FTP, LDAP, Kerberos and a few more services as well.

It's completely free and open source and available for download from sourceforge.

In our organization DNS changes Add/Remove/Delete have been determined to be standard changes. We have documented the set procedures for performing the necessary steps along with communications that take place ahead of time for those application owners that may be impacted by a change to the DNS. Also and the most important is the rollback(remediation) steps in the event that an issue does arise is apart of each request along with the time it would take to replicate across the organization for service restoration. A review is performed after each implementation.