Why does nslookup fail for DNS records set to a private address?

Question

Setup

On some networks I'm able to use nslookup to resolve a domain name that is pointed to a private ip address:

@work> nslookup my192.ddns.net
Server:     10.1.2.3
Address:    10.1.2.3#53

Non-authoritative answer:
Name:   my192.ddns.net
Address: 192.168.20.20

However, on my home network this same query fails:

@home> nslookup my192.ddns.net
Server:     192.168.0.1
Address:    192.168.0.1#53

Non-authoritative answer:
*** Can't find my192.ddns.net: No answer

What Works

I've found that if I change the A record for my192.ddns.net so that it points to a public IP range it will work fine:

@home> nslookup my192.ddns.net
Server:     192.168.0.1
Address:    192.168.0.1#53

Non-authoritative answer:
Name:   my192.ddns.net
Address: 172.217.12.238

At home, if I specify the DNS server for nslookup, or set my laptop's DNS servers to Google's nslookup works as expected:

@home> nslookup my192.ddns.net 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   my192.ddns.net
Address: 192.168.20.20

But I'd like to continue to use my home router as my primary DNS so that it can resolve local network names. I'd just like it not to fail when trying to do lookups for DNS records that point to private range addresses (eg: 192.168.20.20)

Home Network

I run LEDE (formerly OpenWRT) on my home router, which run dnsmasq. I've looked over the documentation for DNS and have even setup the system so that the DNS server it uses to resolve the address is Google's (8.8.8.8) - but it still fails and I can't seem to figure out why.

Question

What's happening here and how can I fix it?

Solution 1

This is a feature of dnsmasq. The dnsmasq people call it "rebind protection", and you can see it both in the dnsmasq manual as the --stop-dns-rebind command-line option and in the LEDE doco as the rebind_protection option.

It defaults to being on. Either turn it off, or add the domain that you desire to work to the set of whitelisted rebind_domain domains.

The attack that it purports to prevent is one where an attacker, who has taken advantage of the fact that your WWW browser will automatically download and run attacker-supplied programs from the world at large, makes xyr domain name seem to rapidly alternate between an external IP address and one internal to your LAN, allowing your machine to become a conduit between another machine on your LAN with that IP address and some attacker-run content servers.

Solution 2

It is a security measure by some DNS software not to resolve to private IP addresses. I guess the rationale for this is to prevent accesses to non-secured routers.

This problem may be solved by not using one DNS which does all the resolving for you but to configure your resolver to connect to the NS for that domain itself.

Comments

[Rui F Ribeiro]

Actually I suspect I once run by this on a FreeBSD system...which software, can you tell?

[Hauke Laging]

@RuiFRibeiro No, sorry

[cwd]

Thanks! I saw on the documentation page boguspriv: Reject reverse lookups to private IP ranges where no corresponding entry exists in /etc/hosts and had tried that option without luck - is that you are referring to? If not, could you elaborate?

[Hauke Laging]

@cwd I encountered this problem years ago and do not remember any details; otherwise I would have mentioned them. You could run tcpdump on the WAN interface of the router in order to see where the problem appears.

[Rui F Ribeiro]

@cwd Seen that page and boguspriv seems to be something else -- dropping RFC 1918 DNS requests that are not yours in order not to clutter the DNS root name servers with bogus requests.

[roaima]

@RuiFRibeiro a forward lookup isn't an RFC1918 request; it's the result that's in RFC1918 address space. (The corresponding PTR would be, though.)