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.
