PTR syntax for stub or forward zones

Unbound
1

Hello,

So far setting up unbound has been going fine, what however is missing,
is the proper configuration for the internal ptr zones. I've tried:

name: "168.192.in-addr.arpa"
stub-addr: 192.168.0.53@53
...

as well as
name: "0.0.168.192.in-addr.arpa"
stub-addr: 192.168.0.53@53

And done the same with alternatively using forward zones.

The stub/forward address is of course pointing to an internal
authorative nameserver and the ptr zones have been listed as insecure
domains as well.

While this configuration works perfectly fine with forward zones, it
does not work for reverse, any the question is: what am I missing?

In fact, looking at the logs, I can see, that unbound tries to resolve
those publically:

unbound[1826:0] info: response for 192.168.2.10. A IN
unbound[1826:0] info: reply from <.> 192.5.5.241#53
unbound[1826:0] info: query response was NXDOMAIN ANSWER
unbound[1826:0] info: finishing processing for 192.168.2.10. A IN
unbound[1826:0] debug: validator[module 1] operate:
extstate:module_wait_module event:module_event_moddone unbound[1826:0]
info: validator operate: query 192.168.2.10. A IN unbound[1826:0]
info: respip operate: query 192.168.2.10. A IN unbound[1826:0] reply:
172.16.35.25 192.168.2.10. A IN NXDOMAIN 0.009302 0 116

That should not happen, so surely I have done something wrong, but as
of now, the unbound.conf man page has not been helpful in this regard.
Or I have misread something.

Thanks for any ideas

Ede

2

:: On Mon, 19 Aug 2024 11:01:29 +0200
:: <20240819110129.2512fb7d@kaperfahrt.nebelschwaden.de>

name: "168.192.in-addr.arpa"
stub-addr: 192.168.0.53@53

this one looks ok

as well as
name: "0.0.168.192.in-addr.arpa"
stub-addr: 192.168.0.53@53

and I'd avoid this, that being said, with ONLY the first one above in
place, try adding

private-address: 192.168.0.0/16

to your config

3

Thanks very much for your fast reply. I however should crawl under a rock, as this problem was not even unbound related.

I've assumed drill to be intelligent enough to recognize ptr queries automatically, as the oh so bad nslookup once did.

It does not, so all the years I have been trying to forward resolve ip addresses.

Sorry for the noise, it now seems to work. And beatifully so, also with transfer of rpz.

Thanks for your time again

Ede

4

Thanks very much. For one, I should crawl under a rock, as this problem was not even unbound related. I've assumed drill to be intelligent enough to recognize ptr queries automatically, as the oh so bad nslookup once did.

It does not, so I have actually been trying to forward resolve ip adresses.

However, now that this has been resolved, either with or without the "private-address" attribute I now get

5

Just ignore this mail, I've still had unblock-lan zones commented out. This was never meant to be sent.