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
Hi Vincent
using a conventional resolver (no rpz, no forwards, no forward zones)
from our Miami cloud:
Tracing to ftp.lip6.fr[a] via 190.185.104.10, maximum of 3 retries
190.185.104.10 (190.185.104.10)
|\___ g.ext.nic.fr [fr] (2001:0678:004c:::::0001)
| |\___ soleil.uvsq
vinc...@cojot.name wrote:
> I've been running bind (since bind 4) in my home/lab for around 3
decades. I
> went that route because I wanted: A) to be abstracted from the ISP's DNS
> servers and B) to have a local DNS cache.
Ditto.
> I run 'bind9.16' on RHEL/Linux using the defau
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
Hi everyone,
I've been running bind (since bind 4) in my home/lab for around 3 decades.
I went that route because I wanted: A) to be abstracted from the ISP's DNS
servers and B) to have a local DNS cache.
Fast forward to today and I have several servers, each with a copy of my
zones and the
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
M
Hi Rob,
Unfortunately, as soon as I remove the 'forwarders' in any of my named
servers, the problem comes back. The output in my previous message was
captured just a few minutes ago after I had disabled 'forwaders' in one of
my bind servers.
Regards,
Vincent
On Thu, 1 May 2025, Rob McEw
In that case, someone smarter and more knowledgeable on this list will
hopefully help you. But first - one last suggestion - if you find that
forwards to 3rd party servers work - but turning those off causes issues
- you should probably make sure that your "root hints" are updated, and
purge an
> 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
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+
Hi Carlos,
First of all, I'd like to say how sorry I was for those affected, as I was
watching the events unfold down south.
I've rebuilt dnstracer for RHEL9 and I don't really understand what's
going on here.. Here's the output for ftp.lip6.fr:
# dnstracer -q cname -s M.GTLD-SERVERS.NET
> /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
dig +norec @198.51.4
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 onl
Hi Rob,
Thank you for your message. Yes, I've already done all that. (got the
latest root zone, restart named each time I switch from forwarders
to non-forwarders, etc...).
I am using lip6.fr as an example because it hosts some mirrors for Fedora
Linux but I am pretty sure it's not the only si
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 -
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
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
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-
I don’t think there was anything wrong with your servers. The log messages
indicate problems with the authoritative servers.
In theory authoritative DNS servers should be able to serve content until the
zone content expires. They should be able to be powered off then rebooted and
continue to se
19 matches
Mail list logo
