Re: Massive increase of SERVFAIL after April 28th 2025.

serve the content they had provided it hasn’t expired in the meantime by reading it off local disc drives. This obviously has not happened for the zones you mentioned. The servers appear to have come up without access to the zone content they are supposed to serve and are hence returning SERVFAIL

Re: Massive increase of SERVFAIL after April 28th 2025.

Also don’t use +short if you want to see the NSID. From my corner of the internet I get the following. % dig +nsid version.bind. txt ch @dns4.p08.nsone.net ; <<>> DiG 9.21.3-dev <<>> +nsid version.bind. txt ch @dns4.p08.nsone.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUE

Re: Massive increase of SERVFAIL after April 28th 2025.

Ondřej Surý wrote: >> dig +short +nsid version.bind. txt ch @dns4.p08.nsone.net > This needs to be this: ^^^ p> You missed @ and thus you asked your local resolver. Yes, you are right. Bad on me I actually have a script that does this, but I transcribed it for posting. I get: obiwan-

Re: Massive increase of SERVFAIL after April 28th 2025.

Thank you, Ondřej! I'm getting the same answer from all my hosts: # dig +short +nsid version.bind. txt ch @dns4.p08.nsone.net "366568643ba5103a1f441fbc3c502ed2eaa0b3d9" Vincent On Thu, 1 May 2025, Ondřej Surý wrote: dig +short +nsid version.bind. txt ch @dns4.p08.nsone.net This needs to

Re: Massive increase of SERVFAIL after April 28th 2025.

On Thu, 1 May 2025, Michael Richardson wrote: Rob McEwen via bind-users wrote: > I strongly suspect that this was caused (even if indirectly?) by the MASSIVE > and many-hours-long power outages in Europe, mainly in Spain and > Portugal. That started on April 28, 2025, at approximat

Re: Massive increase of SERVFAIL after April 28th 2025.

Hi Michael, Thank you so much for chiming in! My guess is that something is in the way, and it's probably trying to attack you (or your ISP) with fake replies, but it's doing a bad job. When I do: dig +short +nsid version.bind. txt ch dns4.p08.nsone.net I get: "9.21.2-1+0~20241120.131+

Re: Massive increase of SERVFAIL after April 28th 2025.

> dig +short +nsid version.bind. txt ch @dns4.p08.nsone.net This needs to be this: ^^^ You missed @ and thus you asked your local resolver. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal w

Re: Massive increase of SERVFAIL after April 28th 2025.

Rob McEwen via bind-users wrote: > I strongly suspect that this was caused (even if indirectly?) by the MASSIVE > and many-hours-long power outages in Europe, mainly in Spain and > Portugal. That started on April 28, 2025, at approximately 6:33 a.m. Eastern > Time (ET) - and the

Re: Massive increase of SERVFAIL after April 28th 2025.

16' on RHEL/Linux using the default bundled root zone > (/var/named/named.ca) and the default root key (/etc/named.root.key). And you have DNSSEC validation turned on? > This has worked well for years until a few days ago (April 28th?) when the > amount of SERVFAIL started g

Re: Massive increase of SERVFAIL after April 28th 2025.

> /var/log/named/auth_servers.log:01-May-2025 11:05:26.694 lame-servers: info: > SERVFAIL unexpected RCODE resolving 'isis.lip6.fr//IN': 193.51.24.1#53 do some queries for these many examples, like dig @193.51.24.1 isis.lip6.fr dig @132.227.60.2 osiris.lip6.fr

Re: Massive increase of SERVFAIL after April 28th 2025.

Hi again Carlos, I really don't understand how it works for you and not for me on a RHEL host in Canada. Here's what I was trying with 8.8.8.8 and 1.1.1.1: # dnstracer -o -e -s 8.8.8.8 ftp.lip6.fr Tracing to ftp.lip6.fr[a] via 8.8.8.8, maximum of 3 retries 8.8.8.8 (8.8.8.8) # dnstracer -o -

Re: Massive increase of SERVFAIL after April 28th 2025.

fers backwards Vincent On Thu, 1 May 2025, Carlos Horowicz via bind-users wrote: Hi, For SERVFAIL to happen, ALL authoritative for the affected domains must have been in Datacenters in Spain, Portugal or southern France. I live in Spain, and as 12:33 CET I lost not only power but basic tele

Re: Massive increase of SERVFAIL after April 28th 2025.

127.0.01 www.google.com Tracing to www.google.com[cname] via 127.0.01, maximum of 3 retries 127.0.01 (127.0.0.1) Refers backwards Vincent On Thu, 1 May 2025, Carlos Horowicz via bind-users wrote: Hi, For SERVFAIL to happen, ALL authoritative for the affected domains must have been in Datac

Re: Massive increase of SERVFAIL after April 28th 2025.

on this list can help you. Rob McEwen, invaluement -- Original Message -- From vinc...@cojot.name To "Rob McEwen" Cc bind-users@lists.isc.org Date 5/1/2025 11:28:23 AM Subject Re: Massive increase of SERVFAIL after April 28th 2025. Hi Rob,   Unfortunately, as soon as I re

Re: Massive increase of SERVFAIL after April 28th 2025.

Hi, For SERVFAIL to happen, ALL authoritative for the affected domains must have been in Datacenters in Spain, Portugal or southern France. I live in Spain, and as 12:33 CET I lost not only power but basic telephony, cellular telephony and cellular data. Everything. Power generators were

Re: Massive increase of SERVFAIL after April 28th 2025.

From vinc...@cojot.name To "Rob McEwen" Cc bind-users@lists.isc.org Date 5/1/2025 11:28:23 AM Subject Re: Massive increase of SERVFAIL after April 28th 2025. Hi Rob, Unfortunately, as soon as I remove the 'forwarders' in any of my named servers, the problem comes back. T

Re: Massive increase of SERVFAIL after April 28th 2025.

Thu, 1 May 2025, Rob McEwen wrote: From vinc...@cojot.name until a few days ago (April 28th?) when the amount of SERVFAIL started going ballistic and started preventing the resolution of a lot of DNS names on the internet to the point where DNS was unusable I strongly suspect that this

Re: Massive increase of SERVFAIL after April 28th 2025.

From vinc...@cojot.name until a few days ago (April 28th?) when the amount of SERVFAIL started going ballistic and started preventing the resolution of a lot of DNS names on the internet to the point where DNS was unusable I strongly suspect that this was caused (even if indirectly?) by the

Massive increase of SERVFAIL after April 28th 2025.

has worked well for years until a few days ago (April 28th?) when the amount of SERVFAIL started going ballistic and started preventing the resolution of a lot of DNS names on the internet to the point where DNS was unusable.. # grep -c SERVFAIL auth_servers.log* auth_servers.log:34245

Re: Can not get a lick of debug information for a slew of queries that are coming back SERVFAIL

quot; 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)

Re: Can not get a lick of debug information for a slew of queries that are coming back SERVFAIL

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

Re: Can not get a lick of debug information for a slew of queries that are coming back SERVFAIL

ything 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#470

Re: Can not get a lick of debug information for a slew of queries that are coming back SERVFAIL

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

Can not get a lick of debug information for a slew of queries that are coming back SERVFAIL

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

Re: query failed (SERVFAIL) and query failed (failure)

> On 23 Dec 2024, at 13:49, Bob Harold wrote: > > I don't think it is your problem. gandi.net is having > trouble. > https://dnsviz.net/d/mail.gandi.net/dnssec/ > That would explain only gandi.net problems. I get errors all over the place. What I nee

Re: query failed (SERVFAIL) and query failed (failure)

N/A at ../../../lib/ns/query.c:7837 > client @0x7fb30fa4d168 172.17.1.200#56216 (mail.gandi.net): query failed > (SERVFAIL) for mail.gandi.net/IN/A at ../../../lib/ns/query.c:7837 > client @0x7fb30fa4d168 172.17.1.200#56216 (mail.gandi.net): query failed > (SERVFAIL) for mail.gandi.ne

Re: query failed (SERVFAIL) and query failed (failure)

): query failed (SERVFAIL) for mail.gandi.net/IN/A at ../../../lib/ns/query.c:7837 client @0x7fb30fa4d168 172.17.1.200#56216 (mail.gandi.net): query failed (SERVFAIL) for mail.gandi.net/IN/A at ../../../lib/ns/query.c:7099 client @0x7fb30fa4d168 172.17.1.200#56216 (mail.gandi.net): query failed

query failed (SERVFAIL) and query failed (failure)

(bolt.dropbox.com): query failed (failure) for bolt.dropbox.com/IN/A at ../../../lib/ns/query.c:7837 client @0x7fb30fa4d168 172.17.1.200#56216 (mail.gandi.net): query failed (SERVFAIL) for mail.gandi.net/IN/A at ../../../lib/ns/query.c:7837 client @0x7fb30fa4d168 172.17.1.200#56216 (mail.gandi.net

Re: SERVFAIL in BIND when resolving certain domains (.gov.co)

Am 01.11.2024 um 22:37:30 Uhr schrieb Marco Moock: > Both servers are reachable, via IPv6 using ICMP echo req, but the DNS > server isn't listening on UDP nor TCP. I have to catch that up: I don't receive any answer when querying UDP or TCP, also on other ports. Maybe it is also a firewall that s

Re: SERVFAIL in BIND when resolving certain domains (.gov.co)

Am 01.11.2024 um 16:30:55 Uhr schrieb Cesar Augusto Camacho Sierra: > Could this issue be related to some additional configuration in BIND > or is it possible that it is a bug in the cundinamarca.gov.co > delegation chain? I appreciate any guidance or suggestions for > additional testing. Proble

SERVFAIL in BIND when resolving certain domains (.gov.co)

;<>> DiG 9.20.3-1+ubuntu22.04.1+deb.sury.org+1-Ubuntu <<>> @localhost gevir.cundinamarca.gov.co ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46766 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORIT

RE: SERVFAIL error during the evening

nd-users-requ...@lists.isc.org You can reach the person managing the list at bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Re: rolling my own hints file

Re: SERVFAIL error during the evening

> I have configured qname to disabled for now. Once the issue is resolved, > I will set it to relaxed. I have provided a download link for the log > files and a dig +trace test for more details on this issue, which I do > not think is related to BIND or its configuration. Sami, Discussions of non

Re: SERVFAIL error during the evening

-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of bind-users digest..." > > > Today's Topics: > >

RE: SERVFAIL error during the evening

s digest..." Today's Topics: 1. Re: SERVFAIL error during the evening (Michael Batchelder) 2. Re: qname minimization: me too :( (Stephane Bortzmeyer) 3. Re: can I provide invalid HTTPS values for testing? (Stephane Bortzmeyer) --

Re: SERVFAIL error during the evening

>> Hello Michael >> Thank you for your response. Here is a pcap file and some logs. > > Hello Sami, > > Your pcap shows your resolver making thousands of queries that get > no responses (or at least the pcap does not contain them). There's > not much I can say, beyond that this does not appear to

Re: SERVFAIL error during the evening

> Hello Michael > Thank you for your response. Here is a pcap file and some logs. Hello Sami, Your pcap shows your resolver making thousands of queries that get no responses (or at least the pcap does not contain them). There's not much I can say, beyond that this does not appear to be a proble

RE: SERVFAIL error during the evening

Hello Okay, thank you Andrews BR -Message d'origine- De : Mark Andrews Envoyé : vendredi 14 juin 2024 00:33 À : RAHAL Sami SOFRECOM Cc : ML BIND Users Objet : Re: SERVFAIL error during the ev

SERVFAIL error during the evening

Sami, After you regenerate your rndc key as Mark advised, you will need to provide us with more information, as what you've sent is not sufficient to troubleshoot your symptom. As a first step, take a packet capture on the resolver that shows incoming queries from the client and the correspond

Re: SERVFAIL error during the evening

Before you do anything else change your rndc shared key as you published it. > On 14 Jun 2024, at 01:00, sami.ra...@sofrecom.com wrote: > > Hello community, > We are experiencing a resolution problem: 'SERVFAIL error'. Our environment > is BIND 9.16.48, OS: Redhat8

SERVFAIL error during the evening

Hello community, We are experiencing a resolution problem: 'SERVFAIL error'. Our environment is BIND 9.16.48, OS: Redhat8. I am sharing with you a part of the log that contains this error, named.conf file. What I've noticed is that the resolution problem is mainly related to dom

Re: occasional SERVFAIL error

This is usually a symptom of child NS being broken. It works with empty cache because of the NS records in parent work, but then child NS take over and boom! -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside you

Re: occasional SERVFAIL error

On 29.02.24 15:20, Ludovit Koren wrote: occasionally I get the following SERVFAIL error: dig www.jiscd.sk ; <<>> DiG 9.18.24 <<>> www.jiscd.sk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207 ;; flags: qr rd r

Re: occasional SERVFAIL error

> Peter Davies writes: > Hi Ludovit, >    It looks like you have two version of the jiscd.sk zone. > host -C jiscd.sk > Nameserver 2001:67c:1bd4:8080::20: >     jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 > 604800 86400 > Nameserver 195.49.191

Re: occasional SERVFAIL error

, Ludovit Koren wrote: Hi, occasionally I get the following SERVFAIL error: dig www.jiscd.sk ; <<>> DiG 9.18.24 <<>> www.jiscd.sk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207 ;; flags: qr rd ra; QUERY: 1, AN

occasional SERVFAIL error

Hi, occasionally I get the following SERVFAIL error: dig www.jiscd.sk ; <<>> DiG 9.18.24 <<>> www.jiscd.sk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0,

RE: replace "SERVFAIL" to "NXDOMAIN" with rpz

: lundi 19 juin 2023 16:56 À : Lee ; RAHAL Sami SOFRECOM Cc : bind-users@lists.isc.org Objet : Re: replace "SERVFAIL" to "NXDOMAIN" with rpz From the correct email alias this time! On Mon, 19 Jun 2023 at 16:50, Greg Choules mailto:gregchou...@googlemail.com>> wrote: Hi L

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

s REFUSED. > > Wireshark it and see. > > By the way, I have been testing this on 9.18.15 > Cheers, Greg > > > On Mon, 19 Jun 2023 at 16:10, Lee wrote: > >> On 6/19/23, sami.rahal wrote: >> > Thank you Greg >> > >> > I tested with other

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

On 6/19/23, sami.rahal wrote: > Thank you Greg > > I tested with other domain name to replace "SERVFAIL" with "NXDOMAIN" is it > not working You're missing "break-dnssec yes" on your response-policy stanza? You need something like respo

RE: replace "SERVFAIL" to "NXDOMAIN" with rpz

Thank you Greg I tested with other domain name to replace "SERVFAIL" with "NXDOMAIN" is it not working I use CentOS7 with BIND9.16.41 grep antlauncher db.rpz antlauncher.com CNAME . *.antlauncher.com CNAME . grep example

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

Hi Sami. That's not what I said. Yes, you can do this with RPZ if you want - it's all in the BIND ARM - but it's not something I would do. Cheers, Greg On Mon, 19 Jun 2023 at 12:40, wrote: > Thank you Greg > > So if I understand correctly if we receive a servfail

RE: replace "SERVFAIL" to "NXDOMAIN" with rpz

Thank you Greg So if I understand correctly if we receive a servfail return code we can not modify this code by nxdomain with the rpz configuration? Regards De : Greg Choules Envoyé : lundi 19 juin 2023 12:02 À : RAHAL Sami SOFRECOM Cc : bind-users@lists.isc.org Objet : Re: replace "SER

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

to be authoritative for "antlauncher.com". Personally I would live with the SERVFAIL because it tells you that something is wrong, not just that it doesn't exist. Then try to contact the people who own this domain and tell them it is broken. Cheers, Greg On Mon, 19 Jun 2023 at 10:

RE: replace "SERVFAIL" to "NXDOMAIN" with rpz

Hello Thank you for these details Greg, by the way I worked on a problem on one of my resolvers and there are no errors of type "SERVFAIL" currently for valid domain names but I receive servfail for this domain name "antlauncher.com" that's why I wanted to change the re

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

Hi Sami. Firstly, a couple of definitions: NXDOMAIN is a response from an authoritative server (or a resolver because it cached it). It is a positive confirmation that "this name does not exist". It means that the QNAME in the query cannot be found, for any record type. SERVFAIL is a res

RE: replace "SERVFAIL" to "NXDOMAIN" with rpz

Hello Thank you for your feedback, yes it works like that! for that does not work for a domain name that already has the return code "SERVFAIL" and we want to change this code by "NXDDOMAIN" like this domain name "antlauncher.com" regards Rahal -Message d&#x

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

text of "broken" domains): in some cases it has seemed impossible to ameliorate / mitigate SERVFAIL utilizing RPZ.I'll try to pay more attention and see if I can isolate a test case if the problem recurs. (I was kind of hoping someone would have a solution!)--Fred MorrisOn Fri, 16 Jun 2023,

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

Admittedly, since I'm writing software to do "off label" stuff with DNS I make mistakes. But I have seen things along this line (interactions between RPZ and regular resolution in the context of "broken" domains): in some cases it has seemed impossible to ameli

Re: replace "SERVFAIL" to "NXDOMAIN" with rpz

That should return a NXDOMAIN. Returning SERVFAIL is never a normal RPZ action. Something is wrong with your configuration. On Fri, Jun 16, 2023 at 1:39 PM wrote: > > > Hello > > For monitoring reasons I try to change the return code of a domain name > from "SERVFAIL"

replace "SERVFAIL" to "NXDOMAIN" with rpz

Hello For monitoring reasons I try to change the return code of a domain name from "SERVFAIL" to "NXDOMAIN" with the rpz classic configuration of BIND9.16.42 as follows: example.com IN CNAME. *.example.com IN CNAME . But it still doesn't work, I still have the me

Re: Response Policy Zone returns servfail for time.in Trigger

On 4/8/23, Fred Morris wrote: > Since one of the corner cases where RPZ is used is for mitigation of > failures of legitimate resources, I have a question... > > On Sat, 8 Apr 2023, Ondřej Surý wrote: >> time.in is currently broken - I am guessing this is the reason why are you >> trying to rewrit

Re: Response Policy Zone returns servfail for time.in Trigger

#x27; to bind-users-requ...@lists.isc.org You can reach the person managing the list at bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Re: Response Policy Zone retu

Re: Response Policy Zone returns servfail for time.in Trigger

Since one of the corner cases where RPZ is used is for mitigation of failures of legitimate resources, I have a question... On Sat, 8 Apr 2023, Ondřej Surý wrote: time.in is currently broken - I am guessing this is the reason why are you trying to rewrite the answers. RPZ does try to resolve

Re: Response Policy Zone returns servfail for time.in Trigger

working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > On 8. 4. 2023, at 16:32, Matthew Gomez wrote: > >  > > Hi, has anyone run into this before? It looks like a bug to me. > > > Summar

Re: Response Policy Zone returns servfail for time.in Trigger

anyone run into this before? It looks like a bug to me. SummaryRPZ Returns a servfail when the trigger is "time.in"BIND version usedBIND 9.18.12-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)Steps to reproduceConfigure a RPZ rule with the trigger as time.in (the action does not seem to

Response Policy Zone returns servfail for time.in Trigger

Hi, has anyone run into this before? It looks like a bug to me. Summary RPZ Returns a servfail when the trigger is "time.in" <https://gitlab.isc.org/isc-projects/bind9/-/issues/4008#bind-version-used>BIND version used BIND 9.18.12-0ubuntu0.22.04.1-Ubuntu (Extended Support

Re: SERVFAIL IPv6 debugging

WHEN: Fri Jan 20 07:01:27 GMT 2023 ;; MSG SIZE rcvd: 162 So it *may* be that this server is the culprit. You will need to gather more evidence though, to get a better idea. I would suggest that you take a packet capture of all DNS traffic, flush the cache, then make digs @ your local server until y

Re: SERVFAIL IPv6 debugging

Hi Bruce, Kindly Check the actual root cause for this "SERVFAIL" error from the following log messages of your system. /var/log/messages With Regards. K.Sanjai Gandhi. - Original Message - From: "Bruce Duncan" To: bind-users@lists.isc.org Sent: Wednesday, January

SERVFAIL IPv6 debugging

ec.europa.eu ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> -6 ec.europa.eu ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29328 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEU

Re: Ask for help with SERVFAIL

You can investigate cookies, if you think that is the issue, by setting options found in the manual. There are a few options: https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-require-server-cookie -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe

Re: Ask for help with SERVFAIL

ITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 57dc9aec153f3647010063897e4ed466568c4ab8742a ;; QUESTION SECTION: ;www.qq.com.IN A ;; QUERY SIZE: 67 ;; communications error to 119.29.29.29#53: timed out ;; no servers coul

Ask for help with SERVFAIL

'servfail' exception occurs after BIND runs for a period of time, restart bind ：servfail does not appear but，After running for some time, it still had the same 'servfail' problem #./sbin/named -VBIND 9.11.5 (Extended Support Version) running on Linux x86_64 3.10.0-51

Re: lame-servers: SERVFAIL unexpected RCODE resolving

On Sat, Nov 26, 2022 at 11:05 PM Anders Löwinger wrote: > 26-Nov-2022 09:19:13.969 lame-servers: SERVFAIL unexpected RCODE resolving > 'lists.opensuse.org/NS/IN': 195.135.221.195#53 > > Lots of errors in the zone: > > https://zonemaster.net/result/ff3dacdfc1e

Re: lame-servers: SERVFAIL unexpected RCODE resolving

26-Nov-2022 09:19:13.969 lame-servers: SERVFAIL unexpected RCODE resolving 'lists.opensuse.org/NS/IN': 195.135.221.195#53 Lots of errors in the zone: https://zonemaster.net/result/ff3dacdfc1e41199 -- MVH/Regards Anders Löwinger, Abundo AB, +46 72 206 0322 -- Visit https://lis

Re: lame-servers: SERVFAIL unexpected RCODE resolving

The .org TLD nameservers point to ns1 – ns4.opensuse.org as the authoritative nameservers for openSUSE.org. Appears that while ns2 and and ns3.opensuse.org are working, ns1 and ns4.opensuse.org return SERVFAIL when querying for openSUSE.org records. Your first sample log entry for

lame-servers: SERVFAIL unexpected RCODE resolving

Hi, Continuing in my quest to figure out why I'm seeing timeout issues from many of the same nameservers, I'm wondering if someone can help me identify the reason for these log entries: 26-Nov-2022 09:19:13.969 lame-servers: SERVFAIL unexpected RCODE resolving ' lists.ope

Re: Periodic SERVFAIL for TLD .BY

Once again, many thanks to all participants of the discussion! It's nice to know that I'm not alone with my problems. I think the topic can be considered closed. сб, 2 апр. 2022 г. в 21:38, Anand Buddhdev : > On 02/04/2022 19:47, Dzmitry Shykuts wrote: > > Hi Dzmitry, > > > I have some questions

Re: Periodic SERVFAIL for TLD .BY

On 02/04/2022 19:47, Dzmitry Shykuts wrote: Hi Dzmitry, I have some questions about this situation. What causes this "address fetching loop"? Maybe it's a bug/future in the BIND software? Misconfigured .BY zone and its servers? Problem with root servers or TLD? Why does my server have this pro

Re: Periodic SERVFAIL for TLD .BY

Am 02.04.22 um 20:30 schrieb Dzmitry Shykuts: I have read every post and am very grateful to everyone who took part in the discussion. It's good when the server is configured correctly, but here you have to use crutches for the whole .BY zone. This has never happened in my 20 years of expe

Re: Periodic SERVFAIL for TLD .BY

e suggest something? Can someone tell me which server timeout? I >> would be very happy for any help! >> >> вт, 29 мар. 2022 г. в 17:02, Dzmitry Shykuts : >> >>> Hello! Can anybody help me with periodic and critical for me SERVFAIL? >>> Cannot determine the s

Re: Periodic SERVFAIL for TLD .BY

hing? Can someone tell me which server timeout? I >>> would be very happy for any help! >>> >>> вт, 29 мар. 2022 г. в 17:02, Dzmitry Shykuts : >>>> Hello! Can anybody help me with periodic and critical for me SERVFAIL? >>>> Cannot determ

Re: Periodic SERVFAIL for TLD .BY

Am 02.04.22 um 19:47 schrieb Dzmitry Shykuts: I have some questions about this situation. What causes this "address fetching loop"? Maybe it's a bug/future in the BIND software? Misconfigured .BY zone and its servers? Problem with root servers or TLD? Why does my server have this problem, but

Re: Periodic SERVFAIL for TLD .BY

Shykuts : > >> Hello! Can anybody help me with periodic and critical for me SERVFAIL? >> Cannot determine the source of the problem. >> >> I have Debian 11.3 and BIND9 9.16.27 on it. There was no such problem >> earlier. >> >> I do request: >> >

Re: Periodic SERVFAIL for TLD .BY

On 2 Apr 2022, at 07:10, Dzmitry Shykuts wrote: > >  > Can anyone suggest something? Can someone tell me which server timeout? I > would be very happy for any help! > > вт, 29 мар. 2022 г. в 17:02, Dzmitry Shykuts : >> Hello! Can anybody help me with periodic a

Re: Periodic SERVFAIL for TLD .BY

Can anyone suggest something? Can someone tell me which server timeout? I would be very happy for any help! вт, 29 мар. 2022 г. в 17:02, Dzmitry Shykuts : > Hello! Can anybody help me with periodic and critical for me SERVFAIL? > Cannot determine the source of the problem. > > I have

Re: Periodic SERVFAIL for TLD .BY

"servfail-ttl 0" doesn't help. вт, 29 мар. 2022 г. в 18:16, Ondřej Surý : > The .by domain is kind of bonkers… > > Step 1: get nameservers for 103.by: > > $ dig +noall +authority IN NS 103.by. @a.root-servers.net > by. 172800 IN NS

Re: Periodic SERVFAIL for TLD .BY

On 29/03/2022 17:16, Ondřej Surý wrote: The .by domain is kind of bonkers… [snip] Sascha Pollok also ran into this issue with .BY. He asked me about it, and I found their setup to be very weird. TTL misalignment leads to sporadic SERVFAILs. Sascha posted about it to the dns-operations list:

Re: Periodic SERVFAIL for TLD .BY

state of the cache whether `named` is able to break out of the loop using the existing data or not. From the log, I can see that it’s hitting the SERVFAIL cache. You can disable the servfail caching with: ``servfail-ttl`` This sets the number of seconds to cache a SERVFAIL response due to DNSSEC

Re: Without IPv6 half of the queries yield SERVFAIL

On Fri, Aug 06, 2021 at 07:22:32AM +0200, sth...@nethelp.no wrote: ! > ! I tried to use this recommendation, https://kb.isc.org/docs/aa-00206, ! > ! marking all IPv6 addrs as bogus, but it does not make a difference in ! > ! behaviour. ! > ! > Update: Actually there is a difference if this recomme

Re: Without IPv6 half of the queries yield SERVFAIL

> ! I tried to use this recommendation, https://kb.isc.org/docs/aa-00206, > ! marking all IPv6 addrs as bogus, but it does not make a difference in > ! behaviour. > > Update: Actually there is a difference if this recommended > configuration is present or not - only the NXDOMAIN outcome is the > s

Re: Without IPv6 half of the queries yield SERVFAIL

On Thu, Aug 05, 2021 at 11:53:35PM +0200, Peter wrote: ! I tried to use this recommendation, https://kb.isc.org/docs/aa-00206, ! marking all IPv6 addrs as bogus, but it does not make a difference in ! behaviour. Update: Actually there is a difference if this recommended configuration is present o

Without IPv6 half of the queries yield SERVFAIL

much as: client: error: query client=0x80db45160 thread=0x80125ba00(pole.daemon.contact/A): query_gotanswer: unexpected error: SERVFAIL query-errors: info: client @0x80db45160 192.168.98.10#17919 (pole.daemon.contact): view intra: query failed (SERVFAIL) for pole.daemon.contact/IN/A at

Re: RES_TRUSTAD, was Trying again on SERVFAIL

>> So ... I can't get the glibc behaviour to mesh with the standard >> on this particular point. > > It's set in RFC 6840: I stand corrected, thanks. - Håvard ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this l

RES_TRUSTAD, was Trying again on SERVFAIL

On Thu 11/Feb/2021 17:44:20 +0100 Havard Eidnes wrote: Yeah, by the time it lands on Debian's glibc we'll have grown a long long beard. I'm still missing RES_TRUSTAD... Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD before, so I found https://man7.org/linux/man-pages/man5

Re: Trying again on SERVFAIL

The internet isn’t always on and it isn’t only composed of big tech companies with lots of resources. like Google's gmail, which has had hours-long service outages from time to time? ;-)___ Please visit https://lists.isc.org/mailman/listinfo/bind-use

Re: Trying again on SERVFAIL

> Yeah, by the time it lands on Debian's glibc we'll have grown a long > long beard. I'm still missing RES_TRUSTAD... Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD before, so I found https://man7.org/linux/man-pages/man5/resolv.conf.5.html which under "trust-ad" contains th

Re: Trying again on SERVFAIL

On Thu 11/Feb/2021 14:47:13 +0100 Ondřej Surý wrote: Mark is right. The internet isn’t always on and it isn’t only composed of big tech companies with lots of resources. The internet consists of lot small systems made by people like you and me and we don’t have infinite resources to keep every

Re: Trying again on SERVFAIL

Mark is right. The internet isn’t always on and it isn’t only composed of big tech companies with lots of resources. The internet consists of lot small systems made by people like you and me and we don’t have infinite resources to keep everything always on. And honestly I find your quote about

Re: Trying again on SERVFAIL

Machines still fall over. They take the same amount of time to fix now as they did 30 years ago. You still have to diagnose the fault. You still have to get the replacement part. You still have to potentially restore from backups. Sometimes you can switch to a standby machine which makes things

Re: Trying again on SERVFAIL

On Wed 10/Feb/2021 22:38:05 +0100 J Doe wrote: Out of curiosity, what servers have you encountered that no longer use the five day cutoff ? I didn't take note, but I read discussions on the topic. Users expect mail to be delivered almost instantly. The "warning, still trying" messages sho

  1   2   3   4   5   6   >