<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Nick, and all that are interested,<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I tried now RPZ and it seems to work
fine. I will see if it works with all devices as expected the next
weeks.</div>
<div class="moz-cite-prefix">I think that a device that uses a local
resolver that checks DNSSEC will maybe refuse this solution.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Just for other users searching for a
similar setup, I did the following:<br>
Edit /usr/local/etc/namedb/named.conf:</div>
<div class="moz-cite-prefix">options {</div>
<div class="moz-cite-prefix">...</div>
<div class="moz-cite-prefix"> //enable the response policy zone<br>
response-policy {<br>
zone "rpz.local";<br>
};<br>
}</div>
<div class="moz-cite-prefix">logging {<br>
...</div>
<div class="moz-cite-prefix"> channel rpzlog {<br>
file "/var/log/rpz.log" versions unlimited size
100m;<br>
print-time yes;<br>
print-category yes;<br>
print-severity yes;<br>
severity info;<br>
};<br>
category rpz { rpzlog; };<br>
};</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Then I added the new zone to my
/usr/local/etc/namedb/master.zones:<br>
zone "rpz.local" {<br>
type master;<br>
file "/usr/local/etc/namedb/master/db.rpz.local";<br>
allow-query { localhost; };<br>
allow-transfer { localhost; };<br>
};<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Create and empty zonefile:<br>
cd /usr/local/etc/namedb/master</div>
<div class="moz-cite-prefix">cp empty.db db.rpz.local</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Now add to db.rpz.local what you would
like to overwrite like:</div>
<div class="moz-cite-prefix">idefix.fechner.net A 192.168.0.1</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Check configuration is fine:</div>
<div class="moz-cite-prefix">named-checkconf</div>
<div class="moz-cite-prefix">named-checkzone rpz db.rpz.local</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">and restart bind:<br>
service named restart</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Make a tail -F
/var/named/var/log/rpz.log</div>
<div class="moz-cite-prefix">And resolve:<br>
host idefix.fechner.net</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">It gives me now the local address and
adds an entry in the rpz logging.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">So far so good.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks a lot for your help, really
appreciated it!</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Matthias <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Am 07.02.2023 um 09:54 schrieb Nick
Tait via bind-users:<br>
</div>
<blockquote type="cite"
cite="mid:a3df75f3-468e-d09c-4a0c-6974da57ed2d@tait.net.nz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Matthias.</p>
<p>Using a Response Policy Zone on your internal DNS resolver, to
change the answers to DNS queries for your domain from
195.30.95.36 to 192.168.0.1, sounds like the solution that most
closely matches what you've described. Just be aware though, if
you have any internal clients that rely explicitly on DNSSEC
(such as a mail server that needs to apply DANE) then, by
default, those queries (that contain DO=1) won't be rewritten.
(See response-policy option, and in particular the break-dnssec
sub-option for more information.)</p>
<p>Another advantage that RPZ has over split-views, is that you
don't need to maintain a separate duplicate zone file.<br>
</p>
<p>OTOH if the DNSSEC thing is an issue, you may want to look at
other alternatives, including:</p>
<ul>
<li>The split-view thing I mentioned below.</li>
<li>IP-layer network trickery, such as mangle rules (or similar)
so that the internal machines continue to use the public
address, but the packets don't actually get routed out to the
Internet.<br>
</li>
</ul>
<p>Nick.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/02/23 19:45, Matthias Fechner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0529b921-8469-cb42-1f4c-5beeb1145896@fechner.net">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">Hi Darren, Hi Nick,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">at first thanks a lot for your
answer.</div>
<div class="moz-cite-prefix">I see that I have not explained my
use-case detailed enough.</div>
<div class="moz-cite-prefix">I have bind running for domain
fechner.net, but not at home and this server I think is here
completely out of discussion.</div>
<div class="moz-cite-prefix">If I must not touch it, I do not
want to touch it as it would see the traffic from my local
computer from home like any other computer in the internet and
I do not want to open it in any way and it should not know the
setup of my local network at home.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">At home I have a bind running. It
serves some local zones I use here internally and is
forwarding all requests to the DNS server my provider is
providing.</div>
<div class="moz-cite-prefix">It is not connected in any way to
my bind servers running for domain fechner.net.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The public IP address
(idefix.fechner.net) is due to this routing, NAT and openvpn
not visible on any of my interfaces on my home server.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">So if I would like to access
idefix.fechner.net it makes a DNS lookup which returns the A
record for idefix.fechner.net and it sees it does not belong
to my interface so it uses the default gateway to go to my
internet provider. It reaches my server in the internet, is
routed into the openvpn tunnel and goes through my local
firewall through a policy based NAT to a local IP
(192.168.200.x). So you see that is not very efficient.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">My idea was to hook into the DNS
and make sure to not return the IPv4 address 195.30.95.36, but
192.168.0.1 (as all my devices at home are using my local bind
here for lookup).<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I hope that explain it better what
I would like to solve.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Matthias<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Am 07.02.2023 um 07:48 schrieb Nick
Tait via bind-users:<br>
</div>
<blockquote type="cite"
cite="mid:7b9bb264-da7f-1112-9ca7-fb356fc75b47@tait.net.nz">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Hi Matthias.</p>
<p>It isn't clear whether the issue you're trying to solve is
(a) avoiding DNS resolution going out then in to get to your
authoritative servers, or (b) with resolved addresses of
your servers being the public address which means that data
packets sent to/from those servers are going out then in to
get to them?<br>
</p>
<p>It looks like Darren has assumed (a)? If that is correct
then it is worth noting that using forwarders like this will
require your authoritative servers to answer recursive
queries. If that is undesirable, you might want to look at
using "mirror" zones on your recursive resolvers? I haven't
personally used zones of this type, but according to the
documentation, this has following advantage over using
"secondary" zones to achieve the same thing: <i>Answers
coming from a mirror zone look almost exactly like answers
from a zone of type </i><i><code class="docutils literal
notranslate"><span class="pre">secondary</span></code></i><i>,
with the notable exceptions that the AA bit
(“authoritative answer”) is not set, and the AD bit
(“authenticated data”) is.</i></p>
<p>However I suspect your issue is actually (b), in which case
I'd suggest using views to serve two versions of your zone
file - one with public IP addresses that is served to
external clients, and one with private IP addresses that is
served to internal clients only, along the lines of the
following:<br>
</p>
<pre># View containing zone with public IP addresses.
view "public" {
match-clients { ... };
zone "fechner.net" {
type primary;
file "../master/fechner.net/<b>public-</b>fechner.net";
dnssec-policy "one-year-zsk";
inline-signing yes;
};
};
# View containing zone with private IP addresses.
view "private" {
match-clients { ... };
zone "fechner.net" {
type primary;
file "../master/fechner.net/<b>private-</b>fechner.net";
dnssec-policy "one-year-zsk";
inline-signing yes;
};
};
</pre>
<p>The two copies of the zone are signed using the same keys.<br>
</p>
<p>For the sake of simplicity I've glossed over the details of
replicating the two different copies of the zone to your
secondary DNS servers, but the general idea is to have the
secondaries use different TSIG signatures for transferring
each copy, and have the "match-clients" use the TSIG key to
figure out which view they are talking to. Let me know if
you need more info about how to set this up?<br>
</p>
<p>Nick.</p>
<p><br>
</p>
On 6/02/23 01:08, Darren Ankney wrote:<br>
<blockquote type="cite"
cite="mid:CAKabWHhvwJR3fVa-LLXVz9F8eSFz-nV12Cz6_=uRvfn33_HDVA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Matthias,
This is what I did to force my resolver bind instance to lookup my
internal domain directly on my authoritative bind instance without
asking any other servers (would have failed anyway as it is a fake
domain "mylocal"):
// on resolver (or caching name server)
zone "mylocal" {
type forward;
forwarders {
192.168.40.142; // authoritative server 1
192.168.40.182; // authoritative server 2
};
forward only; // don't ask any other server
};
Not sure if that will break dnssec for you. There are probably other
way(s) to accomplish this, especially for a real domain on real IP
address(s). But maybe its somewhere to start.
-Darren
On Sun, Feb 5, 2023 at 1:21 AM Matthias Fechner <a class="moz-txt-link-rfc2396E" href="mailto:idefix@fechner.net" moz-do-not-send="true"><idefix@fechner.net></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Dear all,
I have a question regarding a setup I use at home.
It is for domain idefix.fechner.net.
I have at home a small server running with some services at it. As I do
not have a public IP, I tunnel traffic using pf on FreeBSD and openvpn
to route a public IP to my server at home.
This works nice but if I now access idefix.fechner.net it will always go
outside to the internet and then back through the tunnel to my local
server which is a real performance problem, as the internet connection
here is really slow.
The complete domain is dnssec signed using the following configuration:
zone "fechner.net" {
type master;
file "../master/fechner.net/fechner.net";
dnssec-policy "one-year-zsk";
inline-signing yes;
};
Now I want to make sure if I access idefix.fechner.net that it does not
use the tunnel but access it directly using the local address.
So the idea was to configure my named running at home to resolve some
host names differently.
What is here recommended best practice doing it?
Just added a new domain fechner.net and overwrite some A records? I
think that will break dnssec or?
Thanks for any pointer into the right direction.
Gruß
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
--
Visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users" moz-do-not-send="true">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at <a class="moz-txt-link-freetext" href="https://www.isc.org/contact/" moz-do-not-send="true">https://www.isc.org/contact/</a> for more information.
bind-users mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:bind-users@lists.isc.org" moz-do-not-send="true">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users" moz-do-not-send="true">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">Gruß
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">
Gruß
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
</pre>
</body>
</html>