0

I am in dire need of help! Some of our hosted Exchange users recently are getting NDRs when sending to some domains. I believe error is 554 NO PTR IP FOUND. I swore we had our ISP put in a PTR and indeed it was there. However, my other colleague noticed that Google's DNS is not returning the results and instead provides a SERVFAIL error instead. Turns out that Google DNS does DNSSEC validations by default for all queries and if the zone is not signed, then no harm done. However, if zone is DNSSEC enabled but not configured correctly, then you'd get SERVFAIL.

We have talked with our ISP and they refuse to acknowledge that the problem is on their side as they keep saying that DNSSEC is never enabled on any of their .in-addr.arpa zones. But when we do online validation checks, this proves otherwise.

The IP in question is x.x.x.x and is hosted by Centurylink.

https://dnssec-debugger.verisignlabs.com/.in-addr.arpa http://dnsviz.net/d/.in-addr.arpa/dnssec/

My theory is that the receiving email server is simply doing a PTR SPAM check AND they are also configured to use Google's DNS servers of 8.8.8.8 as the resolvers. Because it receives the SERVFAIL message, our clients get the NDR since it can't verify our sending relay server.

I really need help in proving to the ISP that this is somehow DNSSEC related as they keep pushing back arguing that it has ZERO percent to do with DNSSEC. I'm trying to use DIG to prove somehow that DNSSEC is related so please help me out! I've shown those two links to them yet they aren't budging. Am I going crazy or are they correct?

TIA!

EDIT: I have removed our public IP from being listed as our issue seems to have been resolved for now.

2

I would say that the your http://dnsviz.net link makes it very clear how this is a DNSSEC issue.

Yet, if you want to illustrate using dig I would go with +cdflag. it sets the "CD (checking disabled) bit in the query", explicitly telling the resolver to skip DNSSEC validation.

In the example below I'll be using the dnssec-failed.org domain, which is meant to fail DNSSEC wise.

$ dig @8.8.8.8 dnssec-failed.org SOA

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @8.8.8.8 dnssec-failed.org SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8707
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dnssec-failed.org.     IN  SOA

;; Query time: 492 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 09 10:24:17 CET 2018
;; MSG SIZE  rcvd: 46

$

vs.

$ dig +cdflag @8.8.8.8 dnssec-failed.org SOA

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +cdflag @8.8.8.8 dnssec-failed.org SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30849
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dnssec-failed.org.     IN  SOA

;; ANSWER SECTION:
dnssec-failed.org.  21599   IN  SOA dns101.comcast.org. dnsadmin.comcast.net. 2010101883 900 180 604800 7200

;; Query time: 189 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 09 10:25:28 CET 2018
;; MSG SIZE  rcvd: 117

$
  • Thanks andol! I was supposed to have a conference call with them this very morning today. I guess the CenturyLink DNS admins I was talking with finally looked at the websites last night I referred to previously and they now have identified an issue on their part! I will edit your answer to remove our public IP. Thank you!! – isolated_1 Mar 8 '18 at 19:48
  • I went ahead with a different edit, which still provided a meaningful example. – andol Mar 9 '18 at 9:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.