Thank you. I got the key exchanges working ok.

I can run actual DNS queries from the machine that is running unbound when I specify my resolver to query localhost, backend IP or the WAN IP.

Similarly, on the other machine on my LAN, I can run DNS queries to the unbound machine across the backend or by querying the WAN address.

However unbound-control is only able to get status if I run it on the WAN IP. But attempts at remote control on the backend IP fail on the backend IP. I thought it was a firewall issue, but unbound-control fails even locally when I query the backend IP, as well as from the remote machine on the LAN. I had opened up port 8953 to all transports on all interfaces.

Is there a setting in unbound.conf *on* the machine that is running unbound to specify what interface it should listen for remote control connections?


On Mon, 23 May 2016, W.C.A. Wijngaards via Unbound-users wrote:

Hi Fongaboo,

On 21/05/16 00:30, Fongaboo via Unbound-users wrote:

I have (the stock*) Unbound running on FreeBSD 10. I have
unbound-control setup on the Unbound server itself and am successfully
controlling via localhost.

But I have another machine connected to the server via a backend
connection on the 10.x.x.x private network. I want to run
unbound-control on that machine and control the remote (albeit one
backend hop away) server.

I've been looking at docs and tutorials, and it's not clear what has to
be configured where for this scenario.

I've run unbound-control on the remote client and it complains that I
have no unbound.conf file. But is that file ONLY for the configuration
of a server? Would I need to have an unbound.conf file on the client
machine?

A couple things are not clear to me... Do I run unbound-control-setup on
the client machine? I assume I'd have to copy keys to the server? But if
so, how do I store them and refer to them without breaking my localhost
control for unbound-control on the server itself?

I tried adding 'control-interface: <server backend IP>' to the
remote-control section of unbound.conf on the server. I interpreted this
to be that it should listen for control connections on that interface.
But I got:

[1463783089] unbound-control[83533:0] error: connect: Connection refused
for <server IP>


I suppose I might have some firewall concerns. But before I go off on
that tangent, I'd just like to get straight:

1) Do I run unbound-control on the client machine?

Yes with -c some_other_config_file that has the appropriate settings.

2) What should I have in unbound.conf on the client machine (if at all)?

That some_other_config_file has a remote-control section.  The
control-interface there specifies the ip-address of the server machine
that it controls.  Then you need the cert and pem files, (but not the
private server key file).  Copy those files from the server machine to
some location on the client.  Set the pathnames correct for those 3
files (server cert, client pem, client cert).

3) What should I have in unbound.conf on the server?
4) What key exchanging and referencing (in config files) do I need to
keep control with unbound-control going on both the remote client and
localhost?

If you copy the files you can have any number of controlling clients.

(It is possible to sign a separate certificate for every controlling
client, i.e. this is PKIX cert stuff; but you can also just copy the
client cert that the localhost on the server was using).  If you want to
create more client certs; move away the client certs and re-run
unbound-control-setup; that will preserve the server cert and
re-generate a new client cert for you; creating a new one.

Best regards, Wouter


TIA



 -------------------------------------------------------------------------
 shot through the heart              ooh baby do you know what that's worth
 and you're to blame                         ooh heaven is a place on earth
 darling you give love                  they say in heaven love comes first
 a bad name                              we'll make heaven a place on earth
 ORBITAL                                                     "Halcyon Live"



Reply via email to