> On 20 Feb 2025, at 17:35, Danjel Jungersen <dan...@jungersen.dk> wrote:
>
>
>
> On 19 February 2025 13:01:01 CET, Mark Andrews <ma...@isc.org> wrote:
> >You can install a negative trust anchor or sign the zone so that DNSSEC
> >validation works. The zone exists in the public DNS. You can use the same
> >key material or use different key material and publish multiple DS records
> >for both the private and public DNSKEYs.
> >
> >The later will allow DNSSEC validation to work with BYOD.
> >
> >You can also sign your internal zone and add trust anchors for it without
> >publishing DS records. This won’t work BYOD.
>
> I'm very sorry, but you lost me there.
>
> The zone is available publicly, but from public serveres not hosted by me
> (one.com).
> And points to my external ip.
> My internal bind redirects local traffic directly to local servers on local
> ip's.
DNSSEC is designed to stop spoofed answers being accepted. When you create a
local zone that overrides what is in the public zones you are effectively
spoofing answers. As you have a DNSSEC signed public zone if you want to have
these spoofed answers accepted you need to do one of the following:
1) create a working chain of trust that links to your private zone content
or
2) configure a negative trust anchor for your namespace on every validating
device
or
3) configure a positive trust anchor for your namespace on every validating
device
or
4) have the names that are being overridden be in unsigned zones
1 and 4 work for every validating device including BYOD
2 and 3 only work for those validating devices that get configured
1 and 3 require you to sign your internal zone
Long 1 is the best long term solution. 2 and 3 are stop gaps with 3 being more
secure than 2. 4 you are going backward security wise.
3 can be converted to 1 by adding a DS record(s) for your internal DNSKEY(s) to
the dk zone in addition to those you have there for the public zone. You will
need to use the same DNSSEC algorithms for the internal and external zones if
you do this.
You currently have the following DS which means you are using ECDSAP256SHA256
(13) as the DNSSEC key algorithm.
jungersen.dk. 7200 IN DS 26658 13 2
23E45B495015A14C3F4FF57C0A36850C013B881BAAF1E32EE4C0C839 FF9CCA52
I would add “dnssec-policy { csk lifetime unlimited algorithm ECDSAP256SHA256;
};” to your internal primary if you choose to do 1 or 3. This will add a
DNSKEY record to the zone and cause it to be signed. You can then take the
generated DNSKEY and install it as a trust anchor on the postfix boxes.
You will need to do some reading first. Others here can give you more advice.
> It is 1 zone (jungersen.dk), currently 6 hosts (mail.jungersen.dk
> ftp.jungersen.dk and a couple of more)
> 1 server that need this extra caching, the rest of machines are using the
> "real" bind directly, and this works.
> Thinking about it makes me wonder why this works. Is it because it is an
> authoritative server? Even though it is not signed?
>
> What would be the easiest route from here?
>
> Tia
> Danjel
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
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
