It's a common misconception with DNN that the /default.aspx at the end of Urls maps to the /default.aspx page. The actual fact is the /default.aspx is just there to make it look tidy and end in .aspx, and doesn't map to anything at all. For example, you can refer to this forum thread as http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/118/threadid/333587/scope/posts/anything-you-really-want-to-say.aspx
And the above Url will work just fine. The default.aspx at the end is just a placeholder.
With a few very isolated exceptions, all requests for DNN map back to the root /default.aspx page.
There simply is no 'module settings' aspx page or anything like that.
All DNN page content is displayed by the base /default.aspx page deciding on which controls (.ascx) files to load and display. This is determined by several things: the presence / absense of a /ctl/control-name in the url, and a moduleid/xx in the url. If no moduleid (or mid, the two are interchangeable) then the page loads all modules for the page. With no /ctl/ in the url, the page loads all controls for the module.
In order to determine which actual code is run for a certain page, you need to look at the database, working backwards from the Module tab (specified by the mid, or, if absent, by all records in the TabModules table for the tabid), to the ModuleDefinitions, to the ModuleControls (specifed by the /ctl value, or, if absent, all controls for the module where the 'ControlKey' is null). In the ModuleControls table you will find the ControlSrc value, which will tell you which usercontrol (.ascx) file is run for the individual Url.
While all this obfuscation seems over complicated, it's precisely this structure that gives the DNN framework such flexibility.