{"id":169,"date":"2024-01-24T14:39:20","date_gmt":"2024-01-24T21:39:20","guid":{"rendered":"https:\/\/dnstrouble.crider.dev\/?docs=common-problems-ssh-login-hangs-delays\/testing-domain-queries-and-application-quirks"},"modified":"2024-01-24T16:56:18","modified_gmt":"2024-01-24T23:56:18","slug":"testing-domain-queries-and-application-quirks","status":"publish","type":"docs","link":"https:\/\/dnstrouble.crider.dev\/?docs=common-problems-ssh-login-hangs-delays\/testing-domain-queries-and-application-quirks","title":{"rendered":"Testing domain queries and application quirks"},"content":{"rendered":"\n

When trying to gather test results, there are some important quirks that should be remembered.<\/p>\n\n\n\n

(1) DNS query tools such as ‘dig’ and ‘nslookup’ do -NOT- go through nsswitch. <\/strong>

They check \/etc\/resolv.conf directly.

This means if you are debugging \/etc\/hosts entries you cannot use dig or nslookup. <\/strong><\/p>\n\n\n\n

If you need to test the full DNS query ‘flow’ path (application -> glibc -> nsswitch -> \/etc\/hosts -> \/etc\/resolv.conf)
you should use the ‘getent<\/strong>‘ tool instead. It is designed for testing nsswitch entries:<\/p>\n\n\n\n

DESCRIPTION
The getent command displays entries from databases supported by the Name Service Switch libraries, which are configured in \/etc\/nsswitch.conf. If one or more key arguments are provided, then only the entries that match the supplied keys will be displayed. Otherwise, if no
key is provided, all entries will be displayed (unless the database does not support enumeration).<\/code><\/pre>\n\n\n\n
Ex. 1: 
I have defined ‘rhel92’ in my \/etc\/hosts. I want to get the value using getent:<\/p>\n\n\n\n
$ getent hosts rhel92
192.168.0.66 rhel92<\/code><\/pre>\n\n\n\n
Ex. 2: 
I want to go through the full \/etc\/nsswitch.conf ‘hosts:’ list (files, dns, myhostname) to lookup redhat.com:<\/p>\n\n\n\n
$ getent hosts google.com
2607:f8b0:400f:802::200e google.com<\/code><\/pre>\n\n\n\n
If you can’t remember to use getent, you can also use ping, it follow the same flow:<\/p>\n\n\n\n
Ex. 1:<\/p>\n\n\n\n
$ ping -c 1 rhel92
PING rhel92 (192.168.0.66) 56(84) bytes of data.
64 bytes from rhel92 (192.168.0.66): icmp_seq=1 ttl=64 time=1.30 ms<\/code><\/pre>\n\n\n\n
Ex. 2:<\/p>\n\n\n\n
ping -c 1 www.redhat.com
PING e3396.dscx.akamaiedge.net (23.37.105.122) 56(84) bytes of data.
64 bytes from www.redhat.com (23.37.105.122): icmp_seq=1 ttl=55 time=4.26 ms<\/code><\/pre>\n\n\n\n
(2) In the previous version of nslookup, by default only IPv4 results were returned from the DNS server. This was actually a bug, which was corrected in nslookup in RHEL 7.7:<\/strong><\/p>\n\n\n\n
https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/7\/html-single\/7.7_release_notes\/index<\/a><\/p>\n\n\n\n
Per the documentation above:<\/p>\n\n\n\n
“The nslookup utility now looks up both IPv6 and IPv4 addresses by default.”<\/strong><\/p>\n\n\n\n
As of RHEL 7.7 this is the default behavior for nslookup.<\/strong><\/p>\n\n\n\n
It is a common mistake for users to see nslookup return valid IPv4 records, but also return NXDOMAIN for IPv6 entries and think it’s a bug on the nslookup side when it is not.<\/strong><\/p>\n\n\n\n
Here is a basic example of what that might look like:<\/p>\n\n\n\n
[root@rhel79 ~]# nslookup rhel92
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: rhel92
Address: 192.168.0.66
** server can't find rhel92: NXDOMAIN<\/code><\/pre>\n\n\n\n
What happens here is nslookup tries to search our local DNS server running at 127.0.0.1 for both IPv4 and IPv6 records for the ‘rhel92’ domain.<\/p>\n\n\n\n
The DNS server only has IPv4 records and is only configured for IPv4, so it gives the IPv4 records to us:<\/p>\n\n\n\n
Address: 192.168.0.66<\/code><\/pre>\n\n\n\n
But it does not have any IPv6 records. Since nslookup asked for both, ‘NXDOMAIN’ is reported for the the requested but not found IPv6 records from our DNS server:<\/p>\n\n\n\n
** server can't find rhel92: NXDOMAIN<\/code><\/pre>\n\n\n\n
If you wish to only query ‘A’ records\/IPv4 records, you must specify the -query option with the ‘A’ value:<\/p>\n\n\n\n
[root@rhel79 ~]# nslookup -query=A redhat.com\nServer: 192.168.122.1\nAddress: 192.168.122.1#53\n\nNon-authoritative answer:\nName: redhat.com\nAddress: 10.4.204.55<\/code><\/pre>\n\n\n\n
The only other alternative to -not- receive NXDOMAIN for IPv6 when using nslookup is for the DNS server to be properly configured to respond to IPv6 requests.<\/strong><\/p>\n","protected":false},"featured_media":0,"parent":37,"menu_order":3,"comment_status":"open","ping_status":"closed","template":"","doc_tag":[],"_links":{"self":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/169"}],"collection":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/types\/docs"}],"replies":[{"embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=169"}],"version-history":[{"count":1,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/169\/revisions"}],"predecessor-version":[{"id":171,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/169\/revisions\/171"}],"up":[{"embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/37"}],"prev":[{"title":"\/etc\/resolv.conf","link":"https:\/\/dnstrouble.crider.dev\/?docs=common-problems-ssh-login-hangs-delays\/etc-resolv-conf","href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=\/wp\/v2\/docs\/166"}],"wp:attachment":[{"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=169"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/dnstrouble.crider.dev\/index.php?rest_route=%2Fwp%2Fv2%2Fdoc_tag&post=169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}