(re)adding local resolver.arpa zone

[Havard Eidnes]

>> 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