2

I am trying to configure my nameservers to resolve a PTR zone for which we are authoritative. I have several forward zones that work just fine, but when I try to resolve a PTR, the result does not contain an answer.

The config has multiple views. Our internal view is for a 192.168.x.x network. The PTR zone is configured in the external view.

One thing I noticed is that in the reply, it shows our 192.168 zone as being SOA, which is strange to me:

dig -x 204.237.246.33

;; QUESTION SECTION:
;16.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

Here is the error I'm seeing in general.log:

09-Sep-2017 00:12:23.931 DNS format error from 199.212.0.73#53 resolving 
33.246.237.204.in-addr.arpa/PTR for client 192.168.88.252#47911: question 
section mismatch: got 33.88.168.192.in-addr.arpa/IN/PTR

So the only diff I see is /IN/PTR vs /PTR Any input on how to remedy this would be helpful.

AaplMike
  • 167
  • 1
  • 8
  • Looking into it more, I've noticed some particularly strange things happening on my server. First off, the SOA is correctly pointing to my nameserver. Secondly, from my nameserver, I can resolve an IP address correctly. However, from outside my LAN and specifically asking my primary nameserver for the same resolution, it returns NXDOMAIN. Other LAN hosts get correct answers for "nslookup 204.237.246.33". No external hosts do. The strange thing is that I have the zone 246.237.204.in-addr.arpa in the EXTERNAL zone, yet it's only resolving from the INTERNAL zone. That's kinda odd. – AaplMike Sep 22 '17 at 21:28

1 Answers1

0

The names 33.246.237.204.in-addr.arpa and 33.88.168.192.in-addr.arpa are clearly not the same.

It's definitely not normal to get back an answer that doesn't match the question, it's not something that can ever be expected to work.
Either the server you are querying is badly broken or there is some device in the middle that meddles with the traffic (in a badly broken way).

My impression is that this is not directly tied to your BIND installation itself, but either whatever is running at 199.212.0.73 or something in your environment that interferes with the communications with 199.212.0.73.

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • Considering that `199.212.0.73` is `a.in-addr-servers.arpa.` I think we can be pretty confident that it's the "something meddling with the traffic" alternative. – Håkan Lindqvist Sep 09 '17 at 13:12