resolver: DS query for local authoritative zone returns SERVFAIL

[Ondřej Surý]

Hi,

the authoritative servers for 69.155.90.in-addr.arpa are broken.
Instead of returning the proof of nonexistence for DS records
they return the delegation. DS is a parent side record.

>   ; <<>> DiG 9.21.24 <<>> +norec 64-127.69.155.90.in-addr.arpa DS @auth.primary-dns.co.uk.
>   ;; global options: +cmd
>   ;; Got answer:
>   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 362
>   ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
> 
>   ;; OPT PSEUDOSECTION:
>   ; EDNS: version: 0, flags:; udp: 65000
>   ;; QUESTION SECTION:
>   ;64-127.69.155.90.in-addr.arpa. IN      DS
> 
>   ;; AUTHORITY SECTION:
>   64-127.69.155.90.in-addr.arpa. 3600 IN  NS      ns1.le-fay.org.
>   64-127.69.155.90.in-addr.arpa. 3600 IN  NS      ns2.le-fay.org.
>   64-127.69.155.90.in-addr.arpa. 3600 IN  NS      ns3.le-fay.org.
> 
>   ;; Query time: 31 msec
>   ;; SERVER: 2001:8b0:0:30::51bb:1e2a#53(auth.primary-dns.co.uk.) (UDP)
>   ;; WHEN: Mon Aug 17 11:34:28 CEST 2026
>   ;; MSG SIZE  rcvd: 142
> 

Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org

ADHD brain at work: I sometimes lose track of my inbox. Please feel free to send a gentle nudge if you're waiting on a reply!

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 17. 8. 2026, at 11:14, Lexi Winter <lexi at le-fay.org> wrote:
> 
> hello,
> 
> i'm using BIND 9.20.26 on FreeBSD 15.0.  i'm having an issue where a DS
> query for a zone unexpectedly returns SERVFAIL:
> 
>  # dig 64-127.69.155.90.in-addr.arpa ds @::1 +noall +answer +comments
>  ;; Got answer:
>  ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35
>  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
>  ;; OPT PSEUDOSECTION:
>  ; EDNS: version: 0, flags:; udp: 1232
>  ; COOKIE: 4202c41987065998010000006a82cc3a5e9251f76a4ae608 (good)
> 
> when returning the error, BIND logs:
> 
>  Aug 17 09:54:18 amaranth named[43811]: query-errors: info: client
>  @0x3c5a4b759000 ::1#18083 (64-127.69.155.90.in-addr.arpa): view resolver:
>  query failed (SERVFAIL) for 64-127.69.155.90.in-addr.arpa/IN/DS at query.c:7651
> 
> but no other useful information.
> 
> a query for a different rrtype, such as NS, works fine:
> 
>  # dig 64-127.69.155.90.in-addr.arpa ns @::1 +noall +answer +comments
>  ;; Got answer:
>  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25297
>  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
>  ;; OPT PSEUDOSECTION:
>  ; EDNS: version: 0, flags:; udp: 1232
>  ; COOKIE: ab68fd7c1fd103a0010000006a82cc5fedde6474d363832f (good)
>  ;; ANSWER SECTION:
>  64-127.69.155.90.in-addr.arpa. 3600 IN  NS      ns3.le-fay.org.
>  64-127.69.155.90.in-addr.arpa. 3600 IN  NS      ns1.le-fay.org.
>  64-127.69.155.90.in-addr.arpa. 3600 IN  NS      ns2.le-fay.org.
> 
> querylog for both queries shows:
> 
>  2026-08-17T09:54:18.452 queries: info: client @0x3c5a4b759000 ::1#18083 
>  (64-127.69.155.90.in-addr.arpa): view resolver: query: 
>  64-127.69.155.90.in-addr.arpa IN DS +E(0)K (::1)
> 
>  2026-08-17T09:54:55.512 queries: info: client @0x3c5a4a9f5000 ::1#64036
>  (64-127.69.155.90.in-addr.arpa): view resolver: query:
>   64-127.69.155.90.in-addr.arpa IN NS +E(0)K (::1)
> 
> this zone is not signed, it contains no DS records (or any other DNSSEC
> related records) and there are no DS records in the parent zone.  for
> reference, a copy of the zone (AXFR output) is available here:
>  https://www.le-fay.org/files/tmp/64-127.69.155.90.in-addr.arpa.txt
> 
> the zone is configured via a catalogue zone in a view:
> 
>  view "resolver" {
>  attach-cache "resolver";
>  match-destinations { [...] };
>  dns64 64:ff9b::/96 { clients { none; }; };
>  disable-empty-zone "d.f.ip6.arpa";
>  include "/usr/local/etc/namedb/stub-zones.conf";
> 
>  zone "catalog.invalid" {
>  type secondary;
>  file "/var/db/named/secondary/catalog.invalid.zone";
>  primaries { [...] };
>  notify no;
>  min-refresh-time 300;
>  max-refresh-time 300;
>  };
> 
>  catalog-zones {
>  zone "catalog.invalid"
>  zone-directory "/var/db/named/secondary"
>  default-primaries { [...] };
>  };
>  };
> 
> the same catalogue zone is also configured in another view, which is identical
> aside from DNS64 being enabled in that view.  both views exhibit the same
> SERVFAIL behaviour.
> 
> i don't think this is expected behaviour -- does anyone have any idea
> what's going on here?
> 
> thanks.
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.