0

I am seeing some problems with PTR zone resolution, and I can't quite figure out what is not configured correctly.

Summary:

1) I've been delegated authority for my PTR zone (246.237.204.in-addr.arpa, non-RFC2317), and DNS correctly shows that the SOA is my name server:

$ dig SOA 246.237.204.in-addr.arpa

; <<>> DiG 9.8.3-P1 <<>> SOA 246.237.204.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37131
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;246.237.204.in-addr.arpa.  IN  SOA

;; ANSWER SECTION:
246.237.204.in-addr.arpa. 2452  IN  SOA ns1.playnet.com. hostmaster.playnet.com. 2017092502 10800 900 86400 3600

;; Query time: 23 msec
;; SERVER: 17.128.100.12#53(17.128.100.12)
;; WHEN: Wed Sep 27 11:30:29 2017
;; MSG SIZE  rcvd: 104

2) My DNS is set up with multiple Views. The PTR zone is configured in in both views. I had it only in the external view at first, but when I discovered this wasn't working, I added it to the internal (LAN) view as well, just in case.

zone "246.237.204.in-addr.arpa" in {
    type master;
    file "db.246.237.204.rev";
    also-notify { 192.168.88.253 key external-key; };
    allow-query { any; }
};

3) Resolution from my LAN works as expected (dig -x 204.237.246.33 does provide the correct answer).

dig -x 204.237.246.33

; <<>> DiG 9.9.5-9+deb8u13-Debian <<>> -x 204.237.246.33
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63647
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

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

;; ANSWER SECTION:
33.246.237.204.in-addr.arpa. 3600 IN    PTR maild.playnet.com.

;; AUTHORITY SECTION:
246.237.204.in-addr.arpa. 3600  IN  NS  ns1.playnet.com.
246.237.204.in-addr.arpa. 3600  IN  NS  ns2.playnet.com.

;; ADDITIONAL SECTION:
ns1.playnet.com.    7200    IN  A   192.168.88.252
ns2.playnet.com.    7200    IN  A   192.168.88.253

;; Query time: 2 msec
;; SERVER: 192.168.88.252#53(192.168.88.252)
;; WHEN: Wed Sep 27 13:13:01 CDT 2017
;; MSG SIZE  rcvd: 155

4) Resolution from OUTSIDE my LAN fails with NXDOMAIN for any configured host in the reverse zone:

$ dig -x 204.237.246.33

; <<>> DiG 9.8.3-P1 <<>> -x 204.237.246.33
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13946
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

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

;; Query time: 95 msec
;; SERVER: 17.128.100.12#53(17.128.100.12)
;; WHEN: Wed Sep 27 11:21:12 2017
;; MSG SIZE  rcvd: 45

Q1: If the SOA is is correct, why isn't my NS being queried for this?

Now, the strange part. When I specify my nameserver in a query external to my LAN, the answer I get back from outside has a weird authority:

$ dig @ns1.playnet.com -x 204.237.246.33

; <<>> DiG 9.8.3-P1 <<>> @ns1.playnet.com -x 204.237.246.33
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37679
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

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

;; AUTHORITY SECTION:
168.192.IN-ADDR.ARPA.   86400   IN  SOA 168.192.IN-ADDR.ARPA. . 0 28800 7200 604800 86400

;; Query time: 43 msec
;; SERVER: 204.237.246.252#53(204.237.246.252)
;; WHEN: Wed Sep 27 11:14:18 2017
;; MSG SIZE  rcvd: 100

Q2: How is it that 168.192.in-addr.arpa is showing as the authority? Where did that come from?

My internal LAN is an RFC 1912 network (192.168.88.0/24), and I have specified that zone in my Internal view:

zone "88.168.192.in-addr.arpa" {
       type master;
        file "/etc/bind/internal/db.88.168.192.in-addr.arpa";
        also-notify { 192.168.88.253 key internal-key; };
};

Q3: Does the fact that when I query my NS directly and receive NXDOMAIN mean it's a mis-configuration on my NS, or can it be a configuration issue with my ISP?

Thanks in advance...this problem is making me lose sleep!

0

Q1: I don't really understand the reasoning.

Q2: This is indeed strange, I don't believe BIND has the capability of answering with something entirely unrelated like this.

Q3: Normally, I would say "yes", but considering Q2 I suspect this may not be what is going on in this particular scenario.

I also see that one gets entirely different answers over UDP and TCP.

This combined with Q2, leads me to believe that either something else than BIND is bound to 53/udp on the WAN interface or there is something else "in the middle" that is meddling with the traffic.
Do check what process has bound to 53/udp on that address (netstat -plnut or similar) to begin with.

Over UDP the response is as per your question, but over TCP:

$ dig @204.237.246.253 -x 204.237.246.33 +norec +tcp

; <<>> DiG 9.11.1-P3-RedHat-9.11.1-2.P3.fc26 <<>> @204.237.246.253 -x 204.237.246.33 +norec +tcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50398
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

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

;; ANSWER SECTION:
33.246.237.204.in-addr.arpa. 3600 IN    PTR     maild.playnet.com.

;; AUTHORITY SECTION:
246.237.204.in-addr.arpa. 3600  IN      NS      ns1.playnet.com.
246.237.204.in-addr.arpa. 3600  IN      NS      ns2.playnet.com.

;; ADDITIONAL SECTION:
ns1.playnet.com.        14400   IN      A       204.237.246.252
ns2.playnet.com.        14400   IN      A       204.237.246.253

;; Query time: 128 msec
;; SERVER: 204.237.246.253#53(204.237.246.253)
;; WHEN: Wed Sep 27 18:49:34 UTC 2017
;; MSG SIZE  rcvd: 155

$

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.