Hi, I do not know why you would be getting SERVFAIL, but the name ksc.wiki appears to not exist from my perspective:
% dig ksc.wiki ; <<>> DiG 9.10.6 <<>> ksc.wiki ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26112 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;ksc.wiki. IN A ;; AUTHORITY SECTION: wiki. 856 IN SOA a.nic.wiki. admin.tldns.godaddy. 1745315047 1800 300 604800 1800 ;; Query time: 8 msec ;; SERVER: 192.168.40.42#53(192.168.40.42) ;; WHEN: Tue Apr 22 05:49:30 EDT 2025 ;; MSG SIZE rcvd: 98 Perhaps try `dig ksc.wiki +cd` as wiki seems to be signed. Perhaps validation of the non-existence is failing for some reason? Thank you, Darren Ankney On Tue, Apr 22, 2025 at 4:28 AM The Gorf <thegorf+bind9us...@gmail.com> wrote: > > bind version:BIND 9.18.33-1~deb12u2-Debian (Extended Support Version) <id:> > > So it's pretty simple. Im getting a ton of SERVFAILs randomly and I can > neither figure out why nor figure out how to get bind to give me debug > information about why. The documentation here: > https://kb.isc.org/docs/aa-01526 > Hurts my head to read and references stuff that I can't figure out where in > the documentation it is to explain what it is. > > I took the exact document on that page and switched everything to "debug" and > I have reset the server, rebooted the server, nothing. Here is the exact one > line bind produces in its logs for the query that is generating the SERVFAIL: > > 22-Apr-2025 01:08:17.138 queries: info: client @0x7ffa3cb78168 > 192.168.8.104#47099 (ksc.wiki): query: ksc.wiki IN A + (10.30.160.20) > > Nothing. And here is the query-errors file: > geoff@NS1:/var/log/named$ cat query-errors | grep -i wiki > geoff@NS1:/var/log/named$ > zilch. > > So. what am I doing wrong here? Why can't I get any debug info out of this? > > logging { > channel default_log { > file "/var/log/named/default" versions 3 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > channel auth_servers_log { > file "/var/log/named/auth_servers" versions 100 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > channel dnssec_log { > file "/var/log/named/dnssec" versions 3 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > channel zone_transfers_log { > file "/var/log/named/zone_transfers" versions 3 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > channel ddns_log { > file "/var/log/named/ddns" versions 3 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > channel client_security_log { > file "/var/log/named/client_security" versions 3 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > channel rate_limiting_log { > file "/var/log/named/rate_limiting" versions 3 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > channel rpz_log { > file "/var/log/named/rpz" versions 3 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > channel dnstap_log { > file "/var/log/named/dnstap" versions 3 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > // > // If you have the category ‘queries’ defined, and you don’t want query > logging > // by default, make sure you add option ‘querylog no;’ - then you can toggle > // query logging on (and off again) using command ‘rndc querylog’ > // > channel queries_log { > file "/var/log/named/queries" versions 600 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > // > // This channel is dynamic so that when the debug level is increased using > // rndc while the server is running, extra information will be logged about > // failing queries. Other debug information for other categories will be > // sent to the channel default_debug (which is also dynamic), but without > // affecting the regular logging. > // > channel query-errors_log { > file "/var/log/named/query-errors" versions 5 size 20m; > print-time yes; > print-category yes; > print-severity yes; > severity debug; > }; > // > // This is the default syslog channel, defined here for clarity. You don’t > // have to use it if you prefer to log to your own channels. > // It sends to syslog’s daemon facility, and sends only logged messages > // of priority info and higher. > // (The options to print time, category and severity are non-default.) > // > channel default_syslog { > print-time yes; > print-category yes; > print-severity yes; > syslog daemon; > severity debug; > }; > // > // This is the default debug output channel, defined here for clarity. You > // might want to redefine the output destination if it doesn’t fit with your > // local system administration plans for logging. It is also a special > // channel that only produces output if the debug level is non-zero. > // > channel default_debug { > print-time yes; > print-category yes; > print-severity yes; > file "named.run"; > severity debug; > }; > // > // Log routine stuff to syslog and default log: > // > category default { default_syslog; default_debug; default_log; }; > category config { default_syslog; default_debug; default_log; }; > category dispatch { default_syslog; default_debug; default_log; }; > category network { default_syslog; default_debug; default_log; }; > category general { default_syslog; default_debug; default_log; }; > // > // From BIND 9.12 and newer, you can direct zone load logging to another > // channel with the new zoneload logging category. If this would be useful > // then firstly, configure the new channel, and then edit the line below > // to direct the category there instead of to syslog and default log: > // > category zoneload { default_syslog; default_debug; default_log; }; > // > // Log messages relating to what we got back from authoritative servers during > // recursion (if lame-servers and edns-disabled are obscuring other messages > // they can be sent to their own channel or to null). Sometimes these log > // messages will be useful to research why some domains don’t resolve or > // don’t resolve reliably > // > category resolver { auth_servers_log; default_debug; }; > category cname { auth_servers_log; default_debug; }; > category delegation-only { auth_servers_log; default_debug; }; > category lame-servers { auth_servers_log; default_debug; }; > category edns-disabled { auth_servers_log; default_debug; }; > // > // Log problems with DNSSEC: > // > category dnssec { dnssec_log; default_debug; }; > // > // Log together all messages relating to authoritative zone propagation > // > category notify { zone_transfers_log; default_debug; }; > category xfer-in { zone_transfers_log; default_debug; }; > category xfer-out { zone_transfers_log; default_debug; }; > // > // Log together all messages relating to dynamic updates to DNS zone data: > // > category update{ ddns_log; default_debug; }; > category update-security { ddns_log; default_debug; }; > // > // Log together all messages relating to client access and security. > // (There is an additional category ‘unmatched’ that is by default sent to > // null but which can be added here if you want more than the one-line > // summary that is logged for failures to match a view). > // > category client{ client_security_log; default_debug; }; > category security { client_security_log; default_debug; }; > // > // Log together all messages that are likely to be related to rate-limiting. > // This includes RRL (Response Rate Limiting) - usually deployed on > authoritative > // servers and fetches-per-server|zone. Note that it does not include > // logging of changes for clients-per-query (which are logged in category > // resolver). Also note that there may on occasions be other log messages > // emitted by the database category that don’t relate to rate-limiting > // behaviour by named. > // > category rate-limit { rate_limiting_log; default_debug; }; > category spill { rate_limiting_log; default_debug; }; > category database { rate_limiting_log; default_debug; }; > // > // Log DNS-RPZ (Response Policy Zone) messages (if you are not using DNS-RPZ > // then you may want to comment out this category and associated channel) > // > category rpz { rpz_log; default_debug; }; > // > // Log messages relating to the "dnstap" DNS traffic capture system (if you > // are not using dnstap, then you may want to comment out this category and > // associated channel). > // > category dnstap { dnstap_log; default_debug; }; > // > // If you are running a server (for example one of the Internet root > // nameservers) that is providing RFC 5011 trust anchor updates, then you > // may be interested in logging trust anchor telemetry reports that your > // server receives to analyze anchor propagation rates during a key rollover. > // If this would be useful then firstly, configure the new channel, and then > // un-comment and the line below to direct the category there instead of to > // syslog and default log: > // > // > category trust-anchor-telemetry { default_syslog; default_debug; > default_log; }; > // > // If you have the category ‘queries’ defined, and you don’t want query > logging > // by default, make sure you add option ‘querylog no;’ - then you can toggle > // query logging on (and off again) using command ‘rndc querylog’ > // > category queries { queries_log; }; > // > // This logging category will only emit messages at debug levels of 1 or > // higher - it can be useful to troubleshoot problems where queries are > // resulting in a SERVFAIL response. > // > category query-errors {query-errors_log; }; > }; > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
