Problem with undead upstrems

George (Yorgos) Thessalonikefs george at nlnetlabs.nl
Tue Feb 28 10:02:14 UTC 2023


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


More information about the Unbound-users mailing list