VRF support in unbound?

krad kraduk at gmail.com
Sat Jan 5 17:46:20 UTC 2019


This feels overly complicated  Would it not better to have a special shared
service vrf that all other vrfs, have a routing policy into for the
relevant traffic. The unbound  setup could then be fairly simple, rather
than trying to manifest it in multiple places. You can also use this setup
for any other shared services.

On Sat, 5 Jan 2019, 10:56 Ralf Jung via Unbound-users <
unbound-users at nlnetlabs.nl wrote:

> Hi,
>
> > Not sure what your goal is, but would it not be easier to work with
> network namespaces instead of VRF ?
>
> I could probably use `ip vrf exec` to put unbound fully inside the VRF,
> and have
> the same effect as a network namespace.
> But what I want to happen is that outgoing queries are made via the
> default VRF
> on erh0, while the same daemon also replies to queries from the intranet
> in the
> other VRF.  AFAIK such cross-VRF operation is not possible with network
> namespaces.
>
> Kind regards,
> Ralf
>
> >
> > Just like containers do ?
> >
> > With kind regards,
> >  Leen.
> >  Just an other Unbound user.
> >
> > On Fri, Jan 04, 2019 at 02:00:31PM +0100, Ralf Jung via Unbound-users
> wrote:
> >> Hi again,
> >>
> >> I should probably give some more details about my configuration...
> currently, I
> >> am playing with
> >>
> >>>     interface: 0.0.0.0
> >>>     interface: ::
> >>>     access-control: 10.24.192.0/18 allow
> >>>     access-control: fd4e:f2d7:88d2:ffff::/64 allow
> >>>     ip-freebind: yes
> >>>     interface-automatic: yes
> >>>     outgoing-interface: 82.165.162.239
> >>
> >> When a request now comes in from the 10.24.192.0/18 subnet (which is
> in the
> >> VRF), I can see via tcpdump that unbound sends requests to an
> authoritative DNS
> >> server to resolve this request.  However, the response to the original
> client
> >> never goes out.
> >> Via TCP, the request actually works and a response is sent out
> correctly!
> >>
> >> However, all of this is for IPv4 only, and only when I have set
> >> net.ipv4.{tcp,udp}_l3mdev_accept=1.  For IPv6 and without that setting
> (which
> >> doesn't seem to exist for IPv6), unbound does not even seem to receive
> the
> >> request, there is no reaction in the form of messages to the
> authoritative DNS.
> >>
> >> Kind regards,
> >> Ralf
> >>
> >> On 04.01.19 13:24, Ralf Jung via Unbound-users wrote:
> >>> Hi all,
> >>>
> >>> I am playing around with the [VRF] support on the Linux kernel, and
> got basic
> >>> routing and address assignment to work for IPv4 and IPv6.  The next
> step,
> >>> obviously, is to get DNS, and here I am running into the following
> error in unbound:
> >>>
> >>>> unbound[3115]: [3115:0] error: can't bind socket: Cannot assign
> requested address for 2a03:2260:3009::2
> >>>
> >>> This is the expected error when an application does not use setsockopt
> for
> >>> SO_BINDTODEVICE to configure the device on which the address is to be
> bound.
> >>>
> >>> Is there any way to tell unbound to bind to a particular device (and
> not just a
> >>> particular address)?  The only options I found for configuring unbound
> allow
> >>> giving IP addresses to bind to, but there seems to be no way to also
> configure
> >>> the network device to use.
> >>>
> >>> [VRF]: https://www.kernel.org/doc/Documentation/networking/vrf.txt
> >>>
> >>> Kind regards,
> >>> Ralf
> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190105/27823fbf/attachment.htm>


More information about the Unbound-users mailing list