The short answer - if your name server and web server are on the machine you are using or in the same domain that the zone is authoritative for it does not have to look far for the answer for a local http request. If you are looking up a name that is not cached on your nameserver, the resolver must hunt up the food chain to find the IP.
An Example:
Our local ISP had some serious name server issues (among other problems) so we set up our own on the cheap. It's not as fast as their caching name server, but it works all the time. Plus it is not as affected by peak (prime time) loads that the ISPs name server is subjected to (there are only 10 clients max). So we wait up to two or three seconds for uncached names all the time (cached names go BANG!), while the ISP - who keeps a larger cache due to the sheer number of lookups it does, will be faster (BANG!) until the server is overwhelmed by requests and becomes seriously bogged. (HEY - that wasn't a very short answer.)
It kinda goes like this. (Extremely simplified version. Please do not attmept to create your own international communications network based upon this model)
You type in the (valid) URL...
Your computer asks for name resolution from your local resolver which should point it to the DNS server you are using. Now we're waiting on the name server response.
Then if it finds the authoritative name server for that URL it makes an http_request from the server for that address. Now we wait for the http server to give us some stuff.
Then it 'gets' the data from the web server. In this case it's wherever
www.redhat.com/index.html or whatever start page they default to.
Then it waits on doubleclick.net to load the banner ads.
All this is ignoring the likely possibility of forwarding firewalls and load-balanced servers.
Try this: go to a web site that you have not been to in at least a week and see how fast it resoolves (Looking up...). Then reload the page. BANG. Close your browser. and reopen it. Go to that same page. BANG.