kinley@BOND.CRIM.CA (J. Darren Kinley) (11/15/90)
On Oct 25, J. Darren Kinley writes: > ... > > > One of our nameservers (RA.DEPT.CS.YALE.EDU) has picked up a Canadian root > > server (CLOUSO.CRIM.CA - is it valid?): > > ACK!!!! > No, this is *definitely* not valid! ... > > I will investigate and see if I can figure this out. Any hints, > suggestions, or information that could prove usefull will be > *greatly* appreciated. I will have follow this thread backwards > and catch up on what I have missed. > -- End of excerpt from J. Darren Kinley. Hello again, First of all thanks to the people who took the time to reply to my request for hints. Most of the replies simply stated that they had seen the bogus records and/or wished me looks of luck in discovering the source of the bogons. These were interesting and appreciated, but did not quite give the information I was hoping for. I will wrap up this follow-up with a few questions that I don't have acceptable answers to. Problem: Find and eliminate the source of the clouso.crim.ca. bogus root name server records. This turns out to be about as difficult as finding the proverbial needle in the hay stack. Assumptions: I knew the person that was giving out the bad information. This assumption restricted my search all name servers on the RISQnet and a few others in the west of Canada. How I proceeded: 1. Made a list of all name server that I knew and proceeded to ask each who the root name servers were. Bingo! I lucked out. The TTLs, however, were only a few seconds and the bad RRs disappeared immediately. (Hmm, could they be the source of my problems?) 2. Ran a script that monitored those servers on a 2 minute interval over 3 days. I had hoped that this might help to point me in the right direction. The assumption being; from a name server that is infected more often than mine, I can find the source of the problem more quickly. Not even a single hit! 3. Reconsidered assumptions and plan of attack. - I still put I high probability that the person responsible was someone that I knew, and so decided to stick with my primary assumption. - I considered running my NS in debug mode and reading the megabytes of trace, but the bad information had never shown up here. Besides, I didn't really want to go through a trace. - I considered that the problem would go away *if* the guilty person saw this thread, but decided that they probably didn't read this list and that I could not ignore the problem. 4. Some name servers were more suspect than others and so I concentrated my efforts on them. I connected to each and asked simple questions like; ". ns", "ca. ns", "edu. ns.". Finally, I found a machine that thought that we were a name server for just about everything except ".". When asked, however, "foo. ns" it replied that "clouso.crim.ca." was a root name server. Aha! I then visited the domain admin, explained how the name server should work and how to correctly configure it, played with his name server and found out that it was rather broken (or at least I was unable to understand why it worked that way that it did). Anyhow, I was able to get the thing to work. Hopefully, this was the only source of the problem! Has anyone any experience getting a name server to run on an IBM running VM? If so I would like to hear from you. 5. Am I finished? I received a mail from someone on another Canadian regional network. Apparently, before having a connected status on the core, some admins on this particular network found that naming clouso.crim.ca. as a "." name server solved their immediate problems. Perhaps some name servers are still configured in this way. As it turns out, my primary assumption must now be discarded (sigh) and I have possibly/probably not seen the end of the problems. Questions: Does anyone still have the bogus root name server records that name clouso.crim.ca.? HOW DOES THIS BAD INFORMATION GET PROPOGATED? If organization X has a name server which serves *only* the domain associated with X, no one outside of X should be asking the X name server anything other than the domain associated with X. So the bad information cannot possible be propogated outside of the X organization! More generally, I cannot see any scenario where bad root name server information can possibly be propogated by anyone other than root. The exception of course, is that humans force this bad information to be propogated while playing with nslookup or dig. If anyone can enlighten me it would be *greatly* appreciated. Concerning debugging, I have often heard (read) people mention reading traces. Reading a trace is the last thing that I want to do! Perhaps it is time to discuss alternative methods or procodures we (domain admins) can try in order to help isolate problems. I have listed the steps in my approach to the problem. Can someone suggest a better approach? -- Darren Kinley | Centre de recherche informatique de Montreal (CRIM) Analyste/Prog. en Telecom | 3744 rue Jean-Brillant, bureau 500 kinley@crim.ca | Montreal (Quebec) Canada H3T 1P1 uunet!clouso!kinley | tel: +1 514 340 5700 / fax: +1 514 340 5777
del@thrush.mlb.semi.harris.com (Don Lewis) (11/15/90)
In article <9011142027.AA00555@bond.crim.ca> kinley@BOND.CRIM.CA (J. Darren Kinley) writes: >HOW DOES THIS BAD INFORMATION GET PROPOGATED? If organization X >has a name server which serves *only* the domain associated with >X, no one outside of X should be asking the X name server anything >other than the domain associated with X. So the bad information >cannot possible be propogated outside of the X organization! More >generally, I cannot see any scenario where bad root name server >information can possibly be propogated by anyone other than root. >The exception of course, is that humans force this bad information >to be propogated while playing with nslookup or dig. If anyone >can enlighten me it would be *greatly* appreciated. Generally what happens is that the name server for X is somehow broken and is not acting as a name server for X (usually it is supposed to be a secondary server and is listed as a server for X with the root servers, but it is not configured to be a server for X). Its response to queries about X basically tells the client that it doesn't know anything about X and that the client should go ask the root servers. Just to be helpful, it sends along the (possibly bogus) list of the root server names and addresses that it has in its cache. If the client happens to be BIND, it happily caches this root server information. If the client is broken in a similar way or is acting as a forwarder for another server that is broken in a similar way, this bogus information can continue to propagate. There are a lot of servers in this category in the in-addr.arpa domain. I have also observed some versions of Sun's BIND responding with the root server list in the authority/additional sections even when they have an authoritative answer to the query. > >Concerning debugging, I have often heard (read) people mention >reading traces. Reading a trace is the last thing that I want to do! >Perhaps it is time to discuss alternative methods or procodures >we (domain admins) can try in order to help isolate problems. >I have listed the steps in my approach to the problem. Can someone >suggest a better approach? If you are running BIND, there are patches floating about that will log all delegations to the root servers and the associated questions and IP address of the culprit. I try to scan the logs periodically and harass the responsible parties. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
dfk@NIC.EU.net (Daniel Karrenberg) (11/16/90)
del@thrush.mlb.semi.harris.com (Don Lewis) writes: >If you are running BIND, there are patches floating about that >will log all delegations to the root servers and the associated >questions and IP address of the culprit. I try to scan the logs >periodically and harass the responsible parties. How do i make those pathces "float" my way? -- Daniel Karrenberg Future Net: <dfk@cwi.nl> CWI, Amsterdam Oldie Net: mcsun!dfk The Netherlands Because It's There Net: DFK@MCVAX
he@spurv.runit.sintef.no (Havard Eidnes) (11/17/90)
In article <9011142027.AA00555@bond.crim.ca>, kinley@BOND.CRIM.CA (J. Darren Kinley) writes: |> |> 5. Am I finished? |> |> I received a mail from someone on another Canadian regional |> network. Apparently, before having a connected status on the |> core, some admins on this particular network found that naming |> clouso.crim.ca. as a "." name server solved their immediate |> problems. |> |> Perhaps some name servers are still configured in this way. |> As it turns out, my primary assumption must now be discarded |> (sigh) and I have possibly/probably not seen the end of the |> problems. I think there is a less offensive workaround in such a situation, namely to set up their name server as an unregistered secondary name server for e.g. the "ca" top-level domain. The assumption is that they do not have IP connectivity to anywhere outside Canada, so the fact that looking up names on the "outside" is impossible is probably less of an issue. Sure, BIND will yell after a while that it's unable to contact the root name servers. I don't know (or remember) whether it will still work, though -- it's too long since I was in this situation myself, and BIND has changed quite a bit since then. If BIND stops working in the absence of connectivity to a root name server, IMHO I'd say BIND deserves fixing. - Havard