It's an interesting thought, but you're missing the main point. LIBCURL was told to connect to boinc2.ssl.berkeley.edu, and it says it tried to connect to a host at XEROX Corporation.
I can't think of a single way for that to happen, short of a bug. Since web browsers, mail clients, telnet, SSH, and a whole bunch of other things use the resolver in the OS, and they don't go rushing off to XEROX (or MIT if the .18 address gets reversed), that suggests something in BOINC, and BOINC leaves this to LIBCURL. There is more, but I don't want to take away from the main point: there is no way a query for boinc2.ssl.berkeley.edu should return an address in 13.0.0.0/8. This is a cause jump: I don't know that it is actually a bug, and I don't know that it is in the cache part of LIBCURL. I do know from reading the SETI forums that sometimes things happen that don't match what I've seen in 15 years of managing and using DNS. Things like clients not following when s...@home makes DNS changes. ... and I don't think the DNS cache in LIBCURL helps BOINC at all. -- Lynn Al Reust wrote: > I am going to pick out one element of this... It stands out IF the DNS > administrator has set reverse lookups, then if the user does something > silly on the windows side like ipconfig /displaydns they would get the > appropriate record for > > 13.240.68.208.in-addr.arpa > > Which would point to the correct A record. This in Seti's case is > complicated by a round robin DNS that depends on TTL. To add to the further > the SOA DNS servers that host the primary domain records would need to be > in sync with the secondary DNS (round robin). So while we do not know what > is allowed for replication (Zone transfers) or if there is a properly > configured "forwarder" for DNS from the Primary to the Secondaries. To my > knowledge the Primary DNS servers are Berkeley's and their are BIND > (version unknown), Last but not least the DNS Administrator could have > chose to not reveal reverse lookups > While I have heard references to an Internal DNS (Bind) and then the Round > Robin DNS (Bind clone?) it is very hard to say what is real or what is Not > Memorx. It is very tough to pin the bug to libcurl. > > Or the correct question might be did lbcurl cache it or did the OS cache it > and which did not honor TTL. Without tools to properly query/record either > TCP Stack/Cache it becomes moot. > > I can say that my Vista 64 and Win7 64 RC boxes, when I do an ipconfig > /displaydns and see the 5 minute TTL and then later after it has expired I > do the same. The A record for boinc2.ssl.berkeley.edu is not displayed. It > "appears" that the TTL is being honored on the local machine. Despite that, > I do have the symptoms that are being described (libcurl). > > > At 08:16 PM 7/18/2009 -0700, Lynn W. Taylor wrote: >> Richard Haselgrove spotted something interesting a while back, and since >> I've been reading code and documentation trying to come up to speed, >> it's pretty interesting. >> >> What he saw is here: >> >> <http://boinc.berkeley.edu/dev/forum_thread.php?id=3225> >> >> At the time, boinc2.ssl.berkeley.edu resolved to 208.68.240.13 (and .18, >> but that's not important right now). >> >> BOINC tried to connect to 13.240.68.208 -- the octets are reversed. >> >> As part of my reading I see lots of places that say that CURL has >> trouble with their DNS caching -- none of them very detailed, just >> grousing back and forth between users who say "your tool is broken" and >> developers who say "it's a bug in LIBCURL." >> ~ snip >> -- Lynn >> >> _______________________________________________ > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
