Why is Unbound not like a `dig +trace`?

[François Lafont]

Hi,

On 9/24/25 11:53, Yorgos Thessalonikefs via Unbound-users wrote:

> You can still learn a little more here!

:)

> 
> You shouldn't be getting a timeout with qname-minimisation enabled!
> The domain in.ac-versailles.fr is not properly configured and when asked with "in.ac-versailles.fr A" it will return a delegation with designated servers at:
>      prd-dns-int-01.in.ac-versailles.fr, and
>      prd-dns-int-02.in.ac-versailles.fr
> 
> Those servers do not seem to reply and cause the timeout you encounter with dig.
> 
> qname-minimisation exposes broken delegations by its way of operation.
> 
> Now, why do the ac-versailles.fr nameservers reply with a NODATA answer specifically for "in.ac-versailles.fr CAA" queries only, I don't know.


Indeed. In fact, this is the reverse. I explain. The "in.ac-versailles.fr" delegation (the "in" zone) is correct. It's a private zone for private usages etc. so not publicly reachable. Until very recently, it was perfectly OK for us like that. But, since few days, our CA (Certificate Authority) needs to make DNS requests like "type=CAA name=in.ac-versailles.fr" before to deliver our SSL certificates (If we want a certificates for the fqdn foo.in.ac-versailles.fr, the CA must check the CAA requests). It's new for us, our CA applies the RFC 8659 just recently. I have explained the problem in details here:

     https://lists.nlnetlabs.nl/pipermail/unbound-users/2025-September/008575.html

So we have:

* Our private zone "in.ac-versailles.fr" publicly unreachable but until very recently, this was not a problem for us (on the contrary, we were quite happy like that).
* But now our CA needs to solve "type=CAA name=in.ac-versailles.fr" to deliver our SSL certificates (and even a empty or NXDOMAIN response is OK but timeout is not acceptable by the RFC).

So, in the NS of the "ac-versailles.fr" zone (ie the *public* zone), we have installed a kind of DNS proxy (dnsdist) so that:

1. If the request is "type=CAA name=in.ac-versailles.fr" (or in the subdomain in.ac-versailles.fr), the proxy answers directly an empty response (with the "aa" flag, and yes, that's a lie, because the NS of the public zone have no authority over the "in" zone).
2. For any other request, the proxy passes the requests to the "real" nameserver of the zone "ac-versailles.fr".

So, currently:

* The "in.ac-versailles.fr" nameservers are publicly unreachable => It's OK.
* And the thing not really OK is the fact that the NS of "ac-versailles.fr" (ie the public zone) answer an empty response for "type=CAA name=in.ac-versailles.fr" requests. That is the real anomaly, the lie :). The NS should respond with a REFERRAL to the NS of the "in.ac-versailles.fr" but they don't do that anymore because of the proxy we put in place.

This proxy is a workaround to retrieve SSL certificates from our CA, we lie to our CA a little bit. But it's a workaround. And like most workarounds, it's not "100% RCF-compliant". So, in this post, with your explanations, I understand that our workaround doesn't work well with recursive DNS resolvers that perform qname-minimisation. :)

But currently, it seems to work well with our CA which now validates our SSL certificates correctly.

Maybe there is a better solution to solve this problem but, for now, it's the least bad solution we've found. We only cheat for CAA records to validate our SSL certificates by our CA. :)

And by the way, the CAs are in the process of generalizing the application of this RFC 8659, and I think there are quite a few organizations with private zones like us that are facing the same problem.

I hope my explanations were clear and thanks again for your help.

-- 
François Lafont