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.

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

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.

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.

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.