Always Respond to NS record requests....

Amir A. thesubmitter at
Mon Mar 23 20:01:52 UTC 2020

Unfortunately, I can't touch the client.

I was looking for a more regexish solution but it seems I can't use wildcards or anything like:

> local-zone: .com typetransparent
> local-data: "*.com ns"

I saw some reference to using stub zones if I wanted regex or wildcards but I'm not sure I can do something like the override with a stub zone. If i even manage to create false NS entries via the stub zone then the actual lookups for that domain will be forwarded to that false (and probably incorrect NS)

Guess, I am stuck with some sort of automation to deploy all the local data overrides i need...
From: Paul Vixie <paul at>
Sent: Monday, March 23, 2020 3:52 PM
To: unbound-users at <unbound-users at>
Cc: Amir A. <thesubmitter at>
Subject: Re: Always Respond to NS record requests....

On Monday, 23 March 2020 13:53:03 UTC Amir A. via Unbound-users wrote:
> Hi,
> For our purposes we need a DNS server to always respond to  NS record
> requests. The problem is subdomains seem not to have NS records created for
> them even if the root domain as an NS record created.
> Ideally
>   1.  When a client asking for the NS record of a subdomain if it doesn't
> exist I want unbound to return the NS record of the APEX domain
>   2.  If that doesn't work then at least return a static entry for any NS
> record request of ANY domain or subdomain

you seem to be asking for a protocol change. finding the closest enclosing NS
RRset is not something the local server can do without searching, and right
now the protocol expects that the client who needs that data will drive that
searching. one way to perform that searching is res_findzonecut():

> The solution I have right now is:
> local-zone: typetransparent
> local-data: " ns"
> but that would require me to add an entry for every single "" and
> ""
> Anybody have a better solution?

teach your client how to drive the closest encloser discovery process.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unbound-users mailing list