[sf-lug] resolver problem

[Michael Paoli]

Curiouser and curiouser!  ;-)

Well, I still find it quite puzzling, that, e.g.:
$ ping github.com
works, whereas:
$ curl -I https://github.com
fails with:
curl: (6) Could not resolve host: github.com
That particular combination is rather bizarre.

Nevertheless, computers quite logical things - they do exactly what
they're told (well, notwithstanding some hardware failures and such, but
even in such case, they still follow the logic of their programming and
electronics - whatever it dictates from whatever state it's in and goes
through).

On with divide and conquer.  :-)  There's an answer down there
*somewhere*.

So, I might suggest, to also make it a bit easier for those attempting
to follow along and isolate cause of the issue(s)/problem(s), perhaps
keep a high-level summary table, and also a section on particular
diagnostic commands and their output (or relevant portions thereof).
E.g.:

results              operation/command
------------------------------------------------------------------------
Sever not found      Firefox https://github.com/
Could not resolve    curl -I https://github.com/
workaround for above when adding IP of github.com to /etc/hosts
ok                   Chromium https://github.com/
ok                   ping github.com
same as above        different user, same host
all above ok         when booted from Ubuntu 14.04[.x] DVD

diagnostics/commands/output (or selected portions thereof):

$ lsb_release -d || cat /etc/os-release
...
$ uname -m
...
$ cat /etc/resolv.conf
...
$ fgrep hosts /etc/nsswitch.conf
...
$ ip -4 a s
...
$ ip -6 a s
...
$ ip -4 r s
...
$ ip -6 r s
...
(if ip isn't on one's PATH, one can give full pathname, e.g. /sbin/ip)
It would be good to also show the output of the above commands when
booted from the Ubuntu DVD. (you could save them to another system or
some writable USB storage, etc.).

Might also want to occasionally tag that saved output with timestamps -
that may be particularly valuable if at some point things are found to
have changed in their behavior.  E.g. occasionally use:
$ date -Iseconds
(yes, I know, the -I option is deprecated, but it is so dang handy).

Many have made other good/excellent suggestions and points, ... Rick
Moen, particularly on looking at it from a bit more of network and
network connectivity perspective.

I'll also mention, with modern webservers and virtual name hosting and
SNI, etc., hitting an http or https URL by IP address, rather than
hostname, may not get same results, even if the site is working
perfectly and as expected.  However in both cases, one should at least
still be able to connect to the site (open TCP connection to the IP
address and port - by name or IP address).

I'd also be very interested in seeing
tcpdump capture of UDP and TCP traffic to port 53,
while strace is run on each of these commands:
$ curl -I https://github.com/
$ ping github.com
... each captured and saved separately for those two commands.
strace output can be voluminous,
so too for tcpdump, but limiting the capture to DNS traffic and for the
short duration of running such command, should be relatively little
tcpdump data to capture.
On tcpdump, a few of the options I'd recommend,
on Linux, can do:
-i any
that can be very handy if one isn't sure which interface(s) will be
used.
-s 0
-n
-p
-w tcpdump.cap
The above to save the raw capture - can then examine it with tcpdump
(-r) or wireshark or whatever - use suitably named files for each
separate capture (or rename them after completing capture).
I think you can guess what options I commonly use on strace:
$ cat ~/bin/Strace
#!/bin/sh
exec strace -fv -eall -s2048 ${1+"$@"}
The -o option can also be handy to save to a file.
And yes, I didn't detail all the various options I mentioned,
man(1) is very good at covering those.  :-)

Oh, and of course also, good to keep a log of what you observe, try,
change, etc.

So, yes, I find it odd that ping works, but curl fails with an apparent
resolver error - how might it be that it seems one resolves, but the
other doesn't?  That does seem quite odd.  But there's an answer down
there somewhere.


> From: "Alex Kleider" <akleider at sonic.net>
> Subject: Re: [sf-lug] resolver problem
> Date: Thu, 07 Apr 2016 08:53:04 -0700

> On 2016-04-07 00:26, Michael Paoli wrote:
>> A few more divide & conquer things you could try ...
>>
>> So ... works with one browser, not another, works with ping,
>> but not git?  Efficient divide & conquer typically involves
>> devising series of sufficiently easy/feasible tests, that
>> effectively divide possible causes into two sets of
>> roughly approximate probability, and results of test
>> rule one set in, and the other out - or at least
>> significantly assist in determining probability - after test -
>> between the two sets.  One can also think of whittling it down
>> to the simplest test that can show the "works" vs. "doesn't work" -
>> at which point it's generally obvious what the problem is, or at least
>> exactly where the problem is.
>>
>> So ... "browsers" ... & http & https.
>>
>> What about wget and/or curl?
>>
>> E.g.:
>> $ curl -I https://www.google.com/
>> $ curl -I https://github.com/
>> and/or:
>> $ wget -q -O - https://www.google.com/ | head -c 256; echo
>> $ wget -q -O - https://github.com/ | head -c 256; echo
>>
>
> as per instructions, here are the facts:
> alex at x301:~$ curl -I https://google.com
> HTTP/1.1 301 Moved Permanently
> Location: https://www.google.com/
> Content-Type: text/html; charset=UTF-8
> Date: Thu, 07 Apr 2016 15:31:07 GMT
> Expires: Sat, 07 May 2016 15:31:07 GMT
> Cache-Control: public, max-age=2592000
> Server: gws
> Content-Length: 220
> X-XSS-Protection: 1; mode=block
> X-Frame-Options: SAMEORIGIN
> Alternate-Protocol: 443:quic
> Alt-Svc: quic=":443"; ma=2592000; v="32,31,30,29,28,27,26,25"
>
> alex at x301:~$ curl -I https://github.com
> curl: (6) Could not resolve host: github.com
>
> and
> alex at x301:~$ wget -q -O - https://www.google.com | head -c 256; echo
> <!doctype html><html itemscope=""  
> itemtype="http://schema.org/WebPage" lang="en"><head><meta  
> content="Search the world's information, including webpages, images,  
> videos and more. Google has many special features to help you find  
> exactly what you're looking
> alex at x301:~$ wget -q -O - https://github.com/ | head -c 256; echo
>
> alex at x301:~$
>
> Switching users: symptoms are the same:
> Chromium can resolve urls, Firefox can not, and
> pat at x301:~$ ifconfig
> eth2      Link encap:Ethernet  HWaddr 00:1c:25:9d:e1:f0
>           inet addr:10.0.0.16  Bcast:255.255.255.255  Mask:255.255.255.0
>           inet6 addr: fe80::21c:25ff:fe9d:e1f0/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:397957 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:343874 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:61678643 (61.6 MB)  TX bytes:30890987 (30.8 MB)
>           Interrupt:20 Memory:f0600000-f0620000
>
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:65536  Metric:1
>           RX packets:263600 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:263600 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:27988121 (27.9 MB)  TX bytes:27988121 (27.9 MB)
>
> tun0      Link encap:UNSPEC  HWaddr  
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>           inet addr:172.31.2.14  P-t-P:172.31.2.13  Mask:255.255.255.255
>           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>           RX packets:149 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:49 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           RX bytes:17045 (17.0 KB)  TX bytes:6174 (6.1 KB)
>
> pat at x301:~$ ping github.com
> PING github.com (192.30.252.120) 56(84) bytes of data.
> 64 bytes from github.com (192.30.252.120): icmp_seq=1 ttl=52 time=88.4 ms
> 64 bytes from github.com (192.30.252.120): icmp_seq=2 ttl=52 time=87.2 ms
> 64 bytes from github.com (192.30.252.120): icmp_seq=3 ttl=52 time=88.4 ms
> ^C
> --- github.com ping statistics ---
> 4 packets transmitted, 3 received, 25% packet loss, time 2999ms
> rtt min/avg/max/mdev = 87.244/88.044/88.452/0.565 ms
> pat at x301:~$ git clone https://github.com/alexKleider/debk.git
> Cloning into 'debk'...
> fatal: unable to access 'https://github.com/alexKleider/debk.git/':  
> Could not resolve host: github.com
> pat at x301:~$
>
>
> Does this get us any closer to the root problem?
> Alex