unbound behind NAT: Unbound must forward to a more capable name server

Ron Varburg ronvarburg at yahoo.com
Thu Nov 28 12:38:41 UTC 2019


 My understanding is that unbound can not do fully-recursive resolves.
It requires a name server that is able to query the root name servers,
then the 2nd tire name servers, and so on, to forward queries to.
That is, anything that it can not answer out of its cache or local data
must be forwarded to another, more capable, name server.     On Wednesday, November 27, 2019, 10:30:57 PM GMT, Felipe Gasper <felipe at felipegasper.com> wrote:  
 
 The stub zone options won’t work; I still need a fully-recursive query in order to verify that the zone’s DNS is set up correctly. I think the same problem would apply to forward zones.

-F

> Le 27 nov. 2019 à 07:33, Ron Varburg via Unbound-users <unbound-users at nlnetlabs.nl> a écrit :
> 
> Do you want unbound to do the following
> 
> if (querying for *.example.com)
> then query name server at IP1
> else query name server at IP2
> 
> ?
> If so, have you looked at the "Stub Zone Options" and "Forward Zone Options"
> of unbound.conf.5?
> On Wednesday, November 27, 2019, 11:11:56 AM GMT, Felipe Gasper <felipe at felipegasper.com> wrote:
> 
> 
> 
> > Le 27 nov. 2019 à 05:58, Ron Varburg via Unbound-users <unbound-users at nlnetlabs.nl> a écrit :
> > 
> > Would you like all queries, no matter what, to be forwarded to 10.0.1.20?
> > If not all queries, by which criteria do you decide what should be forwarded to 10.0.1.20 and what not?
> 
> No, only those that would otherwise go to the local server’s public IP.
> 
> For example, let’s say our server authoritatively hosts DNS for a domain “example.com”. Unbound will query the root servers, which will direct us to “.com”’s TLD servers. Then Unbound will query those TLD servers, which will direct us to 11.22.33.44, the server’s public IP. Unbound will then try to query 11.22.33.44, which fails because this particular server is behind a NAT that forbids access to the public IP.
> 
> Previously we used a custom-written resolver to do such queries, so translating from public to private IPs was simple. Now that we’ve switched to Unbound, we either have to enable loopback NAT on all servers--which is problematic because we don’t always control the whole environment--or find some way to implement that public-to-private translation in Unbound.
> 
> > Have you currently a working unbound server? If yes, can you post its configuration?
> > Is it running at 10.0.1.20?
> 
> We don’t actually run Unbound as a service; we only use the resolver library (in its default configuration).
> 
> Thank you!
> 
> -FG
> 
> 
> > On Wednesday, November 27, 2019, 10:35:17 AM GMT, Felipe Gasper <felipe at felipegasper.com> wrote:
> > 
> > 
> > Hello,
> > 
> >    What I’d like is for any query that would otherwise go to “11.22.33.44” (i.e., the public IP) to go to “10.0.1.200” (the private IP) instead.
> > 
> >    Thank you!
> > 
> > -FG
> > 
> > > Le 27 nov. 2019 à 03:03, Ron Varburg via Unbound-users <unbound-users at nlnetlabs.nl <mailto:unbound-users at nlnetlabs.nl>> a écrit :
> > > 
> > > I couldn't understand what exactly are you asking for. Referring to your example,
> > > when would you like to forward queries to 11.22.33.44, and when to 10.0.1.200?
> > > On Tuesday, November 26, 2019, 5:36:00 PM GMT, Felipe Gasper via Unbound-users <unbound-users at nlnetlabs.nl <mailto:unbound-users at nlnetlabs.nl>> wrote:
> 
> > > 
> > > 
> > > Hello,
> > > 
> > >    Is it possible to give unbound a lookup of public-to-local IP addresses so that it can work with non-loopback NAT setups?
> > > 
> > >    We have domains whose DNS is hosted from behind the same NAT where unbound runs. Currently we don’t know of a way for unbound to resolve queries to these domains unless the server has loopback NAT set up, which many do not.
> > > 
> > >    Ideally, we’d like for there to be a way to tell unbound that instead of resolving against, e.g., 11.22.33.44, to send the same query to a private address like 10.0.1.200 instead.
> > > 
> > >    Thank you!
> > > 
> > > -FG
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20191128/8da43aa9/attachment.htm>


More information about the Unbound-users mailing list