(re)adding local resolver.arpa zone

Unbound
1

Hi,

I am now (finally!) after the earlier round of debugging memory
leaks in unbound with use of DoH re-enabling DoT and DoH on my
unbound instance, since the fix is included in unbound 1.23.1.

Part and parcel of that is getting a local customized
resolver.arpa zone loaded, to enable use of RFC 9462, "Discovery
of Designated Resolvers".

However, I am having a hard time getting my unbound 1.23.1 to
properly load and use my own local resolver.arpa zone.

# unbound-control list_local_zones

says among other things

service.arpa. static
resolver.arpa. static
test. static

and

# unbound-control list_auth_zones

includes info about my locally added "auth-zone":

resolver.arpa. serial 1

(the other zone listed here is an RPZ zone which is irrelevant
here.)

However, it is apparent that when I query this unbound instance
about resolver.arpa, I get the answer from the "local zone", and
not my own customized resolver.arpa zone:

% dig @$unbound_server resolver.arpa. soa
...
;; ANSWER SECTION:
resolver.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
...

This is quite different from what I have in my own "auth-zone"
which is configured with

auth-zone:
        name: resolver.arpa
        zonefile: "pz/resolver.arpa"

I have been perusing the unbound.conf(5) man page and have the
following remarks:

1) It is somewhat unclear whether "auth-zone:" should be listed
   under another "clause", i.e. indented, or whether it should be
   on the outermost level in unbound.conf. My current attempt
   has it at the outermost level, as shown above.

2) The manual page appears to make a distinction between what's
   called a "clause" (outermost level?), such as "server:", and
   what's referred to as "options" (to be found under a specific
   "clause"(?)). However, the wording on this in general and
   wrt. "auth-zone:" could be more unambigious and explicit.

3) The various options listed under the "server:" clause (and
   other clauses) are not alphabetically sorted, which makes
   finding a given option quickly quite difficult, given the size
   of the man page. Yes, I can search, but then the context of
   "under which clause am I now looking" gets lost.

Given some clarification from the maintainers, I can probably
engage in crafting a reshuffling of the unbound.conf content and
to add some words of clarification.

I am left wondering why my auth-zone: configuration section is
apparently both being acted on (ref. list_auth_zones output), and
simultaneously ignored (ref. the list_local_zones output and the
"dig" query), and I suspect it's the "local zones" version of the
resolver.arpa zone which is still being served up to clients,
despite my best attempts at overriding the "local zone" with a
separate authoritative zone of my own. And, yes, I have done a
full restart of unbound, with no scary warnings in syslog.

So ... "help!"

Regards,

- Håvard

2

Hello Havard,

reading RFC 9462 and looking in my resolver logs, I only see one type of queries:

`_dns.resolver.arpa. SVCB`

So, I added these two lines in my unbound.conf:

     local-zone: resolver.arpa. static
     local-data: '_dns.resolver.arpa. 300 SVCB <your data here>'

Now, I can test:

$ dig @resolver-ip _dns.resolver.arpa. SVCB +short
<your data here>

$ dig _dns.resolver.arpa. SVCB +short
<your data here>

That's all.
But it does not necessary mean, any client will magically *use* the announced DoT / DoH / DoQ :-/

Andreas

3

I have been perusing the unbound.conf(5) man page and have the
following remarks:

1) It is somewhat unclear whether "auth-zone:" should be listed
   under another "clause", i.e. indented, or whether it should be
   on the outermost level in unbound.conf. My current attempt
   has it at the outermost level, as shown above.

2) The manual page appears to make a distinction between what's
   called a "clause" (outermost level?), such as "server:", and
   what's referred to as "options" (to be found under a specific
   "clause"(?)). However, the wording on this in general and
   wrt. "auth-zone:" could be more unambigious and explicit.

3) The various options listed under the "server:" clause (and
   other clauses) are not alphabetically sorted, which makes
   finding a given option quickly quite difficult, given the size
   of the man page. Yes, I can search, but then the context of
   "under which clause am I now looking" gets lost.

Given some clarification from the maintainers, I can probably
engage in crafting a reshuffling of the unbound.conf content and
to add some words of clarification.

Uh, I meant the unbound.conf(5) man page, not the example config
file, if that wasn't obvious. In addition to sorting the options
under each clause, as an example, I think I would suggest to replace

       There must be whitespace between keywords. Attribute keywords end with
       a colon ':'. An attribute is followed by a value, or its containing
       attributes in which case it is referred to as a clause. Clauses can be
       repeated throughout the file (or included files) to group attributes
       under the same clause.

with, probably something along the lines of...

       The configuration file is logically divided into "sections"
       where each section is introduced by a "section clause".

       The recognized section clauses are:

       server: Most of the configuration of the recursive DNS
                 name server function is found in this section.

       auth-zone: Configuration of local authoritative zones.

       cachedb: Configuration of the optional "cache DB"
          feature to e.g. use redis for this function.

       dnscrypt: Configuration of the optional dnscrypt
          feature.

       dnstap: Configuration of the optional dnstap feature
          to "mirror out" a copy of the DNS queries and
          responses.

       dynlib: Configuration of the optional feature to load
          dynamic custom shared libraries into unbound.

       forward-zone: Configuration for selective query forwarding
          of recursive requests where the answer is not
          in the local cache.

       python: Configuration for the optional python script
          module.

       remote-control: Configuration of the facility used by
                      unbound-control(8).

       rpz: Configuration for Response Policy Zones,
          allowing blocking or other custom actions for
          certain lookups.

       stub-zone: Configuration of redirection of certain parts
          of the name space to "custom name servers",
          e.g. for domain names not generally available
          on the greater Internet.

       view: Configuration for different views of the name
          space. You can use e.g. access-control-tag or
          access-control-vew options to direct certain
          clients to certain views. Views can be
          combined with e.g. "rpz" to perform that
          function for just a subset of allowed clients.

       Section clauses may occur more than once, to logically group
       options for a given feature or aspect in one visually
       cohesive group. This may be particularly useful for the
       "server:" clause with its myriad of options.

       Whitespace indentation of option names under each section is
       insignificant, but is still recommended for visual clarity.

with a fact-check for the latter. I beleive it to be accurate, so
deviates both from what python and the .yml file format does...

Regards,

- Håvard

4

Hi Havard,

I think you need to set the zone to 'nodefault'. From Unbound conf documentation:

# By default, for a number of zones a small default 'nothing here'
# reply is built-in. Query traffic is thus blocked. If you
# wish to serve such zone you can unblock them by uncommenting one
# of the nodefault statements below.
# You may also have to use domain-insecure: zone to make DNSSEC work,
# unless you have your own trust anchors for this zone.
...
# local-zone: "resolver.arpa." nodefault
...

HTH,
Otto

5

Part and parcel of that is getting a local customized
resolver.arpa zone loaded, to enable use of RFC 9462,
"Discovery of Designated Resolvers". However, I am having a
hard time getting my unbound 1.23.1 to properly load and use
my own local resolver.arpa zone.

Hello Havard,

reading RFC 9462 and looking in my resolver logs, I only see one type
of queries:

`_dns.resolver.arpa. SVCB`

That figures.

So, I added these two lines in my unbound.conf:

    local-zone: resolver.arpa. static
    local-data: '_dns.resolver.arpa. 300 SVCB <your data here>'

My configuration has:

auth-zone:
        name: resolver.arpa
        zonefile: "pz/resolver.arpa"

Does not an auth-zone override a local-zone zone which is
apparently automatically provided? If it doesn't, that violates
the principle of least astonishment, since the DNS name tree is
only a single tree, and an explicit configuration for a given DNS
node (as above via auth-zone) should IMO override whatever is
automatically provided, irrespective of the method it was
automatically provided via.

My zone file consists of

$ORIGIN resolver.arpa.
$TTL 3600
;

; Implement discovery of resolvers, ref. RFC 9462:

@ SOA dns-resolver1.uninett.no. hostmaster.uninett.no (
                        1
                        28800
                        3600
                        604800
                        900
                )

@ NS dns-resolver1.uninett.no.
@ NS dns-resolver2.uninett.no.

; DNS-over-HTTPS:
_dns SVCB 1 dns-resolver1.uninett.no. (
                        alpn=h2 dohpath=/dns-query{?dns} )
; DNS-over-TLS:
_dns SVCB 2 dns-resolver1.uninett.no. (
                        alpn=dot port=853 )
; DNS-over-HTTPS:
_dns SVCB 3 dns-resolver2.uninett.no. (
                        alpn=h2 dohpath=/dns-query{?dns} )
; DNS-over-TLS:
_dns SVCB 4 dns-resolver2.uninett.no. (
                        alpn=dot port=853 )

; EOF

Now, I can test:

$ dig @resolver-ip _dns.resolver.arpa. SVCB +short
<your data here>

$ dig _dns.resolver.arpa. SVCB +short
<your data here>

That's all.

Right. But in my case I cannot; I get the "built-in" zone data
instead, ref.:

$ dig @dns-resolver2.uninett.no. _dns.resolver.arpa. svcb

; <<>> DiG 9.21.12 <<>> @dns-resolver2.uninett.no. _dns.resolver.arpa. svcb
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57510
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dns.resolver.arpa. IN SVCB

;; AUTHORITY SECTION:
resolver.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 1 msec
;; SERVER: 2001:700:0:ff00::2#53(dns-resolver2.uninett.no.) (UDP)
;; WHEN: Thu Oct 16 20:29:45 CEST 2025
;; MSG SIZE rcvd: 106

$

Granted, I could probably work around the problem by using the
local-zone: configuration clause instead, but ... I still think
the current behaviour is wrong, and my config ought to have
worked as intended. It did back in the 1.22.x days, which is, I
suspect, from an era before the resolver.arpa zone was added to
the "automatic local-zone" list of zones.

But it does not necessary mean, any client will magically *use* the
announced DoT / DoH / DoQ :-/

That's a given, of course. But if you don't supply the hints,
most of them will not come. It does appear, though, that there
are a few opportunistic users of DoT even without the above
announcement, but it's at a much lower rate than what it used to
be with the above in place.

Regards,

- Håvard

6

I think you need to set the zone to 'nodefault'. From Unbound conf
documentation:

# By default, for a number of zones a small default 'nothing here'
# reply is built-in. Query traffic is thus blocked. If you
# wish to serve such zone you can unblock them by uncommenting one
# of the nodefault statements below.
# You may also have to use domain-insecure: zone to make DNSSEC work,
# unless you have your own trust anchors for this zone.
...
# local-zone: "resolver.arpa." nodefault
...

Yes, thank you, that did it.

A bit more pedal-driven than I would have expected, but it'll do.

Regards,

- Håvard

7

Hi Havard,

I took your suggestions and incorporated them into the man page along with some other changes.

https://github.com/NLnetLabs/unbound/commit/9602973c863d506cfce88d632919136627901bb4
https://github.com/NLnetLabs/unbound/commit/6ad26909dd3a22228ebf9711ebc9e2c3b4fa8d44

Best regards,
-- Yorgos

8

Hallo und guten Tag

9

Hallo und guten Tag

10

Hallo und guten Tag

11

Hallo und guten Tag

12

Hallo und guten Tag

13

Hallo und guten Tag

14

Hallo und guten Tag

15

Hallo und guten Tag

16

Hallo und guten Tag

17

Hallo und guten Tag

18

Hallo und guten Tag

19

Hallo und guten Tag

20

Hallo und guten Tag