DNS Reverse Lookup Error

Hi,

I have a bind9 install covering my internal network; the DNS forwarder on pfSense is configured with a Domain Override for my local domain, pointing pfSense at my bind9 install.

Forward lookups work fine, however reverse lookups fail from pfSense with (have tried the local DNS lookup commands on the pfSense box itself):


server can't find x.x.x.10.in-addr.arpa.: NXDOMAIN

Where the x.x.x is the specific address being searched for. In my bind9 configuration, the reverse lookup PTR file is attached to zone "10.in-addr.arpa"; nslookup on the bind9 host or any client pointed directly at the bind9 host rather than the DNS forwarder works correctly.

I have tried adding a Domain Override in the pfSense configuration for "10.in-addr.arpa" but it does not seem to have any affect.

Any ideas?

Regards,
Rob.

Derelict

Try making an x.x.10.in-addr.arpa file. I think you need a 10.in-addr.arpa file, with NS records to the x.10.in-addr.arpa zone with ns records to the x.x.10.in-addr.arpa zone.

Or you have to make the 10.in-addr.arpa zone contain the necessary information.

@ would be 10.in-addr.arpa so your PTR records would have to be:

x.x.x ptr host.example.com.

I've never used 10. so I don't know for sure.

phil.davis

Here is an example of domain override entries for reverse lookups in "10" network. I happen to use 10.49.0.0/16 in pieces across a bunch of sites.
A DNS server at 10.49.0.1 knows about 10.49.0.0/24 reverse entries.
A DNS server at 10.49.32.1 knows about reverse entries in the remainder of 10.49.0.0/16

DNS-reverse-lookup.png_thumb

doktornotor

Yeah, you need in-addr.arpa override for this. It works even with IPv6 and ip6.arpa, though I recommend using come online tool to generate it, like IPv6 Reverse domain calculator - pretty error prone to do it manually. :D

Sorry, but the problem is not configuration of the bind9 PTR file. That works fine. The problem is the pfSense DNS Forwarder does not perform the lookup.

It turns out the reason is I had checked the box marked "Do not forward private reverse lookups" It appears (although the instructions say otherwise) that the domain override for "10.in-addr.arpa" does not work if this option is switched on.

To check, I performed the following (all with the forward domain override intact):


Lookup		Reverse Override	DNFPRL		Outcome
10.1.1.1	NO			NO		Forward lookup only; No record found on reverse
10.1.1.1	NO			YES		Forward lookup only; No record found on reverse
10.1.1.1	YES			NO		Successful forward and reverse lookups
10.1.1.1	YES			YES		Forward lookup only; No record found on reverse

As a sanity test, I also tried changing the "10.in-addr.arpa" override to both "1.1.10.in-addr.arpa" and "1.10.in-addr.arpa" instead, and they both worked even with the "Do not forward private reverse lookups" checkbox ticked.

So it seems the answer is that the rule for allowing domain overrides past the block from the "Do not forward private reverse lookups" checkbox does not apply to the "10.in-addr.arpa" override.

Don't know if that's a bug or intentional, but for the time being I will leave the checkbox unchecked so that it works.

Regards,
Rob.

phil.davis

From memory, "Do not forward private reverse lookups" specifically has a list of the RFC1918 addresses that has stuff like:
10.in-addr.arpa
168.192.in-addr.arpa
16.172.in-addr.arpa
17.172.in-addr.arpa
…
31.172.in-addr.arpa

and if you use the whole of one of those in a domain override, there it overrides, but it is blocked from lookup anyway, so has no effect.
If you use parts of any of those, then the parts get looked up OK, and the rest is subject to "Do not forward private reverse lookups".
All a bit annoying, but tricky to sort out underneath.

phil.davis

I had a look at that code that implements "Do not forward private reverse lookups" and made it smarter.
Pull request: https://github.com/pfsense/pfsense/pull/1498
With that change, you can check "Do not forward private reverse lookups" and also have a working domain override for some chunk(s) of private IPv4 address space like:

10.in-addr.arpa
168.192.in-addr.arpa
16.172.in-addr.arpa
17.172.in-addr.arpa
...
31.172.in-addr.arpa