New member, maybe old question?

Unbound
1

Hello guys, I need some help about understanding how to do what I need with unbound.

My setup is basically is 2 IPVS (heartbeat + ldirectord) with gate(not masquerade) to 4 servers each.

So I need to setup the IPVS on the servers in their loopbacks so I can use the IP to reply.

No arp allowed, forward allowed as needed.

This setup works w/ Named/Bind. The queries are replied by the IP requested (on the loopback as he’s the IPVS)

But w/ unbound the request address is the IPVS but the reply comes from the real IP on the interface, resulting in:

dig google.com @IPVS
;; reply from unexpected source: REALSERVER#53, expected IPVS#

Searching the archives, from oldest to newest I found this:

http://www.unbound.net/pipermail/unbound-users/2008-January/000003.html

And this:

http://www.unbound.net/pipermail/unbound-users/2012-June/002404.html

I can’t bind to 0.0.0.0 cause bind is running on the other interfaces. This is why I have to use the IPs on the config w/ multiple interface statements.

They are both near what I have atm but not the same.

I get this behavior on 1.4.21-r2 (from Gentoo portage)

If I made any mistake in the config let me know:

erver:
verbosity: 1
interface: REALIP
interface: IPVS1
interface: IPVS2
port: 53
cache-min-ttl: 300
cache-max-ttl: 86400
infra-host-ttl: 900
infra-cache-slabs: 8
infra-cache-numhosts: 100000
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
access-control: MYNETWORK.0/24 allow
username: “unbound”
directory: “/etc/unbound”
logfile: “logs/unbound.log”
use-syslog: no
log-queries: yes
pidfile: “/var/run/unbound.pid”
hide-identity: yes
hide-version: yes
identity: “”
version: “”
harden-short-bufsize: no
harden-large-queries: no
harden-glue: yes
harden-dnssec-stripped: yes
harden-below-nxdomain: no
harden-referral-path: no
use-caps-for-id: yes
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
key-cache-size: 512m
key-cache-slabs: 8
neg-cache-size: 8m
include: “/etc/unbound/local-zone.conf”
python:
remote-control:

2

Hello,

But w/ unbound the request address is the IPVS but the reply comes from the
real IP on the interface, resulting in:

dig google.com @IPVS
;; reply from unexpected source: REALSERVER#53, expected IPVS#

...

If I made any mistake in the config let me know:

erver:
verbosity: 1
interface: REALIP
interface: IPVS1
interface: IPVS2

Have you tested with interface-automatic: yes ?

interface-automatic: yes works for me with keepalived managed vips
(and interface: 0.0.0.0).

-Jarno

3

Yes, I have tested, which returned the message that I sent before:

$ /usr/sbin/unbound -d -c /etc/unbound/unbound.conf
[1401816527] unbound[19141:0] error: bind: address already in use
[1401816527] unbound[19141:0] fatal error: could not open ports

Which makes no sense (interface: 0.0.0.0) since there's nothing already
runinng on 53

4

Hi Filipe,

On Wed, Jun 4, 2014 at 7:17 AM, Jarno Huuskonen
<jarno.huuskonen@uef.fi

Have you tested with interface-automatic: yes ?

interface-automatic: yes works for me with keepalived managed vips
(and interface: 0.0.0.0).

-Jarno

Yes, I have tested, which returned the message that I sent before:

$ /usr/sbin/unbound -d -c /etc/unbound/unbound.conf [1401816527]
unbound[19141:0] error: bind: address already in use [1401816527]
unbound[19141:0] fatal error: could not open ports

Which makes no sense (interface: 0.0.0.0) since there's nothing
already runinng on 53

If you enable interface-automatic, the interface: statements are
ignored, the code uses 0.0.0.0 (and ::0 if ipv6 is enabled), and the
options should make it work. So if there is nothing running, why does
it fail? Use strace? (that shows trace of system calls). Could it be
that ipv4 works but the bind to ::0 for ipv6 somehow fails? This is
controlled with do-ip6.

Best regards,
   Wouter

5

Just installed → http://pastebin.com/R8wLXrX7

Just tried w/ only interface-automatic: yes (no interface: ips) and still same error.

Thanks for the help everyone btw.

6

Hi Filipe,

For me such a trace would end like this (with interface-automatic: yes):
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(5, SOL_IP, IP_MTU_DISCOVER, [0], 4) = 0
bind(5, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0

Notice the SO_REUSEADDR option. The trace you post is missing that.
That must be a #ifdef SO_REUSEADDR that fails at compile time
(services/listen_dnsport.c) ?

In latest code there is a so-reuseport option for linux (very recent
3.9) kernels. This option is really there to distribute queries over
threads more easily, but it may also act like reuseaddr in some ways
that you need.

Also, something else is using port 53 somehow? Or does your system
have secure-linux or something like that that prevents binding to this
port by any old program?

Best regards,
   Wouter

7

I’ll update the kernel to search for that option, running 3.10.10 atm.

Yes I have binds running on another 2 interfaces (that’s one reason for not running 0.0.0.0, the other is: simple configure the only IPs for him to use that he needs only)

8

Well, compiled from source and it worked, thanks for the tip to search for SO_REUSEADDR, it helped me to debug this!

But I still get the same behavior as before, the reply comes w/ ethernet IP not loopback IP.