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:

   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?

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

-- 

  / daniel.haxx.se

On 18 June 2013, Daniel Stenberg [off-list ref] wrote:

On Tue, 18 Jun 2013, LCD 47 wrote:

quoted

  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?

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

    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