DNS problems with public records containing RFC1918 results
-
Some background - a user on the ##pfsense IRC channel observed that some DNS queries were failing through pfsense 2.2.x Turns out the results are inside RFC1918 ranges.
We'll just ignore why someone would want to do this - the public DNS is not the right place to store private records.
Try resolving these sample FQDNs through your pfsense DNS server, only the last one works?
-
a.rfc1918.criggie.org.nz has address 10.1.2.3
-
b.rfc1918.criggie.org.nz has address 172.22.22.144
-
c.rfc1918.criggie.org.nz has address 192.168.192.168
-
l.rfc1918.criggie.org.nz has address 127.0.0.1
That's because the DNS server (unbound in 2.2) refuses to pass on any results that contain RFC1918 addresses.
In case you actually want to do this, the workaround is to put a Domain Override into the DNS Resolver, as per screenshot.
You need to do a whois on the domain and find an authorative nameserver's IP to poke in.
This will break if the domain changes nameservers, but if your network depends on crazy stuff then one more SPOF isn't going to make a difference.Doubtless there's keywords and advanced options that can be fed to unbound to make this work…. left as an exercise for the motivated.
-
-
Do you mean that "host overrides" doesn't work here?
I'm surprised because I'm using it (I hope ;D ;D ;D)DNS forwarder has a configuration option to not forward addresses belonging to RFC1918 but I never noticed similar option with DNS Resolver.
On point this is ringing some bells in my mind: I've the feeling that you are explaining occurs when pfSense is used as "public" DNS, meaning requested from internet? Am I correct?
In case I am, this would be my first question mark: why one would want to user DNS Resolver as its public DNS :o
-
Pretty sure protection is enabled by default in unbound
https://doc.pfsense.org/index.php/DNS_Rebinding_ProtectionsIf you want to remove this protection just
server:
private-domain: "example.com"where is example.com is the domain in question.. So
example with default settings
C:>dig a.rfc1918.criggie.org.nz
; <<>> DiG 9.10.2 <<>> a.rfc1918.criggie.org.nz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64191
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;a.rfc1918.criggie.org.nz. IN A;; Query time: 1061 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue May 12 07:49:28 Central Daylight Time 2015
;; MSG SIZE rcvd: 53now example with
server:
private-domain: "criggie.org.nz"C:>dig a.rfc1918.criggie.org.nz
; <<>> DiG 9.10.2 <<>> a.rfc1918.criggie.org.nz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37889
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;a.rfc1918.criggie.org.nz. IN A;; ANSWER SECTION:
a.rfc1918.criggie.org.nz. 300 IN A 10.1.2.3;; Query time: 1258 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue May 12 07:50:40 Central Daylight Time 2015
;; MSG SIZE rcvd: 69But I am at a loss to why anyone would put rfc1918 in public dns??
-
Excellent finding, thank you!
But I am at a loss to why anyone would put rfc1918 in public dns??
I added them to my domain purely for testing. The original guy with the problem said that he inherited the design, that it was already set up like that before he started in the role. He did comment that "the DNS traffic doesn't go through the VPN"
To speculate, they've got some kind of client VPN software, but DNS queries to the *.workname.com domain aren't forced through the tunnel ?
Extra - I wonder if unbound does anything fiddly with IPv6 results…..
-
So they have vpn road warrior doing some sort of split tunnel where only specific networks are routed down the vpn tunnel, and they don't want to have the vpn client use the dns on the place they are vpn'ing too?
So I split tunnel, and only route specific segments down my vpn. But when I connect to the vpn I use the dns at my vpn location so I can resolve the domain there and all local hosts at the vpn location. This allows me to still resolve public stuff, but does prevent me from resolving local stuff on the vpn client side.
I still wouldn't put rfc1918 in public space.. If you want your road warriors to resolve your vpn server side stuff, but not use the dns there - have them use a host file ;)
-
So they have vpn road warrior doing some sort of split tunnel where only specific networks are routed down the vpn tunnel, and they don't want to have the vpn client use the dns on the place they are vpn'ing too?
So I split tunnel, and only route specific segments down my vpn. But when I connect to the vpn I use the dns at my vpn location so I can resolve the domain there and all local hosts at the vpn location. This allows me to still resolve public stuff, but does prevent me from resolving local stuff on the vpn client side.
I still wouldn't put rfc1918 in public space.. If you want your road warriors to resolve your vpn server side stuff, but not use the dns there - have them use a host file ;)
I think you're assuming this is intentional and planned… I suspect its more of an accidental outcome from poor design.
The hosts file is workable on the small scale, but managing large deployments could be fun. Personally the chap should move to something better for VPN access and stop patching symptoms.
-
WTF is this shit? Dude, unless you are running some DNSBL or something in 127/8 range, this crap has nothing to do in public space. WTF.
-
WTF is this shit? Dude, unless you are running some DNSBL or something in 127/8 range, this crap has nothing to do in public space. WTF.
I agree - and I said that in the initial problem statement. Mostly this forum post is to help anyone else who finds DNS weirdness.
Also, I agree that this was a symptom of poor design, rather than a root problem.
