You could consider this one of the Good Practices for security, but I typically do not encourage the use of the default web site as many different microsoft products like to slap all kinds of services into the default web site folder that really should not be exposed to the Internet at large.

So I pretty much make a new web root, use host headers to identify what requests this root should respond to, leave the original default web site running with an unassigned IP and unspecified host header, but then deny access to the default from all IP's other than local IP's.

That aside, based on your specification, I think this is a workable solution. Also, let me be clear on what I interpret your specification to be. You want to take requests for www.domain.com and domain.com and then send them to a site that will serve domain.com. Correct?

First, you're going to need to configure DNN to only use the domain.com alias for the portal. You'll need to actually access the site's host account using the domain.com address. You can't delete an alias if that alias is the alias you are using to access the site at the point in time. Once in, remove the www.domain.com alias.

Second, if you block external access to your default web site (which again, I highly recommend), you'll quickly observe that anyone still requesting www.domain.com is going to get an error message. Ideally, what we'd like to do is instead use a redirection method to instead display the domain.com address.

You'll need to find out exactly what error is being displayed, and then go into web root's "Custom Errors" section and instead of pointing to the error file, point to a new file that will contain the redirection code. Something like this.

Serious DKP modules for serious DNN gaming communities.