newbie question: Allowing recursion

Unbound
1

New unbound user here, recent arrival after many years with bind.

Attempts at a recursive lookup fail against an unbound server, even though unbound.conf explicitly allows this from one particular client. I searched the archive and didn't find an answer, but I may have missed something.

A dig query against this server returns "recursion requested but not available". There are no firewalls blocking traffic between client and server. Running tcpdump on the server shows the query coming in and the server rejecting it.

The server uses the Unbound v. 1.16.3 as supplied in OpenBSD 7.2 and has these IP addresses:

149.28.38.111

2001:19f0:c:1055:5400:4ff:fe4c:d46a

The client also runs OpenBSD 7.2 and has these IP addresses:

144.202.0.40

2001:19f0:c:75b:471f:a26a:c6f2:77bd

The server's full unbound.conf is pasted below, but these are the relevant bits:

server:
root-hints: "/var/unbound/db/root.hints"
#qname-minimisation: yes
interface: 0.0.0.0
interface: ::0
do-ip6: yes

     access\-control: 0\.0\.0\.0/0 refuse

..

     access\-control: 144\.202\.0\.40/32 allow
     access\-control: 2001:19f0:c:75b::/64 allow

Shouldn't the server allow a recursive query from this client? If not, what's missing? Thanks!

dn

full unbound.conf:

# $OpenBSD: unbound.conf,v 1.21 2020/10/28 11:35:58 sthen Exp $

server:
root-hints: "/var/unbound/db/root.hints"
#qname-minimisation: yes
interface: 0.0.0.0
#interface: 127.0.0.1@5353 # listen on alternative port
interface: ::0
do-ip6: yes

 \# override the default "any" address to send queries; if multiple
 \# addresses are available, they are used randomly to counter spoofing
 \#outgoing\-interface: 192\.0\.2\.1
 \#outgoing\-interface: 2001:db8::53

 access\-control: 0\.0\.0\.0/0 refuse
 access\-control: 127\.0\.0\.0/8 allow
 access\-control: ::0/0 refuse
 access\-control: ::1 allow

 \# allow recursive queries from this client
 access\-control: 144\.202\.0\.40/32 allow
 access\-control: 2001:19f0:c:75b::/64 allow

 hide\-identity: yes
 hide\-version: yes

 \# Perform DNSSEC validation\.
2

Hi David,

Your configuration should work.
Are you sure that Unbound is seeing that exact client IP address?
If you increase verbosity (4 at least) Unbound will log why the query was refused.

> A dig query against this server returns "recursion requested but not
> available".
I suppose the "status:" of that response is "REFUSED"?

Best regards,
-- Yorgos

3

Hi Yorgos,

Thanks very much. Logging and debugging was a very good idea. It showed that the unbound config is fine, and that the issue is something I neglected to mention: This system also runs NSD as an authoritative-only name server, and NSD had already bound to UDP port 53.

This may be a question for the openbsd-misc list instead, but if anyone here has examples of how to run an authoritative and recursive server on the same box using unbound and NSD please let me know. I previously used bind, which didn't have this issue because one server handled both authoritative and recursive queries.

Thanks again!

dn

4

How about running nsd on a different port and simply forward queries to these zones via unbound?

5

Hi,

(...) if anyone here has examples of how to run an authoritative
and recursive server on the same box using unbound and NSD please
let me know.

Not exactly what you're looking for, and probably not best practice,
but this should be close enough: I'm running both Unbound and BIND
on the same machine, the first one only on IPv4 and the second
one on IPv6.

Then Unbound is configured to use BIND in the IPv6 loopback
interface to get the data for the local zones:

# unbound.conf
interface: 127.0.0.1
interface: 192.168.1.50

stub-zone:
        name: "home.arpa"
        stub-addr: ::1@53
stub-zone:
        name: "168.192.in-addr.arpa"
        stub-addr: ::1@53

# named.conf
options {
        version "restricted";
        directory "/srv/named";
        recursion no;
        listen-on { none; };
        listen-on-v6 { any; };
};

I'm assuming that you could get something similar with NSD.

Sincerely,

6

Simple answer: don't.

If this is publicly available dns server which is visible to internet
you absolutely don't want to run authoritative and resolving dns
servers on same ip.

If this is home network, solution is to move nsd to other port and add
stub zone configs for unbound so it queries nsd.

7

Hi Yorgos,

Thanks very much. Logging and debugging was a very good idea. It
showed that the unbound config is fine, and that the issue is
something I neglected to mention: This system also runs NSD as an
authoritative-only name server, and NSD had already bound to UDP port
53.

This may be a question for the openbsd-misc list instead, but if
anyone here has examples of how to run an authoritative and recursive
server on the same box using unbound and NSD please let me know. I
previously used bind, which didn't have this issue because one server
handled both authoritative and recursive queries.

Simple answer: don't.

I must humbly, but strongly disagree. If this is setup appropriately
there should be no concern for accomplishing the OP's intended task.

To the OP;
This is the blanket knee-jerk response to this question. Not unlike
stating "you should never log in/become root". It is not up to others
to determine your security policy; as they have no idea of your
working environment/practices/intentions.

That said; it should work just fine to run your recursor on localhost/127.0.0.1/::1
or use whitelist policy for those you intend to permit recursion (an "allow" list)
within an ACL stanza/config-block. This will allow you and your "seconds" recusion
or transfer as needed. While protecting your recursor from abuse.

HTH

8

Hi Yorgos,

Thanks very much. Logging and debugging was a very good idea. It
showed that the unbound config is fine, and that the issue is
something I neglected to mention: This system also runs NSD as an
authoritative-only name server, and NSD had already bound to UDP port
53.

This may be a question for the openbsd-misc list instead, but if
anyone here has examples of how to run an authoritative and recursive
server on the same box using unbound and NSD please let me know. I
previously used bind, which didn't have this issue because one server
handled both authoritative and recursive queries.

Simple answer: don't.

I must humbly, but strongly disagree. If this is setup appropriately
there should be no concern for accomplishing the OP's intended task.

Thanks - this is exactly the intended task. I am a recent convert from bind looking to do two things:

- provide authoritative name service for a few domains (NSD does this now)

- provide recursive, caching, forwarding name service for a few specified hosts (having trouble with Unbound doing this on the same host)

To the OP;
This is the blanket knee-jerk response to this question. Not unlike
stating "you should never log in/become root". It is not up to others
to determine your security policy; as they have no idea of your
working environment/practices/intentions.

That said; it should work just fine to run your recursor on localhost/127.0.0.1/::1
or use whitelist policy for those you intend to permit recursion (an "allow" list)
within an ACL stanza/config-block. This will allow you and your "seconds" recusion
or transfer as needed. While protecting your recursor from abuse.

With unbound.conf configured to listen on 127.0.0.1/::1, recursion works fine on the localhost. Where I'm stuck is providing recursion to other hosts, even if they are on an "allow" list. NSD and Unbound cannot both be bound to port 53 on the same interface. Do I really need two hosts here?

I appreciate Xavier Belanger's suggestion of running each service in a different address family, one in IPv4 and the other in IPv6, but that's not an option for me as some of my hosts are v4 only. And I like Uwe Werler's suggestion about running nsd on a different port and forwarding queries via unbound, but haven't found examples on how that would work, and also wonder if the "aa" flag would be set for authoritative queries since clients wouldn't talk directly to NSD.

The examples I have found run Unbound and NSD on different addresses. Is there some other way of running them on the same machine? Thanks again.

dn

This is OpenBSD, which doesn't support jails AFAIK. I could run a different interface with a private interface address, but am unclear how that would work in practice.

9

With unbound.conf configured to listen on 127.0.0.1/::1, recursion
works fine on the localhost. Where I'm stuck is providing recursion to
other hosts, even if they are on an "allow" list. NSD and Unbound
cannot both be bound to port 53 on the same interface. Do I really
need two hosts here?

That would be the straight-forward and in some ways the simplest
way to deal with it.

An alternative method could be that you could assign one or two
"service" addresses and configure them on your loopback interface
as aliases, arrange routing so that those addresses are routed to
your host, and have unbound and nsd listen on different service
addresses.

Regards,

- Håvard