Score:0

Server

Issues with resolving of our reverse DNS zone

Marki555

3/10/23, 10:04 PM

Few days ago we noticed some of our outging emails being delayed due to remote mailservers unable to resolve our IP (for example Client host rejected: cannot find your hostname, [92.240.244.176]). We did not make any changes to our DNS recently and our ISP also says they did not touch it.

We have 92.240.244.128/25 delegated from their ns1/ns2.lightstorm.sk to our ns1/n2.mojhosting.sk (our ns1 is running BIND 9.10, ns2 is running PowerDNS 4.0).

They claim the fault is on our side because our DNS servers return REFUSED on this query host 92.240.244.202 ns1.mojhosting.sk, but this must have been like this for a long time. Maybe it is because that command queries for 202.244.240.92.in-addr.arpa., which is only CNAME on our ISP DNS, but does not exist inside our delegated 128/25.244.240.92.in-addr.arpa. sub-tree)? Running dig +trace for both records seems to work for me every time.

MXtoolbox says: Warning: Received Non-Authoritative (lame) Answer from: 'ns1.lightstorm.sk', but I have no idea how to check it. Global DNS Propagation Checker shows our IP unresolvable from majority of locations.

Also our ISP has quite bad IPv6 connectivity and I see their ns1/ns2 having also IPv6 addresses, could this also add to the issue?

134

0 + 0

domain-name-system

Patrick Mevzek

3/10/23, 10:18 PM

See https://dnsviz.net/d/202.244.240.92.in-addr.arpa/dnssec/ You have indeed a misconfiguration in some delegation hence the lame answer you see.

Marki555

3/10/23, 10:27 PM

So the issue seems to be between 92.in-addr.arpa and 244.240.92.in-addr.arpa.? So that they say via DNSSEC that 244.240.92.in-addr.arpa. doesn't exist, but without DNSSEC (at least via `dig`) it still works?

Marki555

3/11/23, 9:59 AM

@PatrickMevzek ok, after sleep it seems to me that NSEC is there only because ns1.lightstorm.sk doesn't use DNSSEC and that doesn't prevent resolution (and is marked only as Warning in dnsviz). The real issue is that they return response without the AA flag (marked as Error in dnsviz), correct?

Patrick Mevzek

3/11/23, 8:44 PM

Correct, there is nothing DNSSEC related here in fact. See my longer answer.

Score:1

Server

Patrick Mevzek

3/11/23, 8:44 PM

Your DNS configuration "works" somehow but it is not correct fully, hence can create problems for some cases.

Here is why.

If you query directly you do get a reply:

$ dig -x 92.240.244.176 +noall +ans +nottlunits
176.244.240.92.in-addr.arpa. 3590 IN CNAME 176.128/25.244.240.92.in-addr.arpa.
176.128/25.244.240.92.in-addr.arpa. 43191 IN PTR bill3.hostio.sk.

So we got the final PTR record and we should be happy.

However, if we diagnose all the path from . (root) until 176.244.240.92.in-addr.arpa. we can see a problem.

DNSViz at https://dnsviz.net/d/202.244.240.92.in-addr.arpa/YYzr-A/dnssec/ shows it, if you look at the Errors part:

202.244.240.92.in-addr.arpa/CNAME: The Authoritative Answer (AA) flag was not set in the response. (92.240.232.232, 92.240.232.242, 2a00:10d8:11::1:0:1, 2a00:10d8:11::2:0:1, UDP_-_EDNS0_4096_D_KN)

You can see the same by using dig +trace 202.244.240.92.in-addr.arpa. PTR +nottlunits +nodnssec which gives the below (trimming the first steps at root and 2 domains):

[..]

92.in-addr.arpa.    86400 IN NS ns3.afrinic.net.
92.in-addr.arpa.    86400 IN NS pri.authdns.ripe.net.
92.in-addr.arpa.    86400 IN NS ns3.lacnic.net.
92.in-addr.arpa.    86400 IN NS ns4.apnic.net.
92.in-addr.arpa.    86400 IN NS rirns.arin.net.
;; Received 245 bytes from 200.10.60.53#53(d.in-addr-servers.arpa) in 199 ms

244.240.92.in-addr.arpa. 172800 IN NS ns1.lightstorm.sk.
244.240.92.in-addr.arpa. 172800 IN NS ns2.lightstorm.sk.
;; Received 133 bytes from 199.253.249.53#53(rirns.arin.net) in 142 ms

;; expected opt record in response
202.244.240.92.in-addr.arpa. 3600 IN CNAME 202.128/25.244.240.92.in-addr.arpa.
128/25.244.240.92.in-addr.arpa. 3600 IN NS ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 3600 IN NS ns2.mojhosting.sk.
;; Received 119 bytes from 92.240.232.242#53(ns2.lightstorm.sk) in 173 ms

But the last answer has a problem, the flag "AA" (Authoritative Answer) is missing from it. This final nameserver (ns1.lightstorm.sk) is giving some data (the CNAME record) but does not say it is authoritative on it, where it should.

See this answer without the unneeded details:

$ dig @ns1.lightstorm.sk. 202.244.240.92.in-addr.arpa. PTR

[..]

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32312
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;202.244.240.92.in-addr.arpa. IN    PTR

;; ANSWER SECTION:
202.244.240.92.in-addr.arpa. 1h IN CNAME 202.128/25.244.240.92.in-addr.arpa.

;; AUTHORITY SECTION:
128/25.244.240.92.in-addr.arpa. 1h IN NS ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 1h IN NS ns2.mojhosting.sk.

Note the "flags" part, it should have an "AA" flag. Also the fact that it has "RA" (Recursion Available) seems to show that this nameserver is both authoritative and recursive which is most of the time a bad idea, both services should be separate.

A recursive nameserver will see that, and refuse to go further, hence the various errors you get. Owner of ns1.lightstorm.sk. + ns2 needs to fix its configuration, the problem is there and not elsewhere.

If you want to compare, this is a similar setup, but working for IP 162.202.233.81.

Note how DNSViz does not show any error: https://dnsviz.net/d/81.233.202.162.in-addr.arpa/YY1_ag/dnssec/

and also if you redo the last step to compare with above:

$ dig @ns2.swbell.net. 81.233.202.162.in-addr.arpa. PTR

[..]

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24342
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.233.202.162.in-addr.arpa. IN    PTR

;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 2h IN CNAME 81.80/29.233.202.162.in-addr.arpa.

;; AUTHORITY SECTION:
80/29.233.202.162.in-addr.arpa. 2h IN NS ns2.archaxis.net.
80/29.233.202.162.in-addr.arpa. 2h IN NS ns1.archaxis.net.

Note how the "flags" part is different.

FWIW this kind of setup in the reverse tree is the one designed in RFC 2317 "Classless IN-ADDR.ARPA delegation", using CNAME to be able to subdelegate parts of the tree.

0 + 0

Marki555

3/11/23, 10:37 PM

You mean owner of `ns1.lightstorm.sk` (our ISP who delegates us our IP range) need to fix it? Because you wrote `ns1.mojhosting.sk`...

Patrick Mevzek

3/11/23, 10:44 PM

Yes you are right, sorry about that, I edited. More than my writings, just trust the dig output or what DNSViz says, both tell the problem is with server at `92.240.232.232` (+ IPv6 + its companion), so that is lightstorm.sk indeed.

Marki555

3/24/23, 8:52 PM

Our ISP did fix something, now resolution works (no errors in mailserver logs), but dnswiz still shows the error, so I'm not sure what has changed...

Patrick Mevzek

3/24/23, 9:56 PM

The DNSviz URL I gave is "timestamped", it shows the configuration at a specific date, so the content will never change (it does not trigger a new analysis). You have to run a new diagnostic to see the current configuration. I just done it, it gives the following new timestamped URL: https://dnsviz.net/d/202.244.240.92.in-addr.arpa/YZ60tQ/dnssec/ ; however it shows the same problem still. No idea what your ISP "fixed", but it clearly doesn't show. So again, depending on many other external factors, resolution may work or not, but the DNS configuration is broken.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Issues with resolving of our reverse DNS zone

TH: ปัญหาเกี่ยวกับการแก้ไขโซน DNS ย้อนกลับของเรา

RO: Probleme cu rezolvarea zonei noastre DNS inverse

RU: Проблемы с разрешением нашей обратной зоны DNS

VI: Các vấn đề với việc giải quyết vùng DNS đảo ngược của chúng tôi

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.