A DNS Example
Let's say that you type the URL www.howstuffworks.com into your browser. The browser contacts a DNS server to get the IP address. A DNS server starts its search for an IP address by contacting one of the DNS root servers. The root servers know the IP addresses for all of the DNS servers that handle the top-level domains (.COM, .NET, .ORG, etc.). Your DNS server asks the root for www.howstuffworks.com, and the root would say, "I don't know the IP address for www.howstuffworks.com, but here's the IP address for the .COM DNS server."
Your name server then sends a query to the .COM DNS server asking it if it knows the IP address for www.howstuffworks.com. The DNS server for the .COM domain knows the IP addresses for the name servers handling the www.howstuffworks.com domain, so it returns those.
Your name server then contacts the DNS server for www.howstuffworks.com and asks if it knows the IP address for www.howstuffworks.com. It actually does, so it returns the IP address to your DNS server, which returns it to the browser, which then contacts the server for www.howstuffworks.com to get a web page.
One of the keys to making this work is redundancy. There are multiple DNS servers at every level, so that if one fails, there are others to handle the requests. The other key is caching. Once a DNS server resolves a request, it caches the IP address it receives. Once it has made a request to a root DNS server for any .COM domain, it knows the IP address for a DNS server handling the .COM domain, so it doesn't have to ask the root DNS servers again for that information. DNS servers can do this for every request, and this caching helps to keep things from bogging down.
Even though they're totally invisible, DNS servers handle billions of requests every day, and they are essential to the internet's smooth functioning. The fact that this distributed database works so well and so invisibly day in and day out is a testimony to the design.