howto resolve 10.in-addr.arpa

Unbound
1

Hello,

we have the following configuration to point unbound-1.5.4 to our private nameservers:

server:
   local-zone: "10.in-addr.arpa." transparent
   domain-insecure: "10.in-addr.arpa."

stub-zone:
   name: "private.example.com."
   stub-addr: "10.0.1.53"
   stub-addr: "10.0.2.53"

stub-zone:
   name: "10.in-addr.arpa."
   stub-addr: "10.0.1.53"
   stub-addr: "10.0.2.53"

2

Hi Andreas,

Hello,

we have the following configuration to point unbound-1.5.4 to our
private nameservers:

server: local-zone: "10.in-addr.arpa." transparent domain-insecure:
"10.in-addr.arpa."

stub-zone: name: "private.example.com." stub-addr: "10.0.1.53"
stub-addr: "10.0.2.53"

stub-zone: name: "10.in-addr.arpa." stub-addr: "10.0.1.53"
stub-addr: "10.0.2.53"

----

this setup run here for years. Now the server 10.0.2.53 died and we
notice timeouts for *.10.in-addr.arpa PTR queries. But we did /not/
notice any problems for *.private.example.com.

My guess is both do not work and the TTL is different. Normally,
unbound should try both addresses, and I guess it is trying them but
the other also does not work. unbound-control lookup can be used to
get the info on those two IP addresses, like ping time. Or maybe you
can dig @10.0.1.53 and see if it responds.

Otherwise, this is a bug of some sort, unbound should be trying all
available name servers for your query.

The local-zone config did not seem to be the problem.

Best regards,
   Wouter

3

W.C.A. Wijngaards via Unbound-users:

My guess is both do not work and the TTL is different.

not impossible ...

Normally, unbound should try both addresses, and I guess it is trying them but
the other also does not work. unbound-control lookup can be used to
get the info on those two IP addresses, like ping time. Or maybe you
can dig @10.0.1.53 and see if it responds.

Otherwise, this is a bug of some sort, unbound should be trying all
available name servers for your query.

I tried to reproduce the error condition with only one nameserver.
No Error :-/
I'll have to setup a second nameserver I could switch off on demand.
more observation if that's done...

The local-zone config did not seem to be the problem.

was my guess about transparent vs. nodefault right?

Thanks