On 2018-10-14 01:52, Rick Moen wrote:
> Quoting golinux@??? (golinux@???):
>
>> Well, I picked a few names at random. netflix pops up as soon as I
>> hit enter. Ditto Microsoft, outlook, Apple, twitter, instagram,
>> reddit, snapchat and facebook. Redhat is in a slower lane as is the
>> Linux Foundation. Even Ubuntu takes a while. But I don't get out
>> much so maybe some of you know some popular destinations that I
>> missed.
>

Thanks for taking the time to do this. When I digest it, just maybe my
issue will be solved.

> I assume you mean using a Web browser. I would suggest starting your
> checks using 'dig'.
>

Yes.

> But first, a brief interlude about _where_ your nameservice is coming
> from:
>
> If you look in /etc/resolv.conf, you'll see one or more 'nameserver'
> lines. Mine on my server is like this:
>
> $ cat /etc/resolv.conf
> search linuxmafia.com deirdre.org unixmercenary.net
> nameserver 127.0.0.1
> nameserver 198.144.192.2
> nameserver 198.144.192.4
> #nameserver 198.144.195.186
> $
>
> (If you are getting your IP address using DHCP, you are extremely
> likely
> to be getting passed nameserver IP addresses with your IP address
> lease,
> resulting in the DHCP client software overwriting /etc/resolv.conf
> with,
> among other things, 'nameserver nnn.nnn.nnn.nnn' information.
>

wicd finds a connection automatically. I think it uses DHCP. All these
years I have managed to avoid the fine points of networking because it's
always "just worked".
> Anyway, /etc/resolv.conf is one of the primary configuration files of a
> Linux system's DNS client software, part of glibc. The 'resolver
> library' in glibc uses as its sources of DNS resolution information the
> IP addresses in those 'nameserver nnn.nnn.nnn.nnn' lines. The resolver
> tries each one in turn, starting with the top line and moving down,
> until it finds the first one that answers DNS questions.
>
> Anyhow, it can be vital to know _what_ server is answering (well or
> otherwise) your system's DNS questions by default. Looking at
> /etc/resolv.cofn should answer that question.
>


I don't have anything in /etc/resolvconf except an avahi-daemon in
/update-libc.d/ Maybe I should start by putting 8.8.8.8 in
/etc/resolvconf?

And OT do I even need avahi installed at all?

That's as much as I can digest atm - the rest of this looks
"challenging". I really need some sleep. To be continued . . .

> In the case of _my_ /etc/resolv.conf, notice that the first address is
> the localhost IP addres, 127.0.0.1, which means 'resolve DNS questions
> locally'. This is because my server runs its own recursive nameserver
> daemon. Your first 'nameserver nnn.nnn.nnn.nnn' line will surely not
> be
> that, and will probably be an ISP-operated recursive nameserver
> reachable on the far end of your house's uplink. Following me so far?
>
> Now, we'll turn to basic use of 'dig'. The optional '@' parameter is
> where you can put which nameserver (specified by either fully qualified
> domain name = FQDN or IP address) this query should be sent to. In the
> example below, we will direct a query to out of the Google Public DNS
> recursive nameservers that Google offers for public benefit.
>
> $ dig ns1.linuxmafia.com @8.8.8.8
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55874
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>

> ;; ANSWER SECTION:
> ns1.linuxmafia.com.     21599   IN      A       198.144.195.186
> $

>
> 'dig' is using the default UDP-type datagram transport, and it got
> answer '198.144.195.186'.
>
> You can test exactly how long the question and answer cycle took by
> using the 'time' command as a wrapper:
>
> $ time dig ns1.linuxmafia.com @8.8.8.8
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20713
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>

> ;; ANSWER SECTION:
> ns1.linuxmafia.com.     21519   IN      A       198.144.195.186

>
>

> real    0m0.092s
> user    0m0.008s
> sys     0m0.012s
> $

>
> 'dig' can be badgered into using specifically TCP (instead of UDP)
> transport using a flag (+tcp) to that effect, or it can be told to use
> speciflcally only IPv4 or specifically only IPv6 using options to that
> effect (-4 and -6).
>
> It's the most versatile and reliable tool around for testing DNS
> functionality -- which in turn is useful to be able to test separately
> from the separate task of actually making connections for services
> after
> resolving DNS names to find where to reach them.
>
> I hope that helps.
>