Unbound - dns override - resolves on local box , not remote box

bingo600

I have an issue (idea ...)

I want to be able to have a remote client resolve a dns name via local pfs/unbound domain override , querying a remote pfs/unbound , and even have that remote unbound query a MS-DNS via domain override.

I can't
Either because of an unbound limitation (recursion or ??) , or my limited knowledge of unbound "trickery".

TLDR ...

I have 6 sites in my lab setup , 1 central + 5 remote(s).
All uses pfsense 2.4.5-p1 , and all have OpenVPN L2L connections w. TLS + Cert. Connectivity is excellent , routing + "site inter routing" works 100% fine.

All sites have their own domain name , and all sites uses unbound for DNS resolving. pfSense/Unbound is set to use Cisco Umbrella as DNS forwarders , no 127.0.0.1 resolving (Corp req.).

Local pfSense (site dhcp) is handing out the local domain name , and handing out the local lan interface (pfSense) as dns server. So it's uses the local pfSense/unbound as resolver.

Every site has "local internet exit" , and is "only" routing "Full RFC1918" via L2L to the central site (fw1.fw1lab.local).

In general , I am denying TCP/UDP 53 (PA_DNS - Alias) to "any" , but TFW.
But have allowed it on the OVPN IF (apparently not a part of TFW) , and (for tests) DNS to any on 10.111.66.0/24 (fw2 lan if) , i see no FW blocking anymore.

In fw1 unbound i have allowed (ACL) 10.0.0.0/8 , so every ip used, should be allowed.

I'm testing domain override , as i have a Citrix system that has it's own domainname , and own DC , where all Citrix related stuff is defined.

On fw1.fw1lab.local have defined these domain overrides :

citrix.local  -> 10.110.70.30   (The citrix DC).

And from the local fw1 laptop : l1.fw1lab.local
I can resolve deb01 and deb01.fw1lab.local (defined in unbound) , and
storefront.citrix.local , via domain override to the Citrix DC.

Now i would like the laptop on fw2 , to be able to resolve the same names , but still use fw2 unbound ad the dns.

NO PROBLEMOS i thought ...

I'll just make domain overrides

citrix.local -> 10.110.70.30 (The citrix DC).
fw1lab.local -> 10.101.101.13 (fw1 OVPN IF)

I even got more clever (i think) ... fw1 have domain forward for citrix.local to the Citrix DC. Just forward the fw2 citrix.local queries to fw1 ....

citrix.local -> 10.101.101.13 (fw1 OVPN IF)
fw1lab.local -> 10.101.101.13 (fw1 OVPN IF)

Testing on linux laptop connected to fw2 (l1.fw2lab.local)

DNS just times out , if do a :

host deb01.fw1lab.local

Or

host deb01.fw1lab.local 10.111.66.1   - 66.1 is the local pfS if

DNS works , if do a :

host deb01.fw1lab.local  10.101.101.13  - 101.13 is the fw1 Ovpn IF

I see no fw blocking of DNS , and no rejects in the DNS resolver "GUI" log (i might not have tuned/enabled the right logging for unbound)

As i see it Unbound isn't happy about asking another unbound for an ip address , or i have goofed in the setup under : server:

Do i miss a transparent or local or ??
I'm normally a bind9 guy , and admit not having "close read the unbound doc"

@johnpoz
You are the "Delphi oracle of Unbound"
Any tips/hints ?

I'm not in front of the lab setup.
I might be for a few hours tomorrow , and full thurs/fri.

Others please feel free to chip in too.

TIA
/Bingo

Edit:
Drawing made w. Dia on Linux.
Not Visio ... But not that bad either.
http://dia-installer.de/

I just used synaptic on Mint to instal Dia + Dia-shapes

johnpoz

Before I dive into the info.. your not actually using .local are you?? That is horrible horrible choice of a tld to use..

I would really suggest you use something else..

Take that as a decree from the oracle on high ;) All that use .local will be smitted with horrible dns issues..

That is a special use for mdns.. I would never in a million years use that.. if you want to use local, put a tld on the end, I use local.lan for example.

bingo600

@johnpoz
FSCK ... Yes i am
I had a feeling it was "bad" , a "Corp suggestion".

SIGH ...

/Bingo

johnpoz

HORRIBLE CHOICE!!

Keep in mind that whenever unbound goes to ask some other NS.. If rfc1918 is a response, that would be a rebind..

So any domains your using need to be set as private, if your going to go ask something other than unbounds local resources.

So unbound 1 asking unbound 2, if the answer back is rfc1918 - that would be rebind and you need to make sure that unbound one knows that so its ok with rfc1918 being an answer.

bingo600

@johnpoz

I know ....

But i don't think i have much choice now , where Citrix + many ESXi VM's are using .local. Those are set up by ext. consultants , and would be $$$ to change.

I'll give

private-domain: "fw1lab.local"
private-domain: "citrix.local"

A shot (would that be on fw1 or the remote fw2 ?) , and get back .. Might first be thurs.

If i ever meet the Oracle .. I'll owe a beer or 2.

Edit:
If it's just missing the private ...
Why does it work when i query the fw1 directly via host <name> <server-ip> ?
fw1 is still returning an RFC1918 answer.

In my (confused mind) putting private on fw2 , would make more sense.
As in telling unbound of fw2 , that it is ok to receive an RFC1918 answer for that zone. Well i'm not an unbound Oracle , i just want it to behave

/Bingo

johnpoz

You would need to put private on the unbound that is going to go ask something else.. So if 1 asks 2 for A, and 2 asks 1 for B.. A would be on 1 as private, and B would be on 2 for private.

You directly ask 1 for something that 2 answers - if that works, but client doesn't work and its pointing to 1.. That issue is pretty much related to use of .local.

I would have to refresh read the RFC.. but pretty sure there is something clients do where anything.local has to be asked via mdns.. So you could be running into an issue where unbound never actually gets asked by the client.

Again - HORRIBLE CHOICE for domain choice..

Client might just think that .local is not answering, etc.. Clients can and do send out requests for what domain they should use to query, etc..

So maybe the clients says nope didn't get anything back without even asking unbound 1 or unbound 2, etc.

Lots weird shit that goes on with that .local mess.. And the discovery process for it is horrible - and depending on your devices you can not turn it off..

bingo600

@johnpoz said in Unbound - dns override - resolves on local box , not remote box:

Again - HORRIBLE CHOICE for domain choice..

I don't disagree here , but i doubt i'll get the $$ to fix it, on the already installed servers.

I'll put private in both , and run some tests.

Thanx for taking your time

Ps: If you ever need a poor mans Visio (or on linux) - Dia isn't that bad.
See 1'st post

/Bingo

johnpoz

mdns is really meant to be local only... So if you directly query unbound 1 for whatever.something.local that goes and asks unbound 2.. And that works.

But clients are not resolving it - then look to the clients and make sure they are actually doing a directed query towards unbound 1.

bingo600

@johnpoz

Queries local on fw1 (where the dns stuff is defined) works out of the box , also the citrix.local stuff on the MS-DC (DNS) , when domain override is made for these domains pointing to the DC.

Queries "local - via unbound" on fw2 w. domain override pointing at fw1 (that resolves fine locally) , doesn't work (yet ...)

Queries from a linux pc on fw2 - but specifying the Ovpn IF on fw1 as dns server works.

So it seems that FW1 is happy to resolve ....

But if the query goes laptop -> unbound/fw2 -> unbound/fw1 i get err.
Could be unbound/fw2 that does not like the RFC1918 ansver , as you mentioned.

Will test asap

johnpoz

You can enable rfc1918 to be a viable answer either with private domain settings in unbound. Or you can just disable all of rebind protection..

I would go the the specific domain route.

bingo600

@johnpoz said in Unbound - dns override - resolves on local box , not remote box:

I would go the the specific domain route.

#Me to

Just dropping those 2 lines in every unbound is no prob.

On my home setup where i had an existing linux based DHCP + DNS infrastructure.
I only use unbound to forward to my (existing Bind9 servers) , no pfS 127.0.0.1 resolving. All that hits unbound goes to the Bind9's.

My Phone + MMedia vlans gets a DHCP DNS pointing to a Debian Pihole , that uses the Bind9's.

DNS & especially DHCP is a bit more cumbersome on linux , but i have DDNS (DHCP added entries) working like a charm. And that is s super neat feature.

I have this defined on my home pfS:

server:
private-domain: "mydomain.org"
local-zone: "xxx.10.in-addr.arpa." transparent 
local-zone: "yyy.10.in-addr.arpa." transparent

I made that when i was a pfSense "super noob" , and could resolve nothing RFC1918 via my bind9 servers.

I have no idea if the arpa zone should be transaparent or just local.
Google gave me this suggestion , and it has worked since.

Sometimes i promise my self to find out why i have transparent ... And then i postpone again ...

Well i had to now ...

From:
https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/

transparent
If there is a match from local data, the query is answered.
Otherwise if the query has a different name, the query is re-
solved normally. If the query is for a name given in local-
data but no such type of data is given in localdata, then a
noerror nodata answer is returned. If no local-zone is given
local-data causes a transparent zone to be created by de-
fault.

nodefault
Used to turn off default contents for AS112 zones. The other
types also turn off default contents for the zone. The 'node-
fault' option has no other effect than turning off default
contents for the given zone. Use nodefault if you use ex-
actly that zone, if you want to use a subzone, use transpar-
ent.

Seems like transparent is the way to go for me (sub zones)

/Bingo