DNS issue when cloning over HTTP and HTTPS

    The following snippet illustrates the problem:

$ uname -srvm Linux 3.9.5-smp #2 SMP Mon Jun 10 02:54:26 CDT 2013 i686

$ git --version git version 1.8.3

$ git clone https://github.com/torvalds/linux.git Cloning into 'linux'... fatal: unable to access 'https://github.com/torvalds/linux.git/': Could not resolve host: github.com (Could not contact DNS servers)

    Of course, DNS is working fine, and GitHub is accessible from my
machine:

$ dig github.com

; <<>> DiG 9.9.2-P2 <<>> github.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20305 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;github.com.INA

;; ANSWER SECTION: github.com.212INA204.232.175.90

;; AUTHORITY SECTION: github.com.79055INNSns1.p16.dynect.net. github.com.79055INNSns2.p16.dynect.net. github.com.79055INNSns3.p16.dynect.net. github.com.79055INNSns4.p16.dynect.net.

;; Query time: 0 msec ;; SERVER: 192.168.7.2#53(192.168.7.2) ;; WHEN: Tue Jun 18 00:46:13 2013 ;; MSG SIZE rcvd: 141

$ ping -c 3 github.com PING github.com (204.232.175.90) 56(84) bytes of data. 64 bytes from github.com (204.232.175.90): icmp_req=1 ttl=52 time=142 ms 64 bytes from github.com (204.232.175.90): icmp_req=2 ttl=52 time=140 ms 64 bytes from github.com (204.232.175.90): icmp_req=3 ttl=52 time=154 ms

--- github.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 140.184/145.555/154.217/6.183 ms

$ nc -v github.com https github.com [204.232.175.90] 443 (https) open ^C

    A packet capture shows what's going on:  Git tries to resolve
github.com over LLMNR rather than DNS, and my router responds with
"destination unreachable".  192.168.7.2 is my machine, and 192.168.7.1
is my router:

No.     Time        Source                Destination           Length Expert Protocol Info
      1 0.000000    192.168.7.2           192.168.7.1           70            LLMNR    Standard query 0xbfe4  A github.com

Frame 1: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: IntelCor_94:18:a4 (00:1c:c0:94:18:a4), Dst: 22:4e:7f:5b:02:55 (22:4e:7f:5b:02:55)
Internet Protocol Version 4, Src: 192.168.7.2 (192.168.7.2), Dst: 192.168.7.1 (192.168.7.1)
User Datagram Protocol, Src Port: 55585 (55585), Dst Port: 13568 (13568)
    Source port: 55585 (55585)
    Destination port: 13568 (13568)
    Length: 36
    Checksum: 0x8f89 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Link-local Multicast Name Resolution (query)
    Transaction ID: 0xbfe4
    Flags: 0x0100 Standard query
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        github.com: type A, class IN
            Name: github.com
            Type: A (Host address)
            Class: IN (0x0001)

No.     Time        Source                Destination           Length Expert Protocol Info
      2 0.000254    192.168.7.1           192.168.7.2           98            ICMP     Destination unreachable (Port unreachable)

Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: 22:4e:7f:5b:02:55 (22:4e:7f:5b:02:55), Dst: IntelCor_94:18:a4 (00:1c:c0:94:18:a4)
Internet Protocol Version 4, Src: 192.168.7.1 (192.168.7.1), Dst: 192.168.7.2 (192.168.7.2)
Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 3 (Port unreachable)
    Checksum: 0x8c86 [correct]
    Internet Protocol Version 4, Src: 192.168.7.2 (192.168.7.2), Dst: 192.168.7.1 (192.168.7.1)
    User Datagram Protocol, Src Port: 55585 (55585), Dst Port: 13568 (13568)
        Source port: 55585 (55585)
        Destination port: 13568 (13568)
        Length: 36
        Checksum: 0x9684 [validation disabled]
            [Good Checksum: False]
            [Bad Checksum: False]
    Link-local Multicast Name Resolution (query)
        Transaction ID: 0xbfe4
        Flags: 0x0100 Standard query
        Questions: 1
        Answer RRs: 0
        Authority RRs: 0
        Additional RRs: 0
        Queries
            github.com: type A, class IN
                Name: github.com
                Type: A (Host address)
                Class: IN (0x0001)

    Cloning with the git protocol works as expected.

    A search on the net shows people having the same problem more than
an year ago, and the solution there seems to imply that Git can't cope
with async DNS in curl:

http://osdir.com/ml/freebsd-ports-bugs/2012-05/msg00095.html

    Any idea?

    /lcd

PS: Please CC me on replies, as I'm not subscribed to this list.

On Tue, 18 Jun 2013, LCD 47 wrote:

It's not a git problem really. When you build libcurl to use c-ares for asynch name resolving you unfortunately don't get a really feature complete replacement for all stuff the stock synch resolver can do and I believe you (and person from that link from last year) experience that.

The solution for you is to:

a) rebuild libcurl with another resolving backend (there's a synch and threaded asynch one to choose from)

  or

b) fix c-ares to work "properly" in this scenario as well

On 18 June 2013, Daniel Stenberg <daniel@haxx.se> wrote:

    Thank you for the quick and very helpful response.  I rebuilt curl
with the threaded resolver, then I rebuilt Git, and now cloning over
HTTP works fine.  I'll send a bug report to the maintainers of curl and
Git for my Linux distribution then.

    /lcd