Yup I have this too. Login as host provider and try HOST->Host Settings and try ADMIN->Site Log, ADMIN->Newsletters and I get the infinite redirect in FireFox.

System: WinXP SP3, SQL Server 2008 Express, IIS 5.1, .NET Framework 1.x, 2.x, 3.5 installed, FireFox 3.0.8

DOT NET: Okay so DotNetNuke's Dashboard reports version 2.0.50727.3082 is used.  But I updated web.config to reference 3.5.0.0 many reboot ago. (e.g. add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=...") 

In the IIS 5.1 console there is a dropdown to select ASP.NET version but only 1.1 and 2.0.xxx is displayed. I cannot select 3.5 even though it's installed. [bang head on concrete now]

IDEAS:

1. maybe we are in ASP.NET Framework config/install hell? I read some tech forums stating you have to install IIS directly after or before installing a new .NET Framework otherwise something doesn't quite 'take'.  Maybe we should stand on one leg and squak like a chicken while pressing Ctl-Alt-WTF?
2. Something doesn't seem right between the web.config setting of .NET 3.5 versus the 2.x ASP.NET selected in the IIS config.  I think IIS is not "seeing" the 3.5 installation and maybe I should not contradict these two settings.  Here's the rub -- I tried to specify 2.0.xxx in the web.config providers sections but IIS would encounter errors on startup. IIS would only recognize 1.1 or 3.5 for some bizarre reason???
3. File permissions. Okay so to remove any/all issue there I gave "Full" winxp file access to every known user, SYSTEM, ASPNET, NET LOGON, yadda yadda... still nothing

I agree with the previous poster. I am spending more time on install/config than building websites.  But whatever... this is how the uneducated learn :-)

Final entry on this one. I've now realized a very important comment made on this website about fixing the redirect loop in medium trust (search for "trust" in web.config). The comment is regarding something called the GAC. I glossed over the comment because I'm not really all that concerned with .NET programming (just like to install it and go). But apparantly if you don't know some of the basics of how the GAC works, as a web admin you are in a world of hurt.

When we all delete or remove or otherwise rename and disable "System.Web.Extensions.dll" from the dotnetnuke\bin directory, we are actually forcing DotNetNuke and the .NET Framework to go looking in the GAC rather in the \bin directory.  Turns out doing a "dir /s" or Windows Explorer search for the aforementioned DLL never finds it even though it is in the GAC safe and sound. Normal WinXP search utilities do not venture into the secret world of \windows\assembly -- the location of the Global Assembly Cache ("GAC").

So we are not really removing this dll at all; hence, DotNetNuke works happily if you have at some point installed a .NET version that has registered and properly installed System.Web.Extensions (AJAX) into the GAC. In my case, I had installed .NET Framework 3.5 prior to DotNetNuke and could therefore safely delete the version in my dotnetnuke\bin directory.

Mystery solved for now.

OK. My issue is solved.  Moving to Full Trust did NOT solve the issue. Switching to 3.5 blows up Engage Publish in a pretty nasty way. 

In my case it turned out that 1.6x of extensions wasn't the issue.  Because I am in the middle of a migration I have a hybrid environment using Ektron cms400 for my home page.  It runs as an index.aspx and does not use DNN.  For the pages that use DNN I had setup the DNN home page in the page settings using LINK URL to redirect to www.vanguard.edu, my site root.  In IIS I set index.aspx to be the first selected document over default.aspx.  This worked like a charm until the 4.9.3. DNN upgrade. 

I still don't know why but apparently DNN intercepts every request including those going to my non-DNN index.aspx page and sends them to my default DNN home page which redirects to www.vanguard.edu.  Infinite loop.

The solution was to remove the Link URL for www.vanguard.edu.  I'll just have to figure out another to make that page redirect properly or I'll have to migrate it asap.