Domain forward for /8 in-addr.arpa not working

[Petr Menšík]

Hi!

The problem in unbound exists, because unbound by default creates empty 
authoritative zones for them. You would have to disable those empty 
zones, because their responses are preferred over forwarder responses.

Check output of command: unbound-control list_local_zones

You should see a lot of x.100.in-addr.arpa. lines. You can check this by 
sending "dig @localhost -x 100.64.0.0" and checking flags in response. 
aa flag means local server has generated response and it were not 
received from remote server.

This can be fixed by having these lines in unbound.conf:

local-zone: "64.100.in-addr.arpa." nodefault
local-zone: "65.100.in-addr.arpa." nodefault
...
local-zone: "127.100.in-addr.arpa." nodefault

Alternatively unblock-lan-zones: yes might fix it also.

Another alternative is to explicitly define forward zones instead, which 
will disable creation of such empty zone of the same name. This is what 
you have found.

Non obvious problem is that forwarding 100.in-addr.arpa. only is less 
specific than those empty (sub)zones and therefore does not prevent 
creating those, without any warning that most of these zones will get 
blocked results by empty zones.

Cheers,
Petr


On 23/03/2025 12:11, Jeremy Beker via Unbound-users wrote:
> Paul,
>
> Thanks for the response. While you didn’t address the specific 
> question you did point me to the right solution. :)
>
> One clarification to not besmirch the good folks at Tailscale. They 
> are not using the whole 100.0.0.0/8 address space. They are only using 
> the 100.64.0.0/10 space from RFC6598. And as it is only used 
> internally to their network it won’t in most normal configs conflict 
> with ISP usage of the range.
>
> That said, since DNS has no awareness of CIDR, I was trying to “cheat” 
> by being overly broad in my query forwarding by using the larger /8.
>
> The proper solution, which you led me to, was to define forward-zones 
> for all 64 “class B” spaces inside the /10 CIDR range. Tedious, but 
> doable.
>
> I’m still curious why a /8 didn’t work, but my immediate problem is 
> solved.
>
> -Jeremy
>
> ----
> Jeremy Beker - gothmog at confusticate.com
> http://www.confusticate.com <http://www.confusticate.com/>
> Condensing fact from the vapor of nuance.
>
>> On Mar 23, 2025, at 02:00, Paul Wouters <paul at nohats.ca> wrote:
>>
>> On Sat, 22 Mar 2025, Jeremy Beker via Unbound-users wrote:
>>
>>> I have successfully set up a forward-zone for my `ts.net` domain to 
>>> tailscale’s DNS and it works great. I
>>> want to do the same for reverse lookups. All tailscale addresses are 
>>> in the 100.0.0.0/8 range. So I added
>>> the following to my config (via the GUI, but verified in the config 
>>> file):
>>
>> While not addressing your question, whoever is squatting on 100/8 has
>> picked a pretty bad range. This is in production all over the internet,
>> with the first chunk going to Verisign Business and AWS. Perhaps what
>> was/is intended is to re-use the range 100.64.0.0/10 which is reserved
>> by RFC6598 for CGNAT and should not appear in the public internet?
>>
>>> # Forward zones
>>> forward-zone:
>>>   name: "100.in-addr.arpa"
>>>   forward-addr: 100.100.100.100
>>
>> As 100.100.100.100 is part of 100.64.0.0/10.
>>
>>> This does not seem to work. Any request to look up an address (like 
>>> 100.94.184.34) returns:
>>
>> Who is 100.94.184.34 ? That must be one of your own or part of the
>> tailscale re-use of 100.64.0.0/10 ?
>>
>> Perhaps limiting your range to 100.64.0.0/10 will prevent you mixing up
>> this tailscale universe with the public DNS universe?
>>
>> Paul

-- 
Petr Menšík
Senior Software Engieer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20250612/89f4adfe/attachment.htm>