Questions[dns-lookup](server)

There are various references (such as DNS can't resolve hostname; nslookup can or https://web.archive.org/web/20160525082756/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html or https://web.archive.org/web/20121113214415/http://cbfive.com/blog/post/PING-vs-NSLookup.aspx) that state the following or something similar, but don't give suggestions for alternatives to use:

The reason ping can't resolve the hostname but nslookup can is because nslookup a low-level tool that bypasses the Windows DNS client. It uses whatever DNS server you tell it to (the first one by default), and does the query on the fly.

My question is, how can I manually test the DNS Client to check an SRV record? Is there a way to see the DNS information it tries to use? I can't put Wireshark on every servers in every environment, so I am looking for another way to troubleshoot. I presume the answer is "no", otherwise why would we use nslookup (flawed as it is). Obviously I can't use ping for an SRV record.

Edited with updated findings: The UDP queries are too long, so DNS response with the truncate flag gets sent to the client, so a TCP query needs to be made. The next packet after the TCP DNS query is (from TargetDNS to client): "TCP segment of a reassembled PDU" (which looks like it contains response info), and then is different depending on the scenario:

• Nslookup query - with the nslookup query there is actually a DNS response packet with the information
• ApplicationX (which I believe uses Windows DNS Client) - Windows DNS client query, there is no DNS response packet (i.e. like the other TCP packet has been lost)
  • There is nothing in the DNS cache (ipconfig /displaydns) or on the Client DNS server cache for the SRV record (not even a negative).

It proves, unsurprisingly, the DNS client and nslookup get different results but exactly what are they doing differently (discounting hosts, lmhosts, appending DNS search suffixes, etc)? They are using the same DNS servers (as evidenced by Wireshark). How can I narrow down where the fault lies?

In our scenario, We're running into an issue with our SPF records in route53. We are receiving SPF Too Many DNS Lookups because we are using multiple mail services. Is there a way to resolve this? I saw one thread stating to run a look up on the domains and include them by IP but that doesn't seem too stable of a solution. Another said to us PTR but that seems like the same path. Is there a better way you know of that we could achieve this?

"Error! 15 DNS lookups required to evaluate the SPF record. The maximum is 10."

v=spf1 ip4:52.209.21.221 include:spf1.abc.com include:spf2.abc.com ~all

We have 7 mailing platforms which is causing too many DNS lookups.

spf1.abc.com    -
    
"v=spf1 include:_spf.salesforce.com include:spf.protection.outlook.com include:mail.zendesk.com ~all"

spf2.abc.com    -
    
"v=spf1 include:amazonses.com include:sendgrid.net include:abc-com.spf.smtp25.com include:_spf.google.com ~all"

Is this modification will help

"v=spf1 ip4:52.209.21.221 include:spf1.abc.com -all"

Do we need to go with SPF flattening technique, how can we achieve that can anyone advise me on this?

I have a nginx server on PC_A running as a proxy for a website hosted on PC_B. The server on PC_A provides rate limiting, buffer and cache services for the website.

I would like to enable DNS lookup on PC_A and allow access to the server on PC_B only if the name resolves correctly.

I found this page https://www.nginx.com/resources/wiki/modules/rdns/ that discusses such features, but I am not sure how to implement the rdns_allow or rdns_deny based on the outcome of the lookup. Any help or guidance would be appreciated.

So if I use dig to do a reverse lookup I get:

$ dig 71.74.56.122

; <<>> DiG 9.6.0-APPLE-P2 <<>> 71.74.56.122
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41277
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;71.74.56.122.          IN  A

;; ANSWER SECTION:
71.74.56.122.       655360  IN  A   71.74.56.122

Using nslookup, I get:

$ nslookup 71.74.56.122
Server:     10.0.1.1
Address:    10.0.1.1#53

Non-authoritative answer:
122.56.74.71.in-addr.arpa   name = hrndva-omtalb.mail.rr.com.

Can anyone tell me why dig refuses to do the reverse lookup?