I just reinstalled DNN because something got corrupted when i moved form 3.1 with the AD modules from TTT to 3.2.2.

I was hoping to setup DNN better this time, having gained some experience and learned lessons. Still experimenting, and not wanting to bother Operations too much at work, I am using my hosts file to fake headers for IIS, instead of true DNS entries. Keeping that in mind, i was trying to accomplish the following:

I created several entries: dnn.domain.com; dnn.development.domain.com; ug.development.domain.com; all pointing to 127.0.0.1

I installed a new website in IIS and had the host header entry filled with dnn.domain.com Installation went perfect, I could log in with the host username and password.

Then i added dnn.development.domain.com to the host headers in IIS for the same website and added it as a HTTP alias to the website. Unfortunately when i then point my browser to dnn.development.imageright.com, it does show me the website, but gives the logout option only and when I click it, it doesnt do nothing. I restarted IIS, cleared cash, etc etc etc. Nothing works.

Created a new portal, wondering if there is simply a problem with additional aliases, and maybe per portal only the first works. Wrong, ug.development.domain.com as the primary alias for the website acts the same way as accessing the first portal with the secondary alias. Even went back to the first portal, and replaced the entry in the database for the first alias.

When you say that you setup a Host Header in IIS, does that mean that you are using a server OS? 

If you want to run all of these portals off of a single IIS website, then you do not need IIS Host Headers.  IIS Host Headers are used to run two or more IIS websites on the same IP address.

DotNetNuke runs under one IIS website, and if you can get several different domains to point to the IP address that the IIS website is listening on (either through a Domain Name Server - DNS or the HOSTS file), then DNN can take over from there to allow the portals to be seperately addressed by those domains.  This is done by adding a Portal Alias entry to the portal. This entry represents the domain name to portal mapping.

If you make this entry directly in the PortalAlias table then the web application will have to be restarted because these entries are cached.

I'm not sure what is happening in this situation, but lets start small and work our way up.  Do you have more than one PortalAlias for the default portal (Portal 0)?  If so, do they both work to access the default portal?

If not, what IP addresses do you get when you ping these domains?  I'm assuming they will all be pointing to 127.0.0.1 because of the HOST file entries, but lets make sure.