Previous Table of Contents Next I Can't See You! I've been at a site that was having intermittent problems with DNS lookups. Sometimes the DNS lookup was fine; other times, no good-users at Windows workstations would complain that they got an error stating that there's no DNS entry for www.company.com (I'll be using fictional addressing in this example). Assuming that the site's DNS server at 200.1.1.6 was responsible for the ci.monkey.ny.us zone (standing for Monkey City in the state of New York), our immediate tasks were as follows: o Make sure that the Internet at large knew that 200.1.1.6 was authoritative for ci.monkey.ny.us. I didn't suspect a problem here, but on first blush, this is always a good thing to check. o Find out "who" the zone server above us was (ci.ny.us). I suspected that this was where the problem was (any query that your own DNS server can't handle gets kicked to the next zone above it). We dug out nslookup and proceeded to check out the first task: > server a.root-servers.net Default Server: a.root-servers.net Address: 198.41.0.4 > set type=soa > ci.monkey.ny.us Server: a.root-servers.net Address: 198.41.0.4 Authoritative answers can be found from: US nameserver = NS.ISI.EDU US nameserver = RS0.INTERNIC.NET US nameserver = NS.UU.NET US nameserver = ADMII.ARL.MIL US nameserver = VENERA.ISI.EDU US nameserver = EXCALIBUR.USC.EDU NS.ISI.EDU internet address = 128.9.128.127 RS0.INTERNIC.NET internet address = 198.41.0.5 NS.UU.NET internet address = 137.39.1.3 VENERA.ISI.EDU internet address = 128.9.176.32 VENERA.ISI.EDU internet address = 128.9.0.32 EXCALIBUR.USC.EDU internet address = 128.125.51.11 > server ns.isi.edu Default Server: ns.isi.edu Address: 128.9.128.127 > ci.monkey.ny.us Server: ns.isi.edu Address: 128.9.128.127 ci.monkey.ny.us origin = ns.ci.monkey.ny.us mail addr = hostmaster.ci.monkey.ny.us serial = 29981 refresh = 3600 (1 hour) retry = 600 (10 mins) expire = 86400 (1 day) minimum ttl = 3600 (1 hour) ______________________________________________________________ All root servers, in addition to being in the "dot" or "root" zone, are also in the root-servers.net zone. Each server is designated with a letter, so you can go to b.root-servers.net, c.root-server.net, and so on. ______________________________________________________________ Okay, cool. We went directly to a "root" server-that is, a server that has the authority for all the root zones (.com, .us, .gov, and so on)-and asked it what it knew about our little Monkey City. It responded that we needed to go to another server, one that knew all about the .us domain. We then asked that server about the same thing, and it responded appropriately, so we were in good shape. Our next task was to find out what the zone above us was: > monkey.ny.us Server: ns.isi.edu Address: 128.9.128.127 Non-authoritative answer: monkey.ny.us origin = Buggy.net mail addr = [e-mail] serial = 1998080901 refresh = 3600 (1 hour) retry = 1200 (20 mins) expire = 12096000 (140 days) minimum ttl = 14400 (4 hours) Authoritative answers can be found from: monkey.ny.us nameserver = dns2.Buggy.net monkey.ny.us nameserver = dns1.Buggy.net dns2.Buggy.net internet address = 128.6.1.9 dns1.Buggy.net internet address = 128.6.1.10 Okay, apparently the servers that are authoritative for monkey.ny.us are called dns.buggy.net and have IP addresses of 128.6.1.9 and 128.6.1.10, respectively. Because these servers are on the same subnet, we took a look at how far away they were and how long it took to get a packet from here to there. A ping session revealed that, in fact, certain packets were taking anywhere from 800ms (an eighth of a second) to 1,500ms (a second and a half). Whoa! A second and a half is an eternity in networking. Could, perhaps, the slow connection to the zone server next up in the tree pose a problem? It sure could! DNS only waits for so long before it decides that no answer is in the offing and returns an error to the client. So how did we resolve this? There were two answers here. The folks in question needed to upgrade their line to the Internet because their own traffic was killing them (one person's download was cramming the line so full that DNS traffic wasn't responding fast enough). What's more, a traceroute revealed that the ns.ultra-monkey.net server was 16 hops away. Sixteen hops is, well, a lot. Asking their ISP to take responsibility for the monkey.ny.us zone also helped with this problem, because this meant that there was only one hop between the users and their parent zone. Sometimes, someone else's DNS servers are down. This will generally mean that you can't look up DNS names for one domain only. Most sites have multiple DNS servers, so this shouldn't happen, but it does. This probably means that you'll just have to sit tight and wait for the zone in question to have its problem resolved. In a nutshell, here are the things that typically cause you to be unable to look up outside addresses (an inside-to-outside lookup problem): o Too much lag between you and your upstream zone o Upstream DNS servers are unreachable o The DNS server is down or unreachable for a particular zone Previous Table of Contents Next