reverse lookup for RFC1918 in view failed

[MAYER Hans]

Dear Tony, 

Many thanks for your really very detailed answer. 
I will take a look into details and let you know within the next days.

Kind regards 
Hans 



-----Original Message-----
From: Tony Finch <fanf2 at hermes.cam.ac.uk> On Behalf Of Tony Finch
Sent: Sunday, June 6, 2021 10:54 PM
To: MAYER Hans <Hans.Mayer at iiasa.ac.at>
Cc: bind-users at lists.isc.org
Subject: Re: reverse lookup for RFC1918 in view failed 

MAYER Hans <Hans.Mayer at iiasa.ac.at> wrote:
>

I can see why the behaviour of your server is confusing! I'll explain what is happening in detail below, but here's the basic idea:

Each view in a configuration is separate from the others: `named` first chooses which view to use (based on match-clients etc.) then handles the query purely within that view. If a zone is only configured in one view then that zone configuration will not be used to answer queries that are handled by another view.

By itself, that basic idea isn't enough to explain what's happening with your server, so let's look at the details, then I'll outline some solutions.

> Now the behaviour is the following: When I query from the local IPv6 
> or
> IPv4 network with „dig -x“ for an IP address I get back „status:
> NXDOMAIN“

In this case your query is matching the "intern" view, which doesn't know about your RFC 1918 reverse DNS zone, so it resolves the query using the public DNS, which says NXDOMAIN.

> But when I do the same on the server itself using the loopback 
> addresses for IPv6 or IPv4 it works fine. It also works, if the query 
> comes from the Internet over IPv4 with NAT or with the public IPv6 address.

In these cases your query is reaching the "fueralle" view, which does know about your reverse DNS zone.

> If I query „normal forward“ for an IP with a given name then it works 
> in any case and from every location. This is interesting because the 
> reverse lookup zone and the normal forward zone are both in the same 
> view „fueralle“.

This is where it gets complicated! There are two cases:

When you query your forward zone from an external IP address, or from a loopback IP address, the query is handled by the "fueralle" view, which knows about your forward zone, so it can answer the query.

When you query from an internal IP address, it is handled by the "intern"
view which doesn't know about your forward zone. So it does normal recursive resolution, which (I guess!) eventally tells the server to query itself via the public NAT or IPv6 addresses, so the recursive query is answered by the "fueralle" view.

If you turn on query logging (and if my guess is right) you should see two entries in the query log for this last kind of query, one in the "intern" view, and a matching one in the "fueralle" view.

To make your views behave more consistently, the solution is to make sure that each view knows about all the zones that it needs to.

So your "intern" view should have your forward zone and your RFC 1918 reverse zone, and your "fueralle" view should only have your forward zone (because you don't want to publish a private zone on a public server).

There are a couple of ways to make the forward zone appear in both views.

You can use the "in-view" zone configuration option, which makes this view re-use a zone configuration from another view.

You can continue to rely on the resolver, but that is less reliable because it will not work if/when your network loses external connectivity.

What you must not do is simply copy the same primary or secondary zone configuration into multiple views: if you do that, you will have multiple zone configurations trying to use the same files, and they will conflict with each other.

Tony.
--
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/ Plymouth, Biscay: Variable 2 to 4. Slight or moderate. Mainly fair.
Moderate or good.