Quoting goli...@dyne.org (goli...@dyne.org): > 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
