Hi Nick, and all that are interested,
I tried now RPZ and it seems to work fine. I will see if it works with
all devices as expected the next weeks.
I think that a device that uses a local resolver that checks DNSSEC will
maybe refuse this solution.
Just for other users searching for a similar setup, I did the following:
Edit /usr/local/etc/namedb/named.conf:
options {
...
//enable the response policy zone
response-policy {
zone "rpz.local";
};
}
logging {
...
channel rpzlog {
file "/var/log/rpz.log" versions unlimited size 100m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
category rpz { rpzlog; };
};
Then I added the new zone to my /usr/local/etc/namedb/master.zones:
zone "rpz.local" {
type master;
file "/usr/local/etc/namedb/master/db.rpz.local";
allow-query { localhost; };
allow-transfer { localhost; };
};
Create and empty zonefile:
cd /usr/local/etc/namedb/master
cp empty.db db.rpz.local
Now add to db.rpz.local what you would like to overwrite like:
idefix.fechner.net A 192.168.0.1
Check configuration is fine:
named-checkconf
named-checkzone rpz db.rpz.local
and restart bind:
service named restart
Make a tail -F /var/named/var/log/rpz.log
And resolve:
host idefix.fechner.net
It gives me now the local address and adds an entry in the rpz logging.
So far so good.
Thanks a lot for your help, really appreciated it!
Matthias
Am 07.02.2023 um 09:54 schrieb Nick Tait via bind-users:
Hi Matthias.
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.)
Another advantage that RPZ has over split-views, is that you don't
need to maintain a separate duplicate zone file.
OTOH if the DNSSEC thing is an issue, you may want to look at other
alternatives, including:
* The split-view thing I mentioned below.
* 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.
Nick.
On 7/02/23 19:45, Matthias Fechner wrote:
Hi Darren, Hi Nick,
at first thanks a lot for your answer.
I see that I have not explained my use-case detailed enough.
I have bind running for domain fechner.net, but not at home and this
server I think is here completely out of discussion.
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.
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.
It is not connected in any way to my bind servers running for domain
fechner.net.
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.
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.
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).
I hope that explain it better what I would like to solve.
Matthias
Am 07.02.2023 um 07:48 schrieb Nick Tait via bind-users:
Hi Matthias.
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?
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: /Answers
coming from a mirror zone look almost exactly like answers from a
zone of type //|secondary|//, with the notable exceptions that the
AA bit (“authoritative answer”) is not set, and the AD bit
(“authenticated data”) is./
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:
# View containing zone with public IP addresses.
view "public" {
match-clients { ... };
zone "fechner.net" {
type primary;
file "../master/fechner.net/*public-*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/*private-*fechner.net";
dnssec-policy "one-year-zsk";
inline-signing yes;
};
};
The two copies of the zone are signed using the same keys.
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?
Nick.
On 6/02/23 01:08, Darren Ankney wrote:
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<ide...@fechner.net> wrote:
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
--
Visithttps://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 athttps://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
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
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 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
