RE: 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  On Behalf Of Tony Finch
Sent: Sunday, June 6, 2021 10:54 PM
To: MAYER Hans 
Cc: bind-users@lists.isc.org
Subject: Re: reverse lookup for RFC1918 in view failed 

MAYER Hans  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.finchhttps://dotat.at/ Plymouth, Biscay: 
Variable 2 to 4. Slight or moderate. Mainly fair.
Moderate or good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: reverse lookup for RFC1918 in view failed

[Tony Finch]

MAYER Hans  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.finchhttps://dotat.at/
Plymouth, Biscay: Variable 2 to 4. Slight or moderate. Mainly fair.
Moderate or good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

reverse lookup for RFC1918 in view failed

[MAYER Hans]

Dear All,

I have a strange behaviour which I can’t explain. So I am asking for help.
In my named.conf I have two views. One view is called „intern“ ( German 
internally ) and the other is called „fueralle“ ( German "for everyone" )
In the internal view I have a response-policy with two zones, a „drop“ zone and 
a „passthru“ zone where I rewrite some IP addresses for internal use. The 
"match-clients“ definition is defined with „lokal“ which is the local IPv4 
address range 192.168.0.0/16  and the public IPv6 address but no loopback, 
either IPv6 or IPv4.
The "for everyone“ zone has everything else. It has the domain name as master 
and some others as slave and also "168.192.IN-ADDR.ARPA“ ; match-clients is 
defined with „any“
The server is physically located in network 192.168.0.0 and reachable from the 
world via NAT and has also a public available IPv6 address.

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“
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. 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“.

If I remove the views it works as I would expect.

I am using BIND 9.16.16 (Stable Release)  running on Linux x86_64 
4.19.0-16-amd64

Any help is welcome.


Kind regards
Hans

--

Ing. Dipl.-Ing. Hans Mayer
Systems Analyst
Network Unix Security Team (NUST)
Information and Communication Technologies (ICT)

International Institute for Applied Systems Analysis (IIASA)
Schlossplatz 1
A-2361 Laxenburg, Austria
Phone: +43 2236 807 Ext 215
Mobile: +43 676 83 807 215
Web: http://www.iiasa.ac.at
E-Mail: hans.ma...@iiasa.at

Note: If there is a disclaimer or other legal boilerplate in the above message, 
it is NULL AND VOID.  You may ignore it.





On 01.06.2021, at 17:31, Anand Buddhdev 
mailto:ana...@ripe.net>> wrote:

On 01/06/2021 17:18, Cuttler, Brian R (HEALTH) via bind-users wrote:

Hi Brian,

From what I'm reading I should be sending a notify from the primary
to the secondary when a dynamic zone is updated but I don't seem to be
doing that.

Would someone please point me to the option I'm missing to do so?
I've either completely missed it, mis-understood what I read or am going in
the wrong direction.

You need an "also-notify" option for that zone. Read more about this in
the BIND documentation:

https://bind9.readthedocs.io/en/v9_16_16/reference.html#zone-transfers

While this documentation refers to the latest stable version of BIND, it
should still apply to the older version you're using.

Regards,
Anand
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users