I need to provide different responses for the same name so that I can provide the service for both ways (coming from internet → external ip and coming from internal → private ip). I couldn’t use the external ip internally for performance and technical reasons (router is not capable of hairpin-nat and i wouldn’t want to do it for performance reasons anyway).
I think this is a quite common practice. I saw it implemented often at customers. Also with GSLB (global server load balancing) using DNS it would be needed to serve different records for different clients depending on world regions.
How can such a scenario be supported while using DNSSEC? At the moment I implement the described scenario with using deSEC as the external DNS-server, while using Pi-hole (dnsmasq) for the internal records. The internal records however are not signed, as Pi-hole doesn’t support being an authorative DNS server. Pi-hole itself does validate the DNSSEC signatures of the answers of all outgoing requests.
This setup works for me now. Is this a correct implementation? If not, what should be changed?
That’s called “split-view DNS” or “split-horizon DNS”. It is not currently supported by Desec, but it can be implemented on the resolver side, without support from the authoritative servers, if all clients that need the differing view can be expected to use a specific resolver. If they blindly trust that resolver, DNSSEC on the authoritative servers is no hindrance. There are recommendations on implementing split-view DNS. Your configuration is paragraph 4.1.5
From my experience, this kind of setup is a bit of a PITA.
Having no internal DNSSEC is straightforward enough, until you set up internal systems, that can actually do DNSSEC validation on the end point. Systemd-resolved does it, for example. For these systems, you internal DNS breaks completely until you disable DNSSEC validation (for your domain, at least).
I ended up running an authoritative name server for my internal network, that signs my internal subdomain. The network’s main resolver is actually a DNS proxy (dnsdist, to be specific) that directs queries on my internal subdomain to the internal name server and everything else to a regular recursive resolver.
I added a DS record for my internal subdomain to deSEC, so my internal systems can validate the DNSSEC chain. No NS record on deSEC, so the internal subdomain can still be resolved externally (using deSEC’s name servers).
This setup works, but is somewhat finicky when internally working with the external view on my internal subdomain (e.g. for DNS-based domain validation by Let’s Encrypt).
I believe this qualifies as the “Multiple DS Records” approach.