Hello friends!
I have recently started using tailscale and am working to integrate their MagicDNS into my home setup. I use unbound via opnsense and am hitting an issue.
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):
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
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
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