Hi Florian,
On 27/02/2023 17:33, Paul Wouters via Unbound-users wrote:
On Mon, 27 Feb 2023, Florian Streibelt via Unbound-users wrote:
No, again that is not my issue.
All of the servers that dns.com operates are dropping queries for the
Ressource Record Type DS.
They are the authoritative servers for dns.com as well as for the
parent zone of the zone our customer wants to resolve and the zone
itself.
We are providing recursion for our customer.
Then if they do not respond properly for DS records or with proof of
non-existence, then that implementation is broken and there is not much
you can do. But this means they should also fail to work for google dns
on 8.8.8.8, or on quad9 at 9.9.9.9. That is, your customer should really
move their domain elsewhere.
Perhaps you can try a local override, eg:
local-zone: <your-parentzone> ds always_nxdomain
local-zone: <your-customerzone> ds always_nxdomain
But I don't really know if that will work.
What could work would be:
local-zone: <your-parentzone> typetransparent
local-data: "<your-customerzone> IN DS <ds-data>"
domain-insecure: <your-customerzone>
These are DS answers to the clients.
You would need to provide fake DS data though, not sure if that is
desirable and how that would break the clients that ask for it.
If the zones do not do DNSSEC in the first place (so there is no chain
to break) you could try that.
Best regards,
-- Yorgos
Another option might be to run an unbound instance with
val-permissive-mode=yes
and then on your regular resolver, use a forward-zone: for your
parentzone and customer zone to that unbound instance.
Paul
