Resolve some hosts thats are dnssec signed differently
Matthias Fechner
idefix at fechner.net
Tue Feb 7 16:33:33 UTC 2023
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<idefix at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230207/a9ba584f/attachment-0001.htm>
More information about the bind-users
mailing list