reverse lookup for RFC1918 in view failed

[Tony Finch]

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.