DNS Forwarder - Do not forward private reverse lookups kills Domain Override

ssheikh

Hi,

I am on 2.1-RC1 (amd64) Tue Jul 30 06:13:10 EDT 2013.

In DNS forwarder checking the "Do not forward private reverse lookups" check box also stops forwarding private reverse lookups that have Domain Overrides defined. Dnsmasq just returns non-existent domain.

Unchecking that box gets the override working again properly.

Thanks,

Shahid

wallabybob

@ssheikh:

In DNS forwarder checking the "Do not forward private reverse lookups" check box also stops forwarding private reverse lookups that have Domain Overrides defined. Dnsmasq just returns non-existent domain.

Seems to me that is documented behaviour: (from Services -> DNS Forwarder:

Do not forward private reverse lookups
If this option is set, pfSense DNS Forwarder (dnsmasq) will not forward reverse DNS lookups (PTR) for private addresses (RFC 1918) to upstream name servers. Any entries in the Domain Overrides section forwarding private "n.n.n.in-addr.arpa" names to a specific server are still forwarded. If the IP to name is not known from /etc/hosts, DHCP or a specific domain override then a "not found" answer is immediately returned.

If you think the behaviour is contrary to that described please provide more detailed supporting evidence.

ssheikh

@wallabybob:

Any entries in the Domain Overrides section forwarding private "n.n.n.in-addr.arpa" names to a specific server are still forwarded.

The way I read the above, it means that Domain Overrides for the defined private reverse domains pointing to specific DNS servers in the overrides section will still be forwarded even if this option is checked.

In my case I have a domain override specified for the domain "10.in-addr.arpa" that points to a DNS server on the LAN interface. With this option unchecked, my PTR query is forwarded to the DNS server and I get a proper response. I see all that happening as expected in the packet captures as well.

With this option checked, looking at packet capture, I can see that the query is never forwarded to the override DNS server and dnsmasq directly returns a response with a DNS reply code "No such name" (0x0011)

phil.davis

/* If selected, then forward reverse lookups for private IPv4 addresses to nowhere. */
if (isset($config['dnsmasq']['no_private_reverse'])) {
  /* Note: Carrier Grade NAT (CGN) addresses 100.64.0.0/10 are intentionally not here. */
  /* End-users should not be aware of CGN addresses, so reverse lookups for these should not happen. */
  /* Just the pfSense WAN might get a CGN address from an ISP. */
  $args .= " --server=/10.in-addr.arpa/ ";
  $args .= " --server=/168.192.in-addr.arpa/ ";
  /* Unfortunately the 172.16.0.0/12 range does not map nicely to the in-addr.arpa scheme. */
  for ($subnet_num = 16; $subnet_num < 32; $subnet_num++) {
    $args .= " --server=/" . $subnet_num . ".172.in-addr.arpa/ ";
  }
}

This code in services.inc services_dnsmasq_configure() puts in all the private IPv4 address space with no forwarding specified.
I have domain overrides like:
42.10.in-addr.arpa
43.10.in-addr.arpa
44.10.in-addr.arpa

for the couple of bits of the 10 network that I use internally, and it works. I guess these are more specific, and so get matched first by the internals of dnsmasq. Some time ago I had put Domain Override 10.in-addr.arpa and it didn't work, I never thought about it being an exact match for the one generated by this option.

Perhaps it depends on the order in the command line, which 10.in-addr.arpa is actually actioned. I will try swapping the order of the –server entries, and if that doesn't work, then the code will need to be smarter and detect when the user is explicitly using any of these as a Domain Override.

phil.davis

Yep, changing the code order works - that will save me a couple of Domain Overrides entries on every system, I can use 10.in-addr.arpa now.
This will work easily for 10.in-addr.arpa and 168.192.in-addr.arpa
172.16.0.0/12 is a little more tricky, but nobody can use 172.in-addr.arpa in a domain override, since that covers /8, which is bigger than the reserved /12. They would have to specify 1 or or more of the 16.172.in-addr.arpa 17.172.in-addr.arpa … names anyway (or even more specific). So their user-specified domain overrides should override the ones generated here.
I think the logic is right?
Pull request for Master: https://github.com/pfsense/pfsense/pull/749
Pull request for 2.1: https://github.com/pfsense/pfsense/pull/750
(Use the 2.1 version if you are going to apply this by hand)

ssheikh

Thanks Phil. I haven't had a chance to go back and test this yet. Will do so over the weekend.

Speaking strictly from a DNS perspective, "172.in-addr.arpa" is just a dns zone. So if someone wanted to override that entire zone and send it to a different DNS server, they should be able to. For that matter, if they wanted to override the whole in-addr.arpa, that should be a valid configuration as well.

phil.davis

I think those cases should (kind of) work "reasonably" now. If the user has the checkbox ticked then also adds a domain override for:
a) in-addr.arpa - everything in in-addr.arpa will go to the override destination, except the private address space stuff, which will not be forwarded anywhere - this seems reasonable behaviour.

b) 172.in-addr.arpa - everything in 172.in-addr.arpa will go to the override destination, except the private address space bit/s, which will not be forwarded anywhere - this seems (almost) reasonable behaviour.

c) 192.in-addr.arpa - everything in 192.in-addr.arpa will go to the override destination, except the private address space bit 168.192.in-addr.arpa, which will not be forwarded anywhere - this seems (almost) reasonable behaviour.

i.e. if you check the checkbox then add an override for a chunk of reverse lookup name space that is bigger than an included bit of private space, the private space subset does not get overridden.
Technically that is not in the text explanation on the GUI - but I suspect it is too hard to explain all that without being confusing. And I suspect that almost nobody will do this sort of thing - maybe a few people might use case (a), and if they really want to redirect all the reverse lookup name space then they won't be checking the checkbox in the first place.

ssheikh

Just tested this and it is working well.

The three cases you mentioned are also working exactly as you described.

I think a minor change in the description of the "Do not forward private reverse lookups" option can remove some of the confusion surrounding the three cases.

Do not forward private reverse lookups
If this option is set, pfSense DNS Forwarder (dnsmasq) will not forward reverse DNS lookups (PTR) for private addresses (RFC 1918) to upstream name servers. ~~Any entries in the Domain Overrides section forwarding private "n.n.n.in-addr.arpa" names to a specific server are still forwarded.~~ Use the Domain Overrides feature to forward a particular private IP address reverse domain or its sub-domain. Parent domains of private IP address reverse domains (e.g. in-addr.arpa, 192.in-addr.arpa, or 172.in-addr.arpa) cannot be used in Domain Overrides if this option is set. If the IP to name is not known from /etc/hosts, DHCP or a specific domain override then a "not found" answer is immediately returned.

Or something like that…