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) [email protected] 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 <[email protected]> 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. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
