Public stub zone

Unbound
1

Hi,

I wanted to employ Unbound to expose an experimental DNS server to the
world, benefiting from Unbounds caching and matured security mechanisms.

However, I cannot find a way to expose *just* my stub-zone to the world,
without allowing global recursion at the same time.

Is there a way around this?

Cheers,

- Pieter

2

Hi Pieter,

So if I read your question correctly you have
- An authority server which has no delegation towards it.
- your zone's NS records point to your unbound instance

However, I cannot find a way to expose *just* my stub-zone to the world,
without allowing global recursion at the same time.

I just tried the following:

server:
  ...
  local-zone: . refuse
  local-zone: unbound.net transparent
  ...

forward-zone:
   name: "unbound.net"
   forward-addr: 213.154.224.48
   forward-addr: 213.154.224.1

This would refuse any query not in the unbound.net zone. Does this work
for you?

Regards,
Yuri Schaeffer

3

Hi Yuri,

Hi Pieter,

So if I read your question correctly you have
- An authority server which has no delegation towards it.
- your zone's NS records point to your unbound instance

Both correct...

However, I cannot find a way to expose *just* my stub-zone to the world,
without allowing global recursion at the same time.

I just tried the following:

server:
  ...
  local-zone: . refuse
  local-zone: unbound.net transparent
  ...

forward-zone:
   name: "unbound.net"
   forward-addr: 213.154.224.48
   forward-addr: 213.154.224.1

This would refuse any query not in the unbound.net zone. Does this work
for you?

That works just wonderfully; I had a feeling it could be done somehow...

Thanks!

- Pieter

4

Hi Yuri,

Hi Pieter,

So if I read your question correctly you have
- An authority server which has no delegation towards it.
- your zone's NS records point to your unbound instance

However, I cannot find a way to expose *just* my stub-zone to the world,
without allowing global recursion at the same time.

I just tried the following:

server:
  ...
  local-zone: . refuse
  local-zone: unbound.net transparent
  ...

forward-zone:
   name: "unbound.net"
   forward-addr: 213.154.224.48
   forward-addr: 213.154.224.1

This would refuse any query not in the unbound.net zone. Does this work
for you?

Your example using a forward-zone works just fine, but I tried a
stub-zone instead of a forward-zone, and ran into a segfault with that.
See https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=528

I chose a stub zone since I have authoritative data and the docs mention:

"If you need more complicated authoritative data [...] setup a sub-zone
for it [...]."

What is valid reasoning to choose between a forward and stub zone
statement in my case?

PS. The experimental server in question is here:
http://github.com/skion/junkdns/. It basically looks up publicsuffix.org
extensions at the moment.

- Pieter

5

Hi Pieter,

See https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=528

Thanks, we will look in to it.

What is valid reasoning to choose between a forward and stub zone
statement in my case?

Well, your situation is a bit special... You don't want Unbound to be a
resolver but rather just a cache for your authority. This would be
exactly what forward does.

Regards,
Yuri

6

Hi Pieter,

Your example using a forward-zone works just fine, but I tried a
stub-zone instead of a forward-zone, and ran into a segfault with that.
See https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=528

This issue is now fixed in our subversion repository as r2994. It seems
very specific to your configuration. As a work around you could set the
log level <= 2.

Regards,
Yuri