CURL Unable to resolve DNS internally



  • An odd problem indeed.

    Now, I haven't yet tried rebooting, but seriously, if *nix (or FreeBSD) is so stable, I should be able to fix errors without the Win9x-esque reboot. My primary WinXP box has been 16 days without a reboot, which my pfSense virtual box hasn't yet been able to exceed (it crashed a few days ago, but the WinXP host it was running on ran strong). So, let's see if I can fix this without rebooting. :P
    (end Windows-loving minirant, hehe)

    The problem started when I found that my No-IP address wasn't updated properly, and I had a moment of embarrassment while trying to access my desktop from another location. I came home and later tried figuring out why it wasn't updated. Sure enough, my No-IP alias wasn't updated properly. I dug through the log and found it saying my IP (which was correct) was already up to date. So to force an update, I just re-saved DDNS settings and watched the log.

    Everything looks OK until:
    "php: /services_dyndns.php: Curl errror occured: Couldn't resolve host 'dynupdate.no-ip.com'"
    (note the typo in "Curl errror", just pointing that out)

    It acts like it was successfully updated, which is kinda strange. It updates the cache and acts like everything is normal except for the fact that it didn't update anything. So I backtrace some code and whip up a test script for the "run a command" diagnostic page:

    $ch = curl_init();
    curl_setopt($ch,CURLOPT_HEADER,false);
    curl_setopt($ch,CURLOPT_RETURNTRANSFER,true);
    curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,false);
    curl_setopt($ch,CURLOPT_URL,"http://google.com/");
    $data = curl_exec($ch);
    if (@curl_error($ch)) echo 'Error: '.curl_error($ch);
    echo $data;
    curl_close($ch);
    ?>
    

    Sure enough, after a long pause (about 30-45 seconds), it spits out "Error: Couldn't resolve host 'google.com'". Yeah, well, I call bull.

    From the shell:

    # ping google.com
    PING google.com (64.233.167.99): 56 data bytes
    64 bytes from 64.233.167.99: icmp_seq=0 ttl=240 time=39.563 ms
    64 bytes from 64.233.167.99: icmp_seq=1 ttl=240 time=70.315 ms
    ^C
    --- google.com ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 39.563/54.939/70.315/15.376 ms
    #
    

    So obviously that's working. It can look it up internally, but why can't cURL?

    Now, I am using OpenDNS overriding my ISP DNS on the "general settings" page, and I have DNS forwarding disabled (so clients handle DNS directly, as I'm trying to figure out why LAN->WLAN SMB networking isn't working right; WLAN isn't even connected to the pfSense box, the AP is connected straight to the LAN switch). That may be a problem, but I don't understand why it's only cURL that can't access DNS.

    So, uh… thoughts? Oh, and if nothing else, at least this topic is searchable now... there doesn't even seem to be a single cURL-related problem on this forum! =)



  • Excuse my bump… but a full week (to the hour) without even a follow-up reply is kinda sad.

    Rebooting and even reconfiguring the DNS settings (several times) doesn't help. I've also noticed that my Squid proxy was misconfigured due to some misleading statements in the WebUI about the proxy's network being "automatically added to the allow list" - I couldn't get it to actually filter things on my network (through transparent mode) until I added 192.168.1.0/24 to the access list (something that claimed to be automatic). Later, when Squid crashed (euh?), I was unable to restart it using the service status page (it did absolutely nothing), but re-saved the "proxy options" page in order to restart it. Seems like a kinda clunky, buggy system for something that's "stable" IMO... =(

    [/jabbing]

    Anyway, any help on this one? I had to install No-IP's actual client on the Windows side of my pfSense box - thank goodness I'm now using pfSense in VMware! ;)



  • And another week.


Log in to reply