Home / server / Questions / 1083194
Accepted
Marki555
Asked: 2021-11-11 14:04:50 +0800 CST

Issues with resolving of our reverse DNS zone

  • 772

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?

domain-name-system

1 Answers

  1. Best Answer

    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.

    • 1