Set unbound to reply more smarter to firewall's own domain

sebastiannielsen

Currently, I have named my firewall a specific domain, call this "fw.example.org".
Then I have 4 internal non-wan interfaces: LAN, SERVER, WIRELESS, VPNSERVER

Querying "fw.example.org" will return the LAN interface IP's, regardless of if the query is made from LAN, SERVER, WIRELESS or VPNSERVER.
Eg, lets say LAN=192.168.1.1, SERVER=192.168.2.1, WIRELESS=192.168.3.1, VPNSERVER=192.168.4.1
Querying fw.example.org from a client connected to the wireless AP that is hooked up to 192.168.3.1 interface, will still return 192.168.1.1

How can I configure this, to reply more smart to the firewall's own domain, by "sensing" where the request came in, and reply with the IP of the interface where the request arrived, so a request that arrived on WIRELESS will get a 192.168.3.1 reply on querying fw.example.org, and a request that arrives on SERVER will get 192.168.2.1 as reply on fw.example.org and so on.

Since theres a advanced option entry, it must be possible to configure it this way.

johnpoz

I can tell you the simple solution would be to use sub domains for your different networks.

So your example.org can be your lan, so fw.example.org would be 192.168.1.1

Then create host overrides for your other networks

srv.example.org
wifi.example.org
vpn.example.org

Use those as your search suffix for your different networks. Then youw ould have say your overrides like

fw.srv.example.org 192.168.2.1
fw.wifi.example.org 192.168.3.1

etc..

Or you could run bind that allows you do actual views so depending on where the source query came from you can provide your different answers so that would do exactly what you want where you get fw.example.org to resolve to the IP in that network.

I would have to dig a bit deeper to see if dnsmasq or unbound can be setup with advanced stuff to give a specific answer based upon source of the query. But the simple solution I use on my home network is just example I gave above..

so for example

C:>dig pfsense.local.lan +short
192.168.9.253

C:>dig pfsense.dmz.local.lan +short
192.168.3.253

C:>dig pfsense.wlan.local.lan +short
192.168.2.253

edit: Ok let me do some testing, it seems dnsmasq supports a localise-queries function… Which could be used to resolve an IP that is in the same network that the query came from

-y, --localise-queries

Return answers to DNS queries from /etc/hosts which depend on the interface over which the query was received. If a name in /etc/hosts has more than one address associated with it, and at least one of those addresses is on the same subnet as the interface to which the query was sent, then return only the address(es) on that subnet. This allows for a server to have multiple addresses in /etc/hosts corresponding to each of its interfaces, and hosts will get the correct address based on which network they are attached to. Currently this facility is limited to IPv4.

Maybe unbound does the same sort of thing?? Would you mind using dnsmasq vs unbound? Oh you didn't say which you were using but the current default is to use the resolver unbound and not the forwarder dnsmasq in pfsense.

edit: From simple test

localise-queries
host-record=pfsense.local.lan,192.168.2.253

I turned on dnsmasq.. added this to advanced section

When I do a query from my wlan network 192.168.2.0/24 I get back this

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;pfsense.local.lan. IN A

;; ANSWER SECTION:
pfsense.local.lan. 1 IN A 192.168.2.253

;; Query time: 3 msec
;; SERVER: 192.168.2.253#53(192.168.2.253)
;; WHEN: Mon Feb 15 09:59:19 CST 2016

When I do query from my lan, or my remote vpn network I get this

C:>dig pfsense.local.lan

; <<>> DiG 9.10.3 <<>> pfsense.local.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56356
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;pfsense.local.lan. IN A

;; ANSWER SECTION:
pfsense.local.lan. 1 IN A 192.168.9.253

;; Query time: 145 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Mon Feb 15 09:55:16 Central Standard Time 2016
;; MSG SIZE rcvd: 62

So that seems it would do exactly what your asking.

sebastiannielsen

The first solution wouldn't work since I have a wildcard certificate issued.

And didn't you read the thread title? Its pretty clear im using unbound, since I have configured it to do the resolving locally instead of relying on a external DNS server. (for added DNSSEC security), and I don't want to switch to dnsmasq since then I lose all the features of unbound.

johnpoz

What does a wild card cert have to do with what dns resolves – let me think, oh yeah nothing ;)

As to unbound and dnsmasq - yeah my bad on that, but there was another thread with pretty much same question as this and confused the two..

If you are installing a wildcard cert, and you want to resolve your differnet IPs based upon source then you can use bind, which would be my suggestion or you could use dnsmasq vs unbound. I can not seem to find any such solution in unbound.

Other option is you could run multiple instances of unbound on your different networks so it had different records based upon the instance you did the query against. I don't see how you could do this in the pfsense gui.. So would be easier to just install bind and use it.

BIND has dnssec support if that is what your after.. BIND to be honest is way more powerful overall dns product, but unbound is good at what it does which a caching name server never really meant to be an an authoritative name server, etc..

Wish I could help more - but unbound is not going to be able to do what your asking.

sebastiannielsen

about the cert: Since the cert is issued to lets say *.example.org (its just a example), your idea of putting it in different nets like pfsense.wan.example.org and then issuing different search domains wouldnt work, because the cert wouldn't validate, because a wildcard cert is only valid for one domain level down.

Maybe it could work if I have search domain like wan.pfsense, lan.pfsense, wlan.pfsense and such, and then have unbound to resolve like fw.example.org.wan.pfsense, fw.example.org.lan.pfsense and so on. Then the search domain would become invisible to the browser, and thus the certificate would validate, provided that the certAPI does not extend the domain to the search domain. Of course, the base domain "fw.example.org" must not resolve either, because what I understand, it only appends search domain if it fails the lookup without search domain.
Should try that and see if that works.

About BIND, it does not support 0x20 bit security on queries. Also what I can see, it doesn't have possibility to configure DNS rebinding protection, eg tell bind to never return private IPs for public domains.

johnpoz

I know exactly what a wild card cert is - but that has NOTHING to do with dns, nor did you mention it in your post.. Why would you be accessing pfsense from multiple names… Why not just access pfsense.example.org when you hit the gui..

You could always just use different host names pfsense-dmz.example.org, pfsense-wifi.example.org - now your wild cart is still valid..

If bind does not support 0x20, have not looked into that then just forward to unbound to do your public look ups.. Nothing saying that dns has to be run on pfsense, or that pfsense has to do the external queries, etc.. You seem to want your cake and eat it too ;)