> From: "Havard Eidnes via bind-users"
> Sent: Thursday, March 13, 2025 7:21:32 AM
> The reason is that the "how to reproduce the problem" bit is
> quite fuzzy.
Yeah. :-( In general, without logs or similar, it is impossible to diagnose
this sort of problem by DNS results alone. Unless zon
On 3/13/25 12:21, Havard Eidnes via bind-users wrote:
I wondered a while whether this would be more appropriate to post
here or as an issue in ISC's gitlab, but came to the conclusion
that for now the best place would be here. The reason is that
the "how to reproduce the problem" bit is quite fu
Hi,
I wondered a while whether this would be more appropriate to post
here or as an issue in ISC's gitlab, but came to the conclusion
that for now the best place would be here. The reason is that
the "how to reproduce the problem" bit is quite fuzzy.
If someone from ISC wants this reported as a
Thanks to those who replied to my earlier email. I've straightened out
my routing issues but I'm still having name resolution failures.
Since then I've upgraded to OpenBSD 7.6 with BIND 9.20.2 from packages,
with no change.
I'm getting frequent lookup failures on most
Are you running NTP? (e.g. is your time correct on the device running bind?)
Forwarding to another recursive resolver or using hints?
I'm running Bind 9.18.29 on FreeBSD 14.1-p4 on a RPI4. No jails. (It runs
on RPI5 also)
I also have it setup to run unbound 1.21.0 for comparison. (BTW, that works
Hi Steven.
As you said, `listen-on {...;};` tells BIND which addresses to register for
incoming traffic. This can be a list, not just one address. Any query
received on (say) 10.0.0.1 will be responded to from the same address.
It is possible to choose which address to use for outgoing queries/fet
On 13/09/2024 16:14, Steven Shockley wrote:
Is there a way to tell BIND to listen (and respond) on a specific
interface? I already have listen-on { 10.0.0.1; }; (vlan101 IP) in the
config with nothing else listening.
BIND will send the response with a source address of 10.0.0.1, and it
hand
On 9/12/2024 9:20 PM, Steven Shockley wrote:
I'll try to run some tcpdumps inbound and outbound tomorrow, traffic
should be pretty light.
I did find something interesting that may or may not be related.
The machine is also the Internet gateway. One NIC has a vlan interface
for each network;
On 9/11/2024 2:11 AM, Ondřej Surý wrote:
Does this happen only with this specific domain or it happens with different
names too?
Thanks for the reply. It happens with many domains.
If you can reliably reproduce the problem, you can either bump up the debugging
(-d 9 argument to named) or c
Hi Steven,
sorry to hear that.
Does this happen only with this specific domain or it happens with different
names too?
If you can reliably reproduce the problem, you can either bump up the debugging
(-d 9 argument to named) or capture the traces.
Are there any other log entries preceding the
Hi, I'm running BIND 9.18.29 on OpenBSD 7.5, installed from ports. It
does recursion and resolving for a small home network.
Multiple times a day, clients will make a DNS request that fails. The
web browser will say it can't find the address (DNS lookup failure).
Hitting retry a couple of ti
named is looking for K files that match the DNSKEY records in the zone and
is not finding them. Removing K files too early or having them in the
wrong place will produce these errors.
You can work out which DNSKEY record matches the number with dig +rrcomments
or dig +multiline.
[beetle:~/git/bi
I've had bind 9.9.4 doing dnssec for a few years now. All the zones are
configured with:
key-directory "/var/named/keys";
auto-dnssec maintain;
inline-signing yes;
I just added a bunch of zones, and 8 of them are failing with:
dns_dnssec_findzonekeys2: error reading priv
13 matches
Mail list logo
