I understand that Internet routing tables can handle
up to 65,536 IP addresses. But Domain Name Servers
can handle unlimited domain name listings. Is this
true, and if so, why?
Yes, it’s true. But you’re comparing apples and oranges.
The purpose of a routing table is for a router to know to which interface to forward a particular packet. It has nothing to do with DNS. The more routes a router knows, presumably, the more efficient its routing decisions will be, but the longer they might take. Since each router must have its own routing table, and since speed is imporatnt when forwarding packets, the space allocated for routing tables is not gigantic.
The purpose of a Domain Name Server is to provide translation between fully qualified host names, such as http://www.goresucks.com, and the IP address of the server that runs the Gore Sucks website. The Domain Name Service can have an effectively unlimited number of listings, because they are distributed among many different hosts.
- Rick
OK, so does each computer operating as a Domain Name
Server have a limit to the number of listings it can
hold? And are the listings in the DNS in RAM? The DNS
seems to go much faster than routers, for example when
I enter a non-existing domain name, the result pops up
very fast. But to reach an existing site, it can take
a few good seconds.
What?
I’m not sure I understand what you are saying/asking, but I’ll give it a shot.
First of all, I don’t know for a fact if an individual DNS server has a limit, but I don’t guess so. It’s not that important to ‘faster vs. slower’. Also, whether the listings are in RAM is likely to be implementation dependent - I’d say probably they are in RAM, but again it depends on the implementation. I see where you are going with this, the DNS in RAM would be faster than the routing table on etch-a-sketch. But this faster vs. slower thing is confusing me - it is like comparing apples and oranges.
The part I have trouble understanding is “The DNS seems to go much faster than routers…” Every time you try to access a site on the web, you use DNS to find out what the address of the server is, and all the routers required to get the request from your machine to the server and the response from the server back to your machine. So how can you tell which is faster? If DNS is slow, then yes it might take forever for it to tell you “www.asdfasdfasdf.com not found”, and then you’d know. But, if the site exists you must go through N routers to get the data, so even if the routers are very fast you still have some work to do to get the page and it has to take longer than the DNS failure.
Also, Rick explained how they are two entirely different things. It’s like asking if it is faster to look on a map to see how to drive to Chicago or to actually drive to Chicago - it depends on a whole lot of factors, but generally looking at the map is faster. But then, who cares if you really want to get to Chicago? Likewise, if all you wanted to do was look at IP addresses all day it’d be very fast. But finding that http://www.theonion.com translates to 878.999.3221.834 [sic] is much less interesting than reading about the annual Raccoon Federation meeting.
Curwin inquires:
As may be… but you’re comparing apples and oranges again. If you’re resolving a valid domain address and it’s slow to come up, that’s NOT telling you anything about how long the domain name took to resolve – it’s telling you that the domain resolution and the remote host’s response to your request took a long time. Granted, Netscape and IE tell you that remote site X has been contacted, which generally means that the domain name successfully resolved – but is that what you’re going by?
Also, consider that your ISP is running its own DNS servers. Response to your domain resolution requests is likely to be snappy. But when you’re going to to different networks with your requests, then you’re going to be experiencing all sorts of different routes to your eventual host, with whatever problems or outages lie between you and them.
DNS response time just isn’t something you can look at and extrapolate anything else from.
Also,. a DNS request can require several trips back and forth to various hosts. I run a small DNS server at home (my ISP’s DNS goes down once in a while, and I have the license for the software for historical reasons, so what the hell).
When a DNS server starts, it has almost no information. It knows the IP addresses of a few “root servers”. Currently there are 13 primary root servers (domain names a.root-servers.net through m.root-servers.net; look them up if you care. a.root-servers.net is at 198.41.0.4).
(Of course, the DNS server only cares about the IP address, but it knows the domain name so people can “read” the cache more easily).
Every record in a DNS server’s cache has a Time To Live (TTL). The TTL tells the DNS server how long it can hold the record in its cache without having to re-check it. The root server addresses haven’t changed in years, and my DNS server lists them with a TTL of 3,600,000 seconds.
When a newly-started DNS server gets a request for, say, http://www.altavista.com, it asks one of the root servers for the address of a server for the .com Top Level Domain (TLD). (If that server is down or not responding fast enough, it asks another) My server currently has 12 servers listed for .com, including a, e, f, and g.root-servers.net, each with a TTL of 382,214 seconds.
The DNS server then asks one of those servers for altavista.com. It gets back one or more IP addresses. My server lists three for altavista.com; ns1.altavista.com, ns2.altavista.com, and ns3.altavista.com, each with a TTL of 130,365 seconds.
For more complex domain names, this process may have to go on for several more levels. For http://www.altavista.com, we’re done.
Finally, the DNS server returns one of those addresses to the requesting program. The requesting program sends anything for http://www.altavista.com to the address that the DNS server returned, and the computer at that address may route the requests in various ways over their internal network to the appropriate computer.
Most DNS servers can be set to ask another DNS server before going to the root servers. If that is the case, and the other DNS server happens to have altavista.com in its cache, then the process is simpler.
OK, let me get this straight –
Apples are the red ones, and oranges are the uh…?
Seriously…
I can tell using tracert. If I do tracert on yahoo.com, it starts doing the trace on the routers right away, which seems to indicate that the DNS knew the domain’s IP address very quickly. If the info was on the DNS of my ISP, then I can understand the speed, but if I am looking for a non-existent domain, then doesn’t the DNS send requests to a number of additional DNSs? Shouldn’t that take more time?
OK, so maybe this is what I’m not understanding. I thought that both DNS and Routing tables were parallel to the map in your example, not the drive. In your example, if I wanted to get from Chicago to Milwaukee, I’d first have to find what highway to take (the DNS) and then make the actual directions (the routing table). Am I misunderstanding the role of the routing table?
My basic question still stands (I think): if the routing tables are limited in size, why aren’t the dns’s?
If the domain is non-existent, then I don’t think it actually needs to ask anyone but the root servers JonF described in his post - very fast indeed. For a site that does exist, you should get DNS very quickly, especially if it is a site that is commonly looked up and will therefore be in the cache of just about any DNS server (e.g. Yahoo).
Even in the case where multiple DNS servers need to be queried, unless you come up with a domain name that is rarely visited the cache of some DNS server will contain it and save you a fair amount of time. If you do find a domain name that few use, you would then have to get the information from the DNS server for that domain itself, and that might take more noticeable amounts of time.
I’d describe the analogy more like this: First, you want to go to Milwaukee, so you open your window and shout “Where is Milwaukee?” Your neighbor, if he knows, will tell you the coordinates of Milwaukee in Latitude/Longitude (DNS.) Then, you get in your car and start driving. When you get out of your driveway, ask someone “How do I get to Latitude X Longitude Y?” Instead of getting a complete set of directions, they will tell you “Get on the freeway.” So, get on the freeway and ask a passing motorist “How do I get to Lat X Long Y?” They’ll tell you what direction to travel and how far. When you go that far, ask again and they will tell you what exit to take. Each time you ask a question and get a response on the way to Milwaukee is a routing table interaction.
The key point is that each interaction with the routing tables doesn’t take that much time, and in fact since a DNS request goes through the net in the same way as other packets, it has the same problems - the difference is you don’t have to go all the way to Milwaukee to find out where Milwaukee is if your neighbor knows where it is.
A routing table always is a local decision - note you can’t ask your neighbor what exit to take in Milwaukee, nor can you ask him how far it is - you must get on the freeway and get to the router (junction, whatever) and ask the router how to get where you are going. Actually, you tell the router where you want to go and he throws you in the direction of the next router that can help you, but hopefully you get the point.
That’s just the way it is. That’s like asking “If I can do a spreadsheet in Excel, why not in Netscape?” The two things provide very different services and are built in different ways.
One more thing that may help elucidate: A routing table (or a router with a routing table) is a part of the internet infrastructure, like stoplight or freeway junction. DNS is a higher level protocol by which certain types of information is transmitted over the internet. In the Milwaukee example, if your neighbor didn’t know where Milwaukee is, he might send his kid to the library in your hometown to look it up. The kid has to go through stoplights (routers) to get to the library (DNS server) to look up the location of your destination. He then returns with the information so your neighbor can shout the answer to you. The DNS information had to travel through routers to get to a server that could respond and return the info to you. The only reason it is faster than talking directly to the name server in Chicago is that it didn’t have to go to Chicago.
Maybe I better stop with the metaphor madness. Is it helping at all?
You probably are set to use your ISP’s DNS server, and your ISP’s DNS server probably has such a popular destination in its cache, so your request never leaves your ISP’s local network. Try a traceroute on http://www.herald.asdc.kz/ (but don’t click on it first; that’ll do a DNS and then it’ll be in your ISP’s DNS server for a while).
curwin, I suspect the problem is a misunderstanding about packet flow across the Internet. Here is a basic explanation of how DNS and IP work when you talk to www.xyz.com. I hope this helps. I’ll start from the beginning; ignore the bits you already know:
www.xyz.com is a Domain Name, which is really a name for human usage, but not very useful for routing. Every addressable host has a unique IP address. Think of a domain name like a human name and an IP address like a phone number. Only IP addresses can be routed through the Internet. Think of it like the human/phone analogy: You can’t dial someones name on your telephone. You have to look up the phone number in a phone book or call information and get the number. Only at that point can you dial the phone number.
First, getting an IP address from a domain name: That is the purpose of DNS. Just like the human/phone analogy above, you can look the number up in your local machine (like looking in the phone book), or contact a DNS Server and ask it to give you the IP address for a domain name. Also like the analogy, you need to know the IP address of the DNS server first, just like you need to know the number for information (411 or 555-1212) before you can get your desired IP address. Your workstation is configured with the IP address of a DNS server. Your workstation sends packets to this DNS server asking it for the IP address of the desired domain name (xyz.com). A Domain Server maintains a table of domain names and their associated IP addresses. As you indicate a typical list is huge. The actual flow of DNS packets to and from the DNS server is the same as the flow of your HTTP packets to the final web server, www.xyz.com.
The Flow of Packets: the Internet is connected together by a bunch of boxes called Routers. Routers have one or more Interfaces. Each interface is a physical connection to either another Router (typically physically distant, in a different city) or a destination Host or LAN. So, between you and www.xyz.com, there are a series of routers. You send a packet to a router, which must forward it to the appropriate next router (known as the next Hop), then to the next, till it finally gets to it’s destination. Each router decides which router to forward a packet on to based on the packets destination IP address and the routers internal knowledge of what packets go where. This information is known as it’s Routing Table.
Routers communicate with each other and notify each other about the routes that they can deliver to. This communication is known as a Routing Protocol. Routers can also be configured by hand to over-ride information gotten from routing protocols. This is known as Static Configuration. Routers are also configured with a Default Route, which is a router to which they send packets with destinations not in the local routing tables.
I just found a great movie that really describes how the internet works, including routers (although it doesn’t directly mention DNS servers). You can find it at:
curwin, I hope your original question got answered.