Localhost view is not working for me
Bob Harold
rharolde at umich.edu
Mon Mar 30 18:42:01 UTC 2020
Try without the "match-destinations". Only use match-clients to determine
the view. (Or try only match-destinations as a separate test.)
(I have never used match-destinations.)
Turn on query logging and see what source and destination your queries are
using. Make fake queries to unique names just to be sure which queries you
are looking at.
That's the best that I can suggest.
--
Bob Harold
On Mon, Mar 30, 2020 at 1:07 PM Marc Chamberlin via bind-users <
bind-users at lists.isc.org> wrote:
> Hello - I am running the Bind server
>
> > named -v
> BIND 9.11.2 <id:0a2b929>
>
> under OpenSuSE Leap 15.0. In order to support other servers running on the
> same system that my Bind server is running on I am trying to set up 3
> views, one for the localhost, one for my internal network to use, and one
> for the external Internet. (yes this is also a gateway system with 2 NIC
> cards.) What I am having troubles with is getting the localhost view to
> work properly. I have tried a number of ways to get this to work and will
> show the apropos segment of my named.conf file below. Commented out
> sections show things I have tried already but rejected because the results
> I get from queries, from other servers on this gateway/localhost system,
> that are not what I want. For example if I use the definition in with
> localhost is defined, rather than 127.0.0.1, I will get results that are
> defined by my internal view which is not acceptable. If I use 127.0.0.1
> instead, lookup query results from/for the other servers running on my
> gateway/localhost fail completely with no results returned. I don't
> understand why 127.0.0.1 fails, it seems like this should be the proper way
> to limit the scope of localhost queries so that they are answered by
> definitions defined in my "localhost_resolver" view. What am I missing?
> How to I set up the "localhost_resolver" view so that it will answer
> queries from localhost without falling through to my "internal" view?
> (The keys are also necessary to restrict certain types of queries but I
> tried not using them and got the same inadequate responses to queries from
> the localhost.)
>
> I have also used dig to show exactly what view was answering queries from
> localhost and it verified that the queries were indeed being answered by my
> internal view when I used localhost in the match-clients and
> match-destinations statements. If necessary I can post other files, such
> as the local_zones.conf or some of the domain definition files themselves
> but will have to edit them to remove actual URLs and other sensitive
> information. I checked the log files also, after setting the debug level
> to 10, and the Bind server reports no errors or warnings when it is started
> up. Thanks for any help offered, and below is what I think is the relevant
> part of my named.conf file.
>
> Marc....
>
> view "localhost_resolver"
> {
> // match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localhost; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localhost; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 127.0.0.1; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 127.0.0.1; };
>
> // match-clients { 127.0.0.1; };
> // match-destinations { 127.0.0.1; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> zone "localhost" in {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> allow-update { none; };
> };
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" in
> {
> type master;
> file "127.0.0.zone";
> };
> include "/etc/named.d/local/local_zones.conf";
> };
>
> view "internal" { // What the home network will see
> // match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; localnets; localhost; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; localnets; localhost; };
>
> // match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
>
> // match-clients { 192.168.10.0/24; };
> // match-destinations { 192.168.10.0/24; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> include "/etc/named.d/internal/internal_zones.conf";
> };
>
> view "external" { // What the Internet will see
> match-clients { any; };
> match-destinations { any; };
> recursion no;
> include "/etc/named.d/external/external_zones.conf";
> };
>
>
>
> --
>
> --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-.
>
>
>
>
>
> *Computers: the final frontier. These are the voyages of the user Marc.
> His mission: to explore strange new hardware. To seek out new software and
> new applications. To boldly go where no Marc has gone before! *
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200330/0a7187a7/attachment-0001.htm>
More information about the bind-users
mailing list