<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello - I am running the Bind server <br>
</p>
<p>> named -v<br>
BIND 9.11.2 <id:0a2b929><br>
</p>
<p>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.) <br>
</p>
<p>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.</p>
<p> Marc....<br>
</p>
<p>
<blockquote type="cite">view "localhost_resolver"<br>
{<br>
// match-clients { ! key letsencrypt.; ! key
rndc-key.; ! key letsencrypt_amcrest.; localhost; };<br>
// match-destinations { ! key letsencrypt.; ! key
rndc-key.; ! key letsencrypt_amcrest.; localhost; };<br>
<br>
match-clients { ! key letsencrypt.; ! key
rndc-key.; ! key letsencrypt_amcrest.; 127.0.0.1; };<br>
match-destinations { ! key letsencrypt.; ! key
rndc-key.; ! key letsencrypt_amcrest.; 127.0.0.1; };<br>
<br>
// match-clients { 127.0.0.1; };<br>
// match-destinations { 127.0.0.1; };<br>
<br>
recursion yes;<br>
zone "." in {<br>
type hint;<br>
file "root.hint";<br>
};<br>
zone "localhost" in {<br>
type master;<br>
file "localhost.zone";<br>
allow-update { none; };<br>
};<br>
zone "0.0.127.in-addr.arpa" in {<br>
type master;<br>
file "127.0.0.zone";<br>
allow-update { none; };<br>
};<br>
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 {<br>
type master;<br>
file "127.0.0.zone";<br>
};<br>
include "/etc/named.d/local/local_zones.conf";<br>
};<br>
<br>
view "internal" { // What the home network will see<br>
// match-clients { ! key letsencrypt.; ! key
rndc-key.; ! key letsencrypt_amcrest.; localnets; localhost; };<br>
// match-destinations { ! key letsencrypt.; ! key
rndc-key.; ! key letsencrypt_amcrest.; localnets; localhost; };<br>
<br>
// match-clients { ! key letsencrypt.; ! key
rndc-key.; ! key letsencrypt_amcrest.; 192.168.10.0/24;
127.0.0.1; };<br>
// match-destinations { ! key letsencrypt.; ! key
rndc-key.; ! key letsencrypt_amcrest.; 192.168.10.0/24;
127.0.0.1; };<br>
<br>
match-clients { ! key letsencrypt.; ! key rndc-key.;
! key letsencrypt_amcrest.; 192.168.10.0/24; };<br>
match-destinations { ! key letsencrypt.; ! key rndc-key.;
! key letsencrypt_amcrest.; 192.168.10.0/24; };<br>
<br>
// match-clients { 192.168.10.0/24; };<br>
// match-destinations { 192.168.10.0/24; };<br>
<br>
recursion yes;<br>
zone "." in {<br>
type hint;<br>
file "root.hint";<br>
};<br>
include "/etc/named.d/internal/internal_zones.conf";<br>
};<br>
</blockquote>
<blockquote type="cite">view "external" { // What the Internet
will see<br>
match-clients { any; };<br>
match-destinations { any; };<br>
recursion no;<br>
include "/etc/named.d/external/external_zones.conf"; <br>
};<br>
</blockquote>
<br>
</p>
<p><br>
</p>
<div class="moz-signature">-- <br>
<pre> --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-. </pre>
<br>
<b>Computers: the final frontier. These are the voyages of the
user Marc.<br>
His mission: to explore strange new hardware. To seek out new
software and new applications.<br>
To boldly go where no Marc has gone before!<br>
</b></div>
</body>
</html>