DNS blocks RFC1918 answers [SOLVED]

nailezs

Hey guys,

I'm new here, forgive me for any rule breaking.

I have pfsense running an isolated enclave that hangs off of a 10/8, so it goes:

10.0.0.0/8 -> (WAN) pfsense (LAN) <- 192.168.0.0/16

10.0.0.0/8 I'll call "corp", 192.168.0.0/16 I'll call "local" (it's not really set to "local", I promise)

I have DHCP working appropriately, linked with DNS. But I have 2 1 problems:

1) Sometimes when querying from "local" to "corp" for names (some-server.corp), pfsense suffixes the "corp" name with my "local" -> some-server.corp.domain
IE "nslookup some-server.corp" goes to pfsense, which turns the query into "nslookup some-server.corp.local"
Obviously, the "corp" dns servers have no clue what this is, and return NXDOMAIN.

tcpdump from pfsense-LAN connection (labeled sequentially with (#)):
(1) IP local-server.local.53610 > pfSense.local.domain: 4550+ A? some-server.corp. (35)
(4) IP pfSense.local.domain > local-server.local.53610: 4550 NXDomain 0/0/0 (35)

tcpdump from pfsense WAN connection:
(2) IP pfsense-WAN.51204 > dns.corp.domain: 13545+ A? some-server.corp.local. (56)
(3) IP dns.corp.domain > 10.128.7.1.51204: 13545 NXDomain 0/1/0 (131)

If I query from "local" to "corp", "nslookup some-other-server.corp" and the answer from the "corp" dns servers is in 10.0.0.0/8, pfsense strips the answer and forwards "no answer" to the "local" server.

tcpdump from pfsense-LAN connection (labeled sequentially with (#)):
(1) IP local-server.local.47286 > pfSense.local.domain: 8139+ A? some-server.corp. (39)
(4) IP pfSense.local.domain > local-server.local.47286: 8139* 0/0/0 (39)

tcpdump from pfsense WAN connection:
(2) IP pfsense-WAN.60531 > some-server.corp.domain: 9225+ A? some-server.corp. (39)
(3) IP some-server.corp.domain > pfsense-WAN.60531: 9225* 1/0/0 A 10.X.X.X (55)

I'm using the DNS Forwarder. The following are enabled: Enable DNS forwarder, Register DHCP leases in DNS Forwarder, Register DHCPstatic mappings in DNS Forwarder, Resolve DHCP mappings first, Query DNS servers sequentially, Require domain. Interfaces is set to "All".

Please help!

Thanks!

UPDATE: A reboot seems to have solved issue #1. Ghost in the Machine, perhaps? I've edited the post title accordingly.

UPDATE 2: FIXED! I was unaware of DNS Rebinding attacks or of pfSense's protections against it. Here's a link to the docs: https://www.netgate.com/docs/pfsense/dns/dns-rebinding-protections.html

Cabledude

@nailezs : thank you so much for following up on your own question so as to help others.

@ netgate staff and other specialists:

I also created some new DNS entries that are being blocked now. This article explains why.
However:
Sometime in the past year I created a DNS record entry to a private address (the pfSense firewall in fact) in my cloudflare DNS dashboard. At the time it wasn’t blocked. A “nslookup <host>.<domain>” query yielded the private IP address.
What’s more: those FQDN’s are still resolved today, even though they should be blocked by the rebinding protection.

What could be going on here? Some kind of caching? Shouldn’t be as I used the default TTL settings in cloudflare.

Other ideas?

johnpoz

@Cabledude without details - hard to say what your doing. Do you even have rebind protection enabled.

What is the fqdn you are doing query for that returns rfc1918. If you are asking some other ns other than pfsense? If you don't want to post in public - send it to me in a DM.

It sure isn't going to be a ttl, rebind protection has been part of pfsense for years and years..