On 13/09/2022 21:09, Casey Deccio wrote:
After rerunning nrpe-ng with the following:
sudo strace --read=4 -F /usr/bin/python3 /usr/sbin/nrpe-ng --debug -f --config
/etc/nagios/nrpe-ng.cfg
I see the following in the debug output on Host B:
[pid 1390861] read(4, "nslookup: ./src/unix/core.c:570
At 16:05:08, a toy BIND 9.10.3-P4 recursive nameserver began answering all
queries with SERVFAIL, logging:
-=-
Mar 25 16:05:08 serni named[1525]: validating dlv.isc.org/NSEC: verify failed
due to bad signature (keyid=64263): RRSIG has expired
Mar 25 16:05:08 serni named[1525]: validating dlv
How does the new-in-9.16 dnssec-policy interact with views - in
particular for key generation/rollover?
For example, we have a zone defined in multiple views with different
contents (and thus not suitable for in-view), being signed by the same
set of keys (currently maintained by dnssec-keymgr
> In Socket.c, there are many "manager->nevents"
> for an example, manager->nevents = ISC_SOCKET_MAXEVENTS;
>
> but the manager is defined in "isc_socketmgr_t *manager "
Where the nevents member is involved, I see manager being of type
isc__socketmgr_t - note the additional underscore (in 9.1
> [...]
But I'm getting errors in bind9.
What do the errors say? Perhaps the text will point either you or us to
the cause.
Graham
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailin
I have a DNS server (which is both forwarder and authoritative NS) and I see
this odd behavior locally on the host:
dig @localhost # returns immediately with right response
dig @ # returns sometimes, timesout most of
the time
> [...]
during this behavior, I saw lots of UDP packet l
I added below line to my named.conf to include IPv6 addresses to the
forwarders list. However I am getting this error *“Sep 13 10:33:06
servername named[24778]: [ID 873579 daemon.error] /etc/named.conf:158:
expected IP address near '2001:1890:1C04:3000:0CB7:4432'”*
That's because it's not a vali
Hi Eric,
> I run bind dns server 9.9 now with around 3000query/s. I recently
> upgrade our server to Fujitsu M10-1 Solaris 10 with bind9.10.
> I feel that the server serving bind is not as fast as old one in intel
> solaris which was more than 8 years ago. I tried a few test
> and found that dig
I'm trying to settle on a (Linux) caching stub resolver configuration
and looking at lwresd, but it's not working as I expect for validation.
Given an lwresd.conf of:
-=-
options {
forwarders { 192.168.125.1; };
forward only;
dnssec-enable yes;
dnssec-validation auto;
};
lwres {};
-=-
Hi John,
> whether we can force BIND to realize same Name Resolution ( A records) ,
> i search named.conf detail and *found the command ***rrset-order fixed )
> *will be suitable *, but fixed will be support by BIND 8 ,
>
> and i use BIND 9 now , if possible , please give me some advisement
Chec
> Please confirm that if a DNS query is sent to the virtual address, the reply
> will be sourced from the virtual address. The reason for restricting BIND to
> a single address was mostly for firewall and administrative simplicity, but
> that's not a big deal as long as the same address is used bo
Hi Folks,
We use a DNAME record on lancaster.ac.uk and are seeing cases where
Microsoft's new Edge web browser is unable to display pages from web
servers reached via a DNAME in certain circumstances[1].
If you have deployed a DNAME record in a forward zone and would be
willing to help us explore
> I see that named is not listening on IPV6
> [...]
>
> What changes would be required to make Bind Listen on both IPV4 and IPV6?
Perhaps the named process has been started with the -4 argument? ('Use
IPv4 only even if the host machine is capable of IPv6')
Graham
On 17/07/2015 20:41, Leandro wrote:
Hello guys.
I was writting the reverse zone definitions you recommended some weeks ago.
What I understood is that RFC 1918/3330/5735 defines the reserved ips
for internal or experimental use. They can not be routed outside a
private network.
It means that my d
Hi Carl,
I have a client with 9.10.2-P1-RedHat-9.10.2-2.P1.fc22 on Fedora 22, on
a machine with a pppoe link with an mtu of 1492. The routers seem to be
properly fragmenting udp - it can receive large packets such as
dig www.byington.org +dnssec +bufsiz=4000 +notcp @205.147.40.34
which says:
> zone "_msdcs." {
> [..]
> file "data/db.192.168.1.2.slave";
> };
> zone "" {
> [..]
> file "data/db.192.168.1.2.slave";
> };
Both zones are being backed by the same file, so one will be overwriting
the other. This may not be the cause of the half-working situation, but
it won't be helping. D
> I configure bind to serve "example.com" domain with
>
> 1. dnssec-enable yes;
> 2. auto-dnssec maintain;
> 3. inline-signing yes;
> 4. allow-update{localhost;};
>
> Bind can fully automatic dnssec signing on example.com but If I want to
> modify a record in example.co
On 04/02/2015 13:04, Tony Finch wrote:
> Graham Clinch wrote:
>>
>> What does 'lame-servers: error (chase DS servers) resolving [...]'
>> really mean, and is it really an error?
[snip]
>> In particular, I see this for the first resolution within a static-stu
Hi Folks,
What does 'lame-servers: error (chase DS servers) resolving [...]'
really mean, and is it really an error?
It seems to be: pause the current resolution whilst I start another
round to fetch a (DS) record from the parent zone, but once that
completes, everything works out.
In particular
On 19/01/2015 19:10, Evan Hunt wrote:
> On Mon, Jan 19, 2015 at 05:56:52PM +0000, Graham Clinch wrote:
>> I think this is down to an optimisation in lib/dns/zone.c which checks
>> whether a notification is already queued to the same 'dst' address,
>> ignoring whethe
Hi List,
Using BIND 9.9, I am trying to notify two different slave views on the
same host using TSIG keys as the differentiator:
also-notify { 127.0.0.1 key slave1; 127.0.0.1 key slave2; };
It appears that only the first (slave1) receives a notify.
If I change the second address to a different
On 16/01/2015 15:36, John wrote:
> DNAME will not work with DNSSEC.
> DNAME only work with the sub-tree, while DNSSEC is at the domain level.
>
> taking the example:
> klam.biz IN DNAME klam.com
>
> DNSSEC will try to find keys for klam.biz NOT klam.com, which results i
On 14/01/2015 09:34, stefan.las...@t-systems.com wrote:
> Our customer uses a fictional Toplevel Domain[...]
Can you flip the problem on its head, by signing the fictional TLD and
deploying managed-keys (or trusted-keys) on the validating resolvers?
Graham
___
Hi Folks,
I think we can wrap this up thanks to assistance from the reporting site -
they're running BIND 9.8.1-P1 (stock package in Ubuntu 12.04 LTS).
This means they don't have the following fix, which appeared in 9.8.2b1.
3175. [bug] Fix how DNSSEC positive wildcard responses fro
> In the xfer log file, there are line of request to servers and ones of
> reply from the servers. Do they come in pairs? If do, are they next to
> each other?
Assuming we're thinking of the same xfer log (categories
xfer-in/xfer-out)...
In normal operation you could expect pairs:
* '(A|I)XFR s
Hi Casey & List folks,
> My apologies - this was actually a bug in DNSViz. The NSEC3 computation
> was being performed on the wrong name (the wrong origin was being
> applied). It should be fixed now, as shown in:
>
> http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/
> http://dnsviz.n
signature inception time
of the lancs.ac.uk NSEC3's RRSIG being yesterday (20141118125729), is
very odd...
What's going on? Both zones are being signed by the same instance of
bind and there are no interesting log messages.
Thanks,
Graham
--
Graham Clinch
Syste
or do I need to keep all of the keys ever used on the zone
in the key directory, if I wish to use dnssec-coverage?
Graham
--
Graham Clinch
Systems Programmer,
Lancaster University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
nload page suggests there is an ARM for 9.10,
linking to http://www.isc.org/downloads/bind/doc/bind-9-10/ - but that
page contains the ARM for 9.9 (and thus, no details on prefetch). The
download for 9.10b2 does contain an ARM with details on prefetch.
Graham
--
Graham Clinch
Systems Programmer,
On Mon, Mar 10, 2014 at 12:38:34PM +, Graham Clinch wrote:
This isn't quite what I see with inline-signing on 9.9.5:
If I switch from NSEC to NSEC3, my zone continues to have an NSEC chain
until the moment it has an NSEC3 chain.
If I replace an existing NSEC3 chain with a new sa
NSEC or NSEC3 records until the
operation completes!! For example, the are no signatures on the
DNSKEYs, which feels like a disaster.
Am I doing something wrong? I hope so!
Graham
--
Graham Clinch
Systems Programmer,
Lancaster University
___
P
Hi Chris & co,
Using 9.9.5, I get messages exactly like that
when updating the unsigned zone file while there are no keys.
Thanks for the confirmation - I've logged bind9 bug #35502
"inline-signed zone, with no keys, does not synchronise changes made in
master file".
Back on topic - I didn
error: zone test1.local/IN (signed): receive_secure_serial: not found
But despite showing unsigned and signed zone both with serial
2014030615, the 'signed' one actually still has 2014030610 - the serial
at the point of enabling inline-signing.
I still have to investigate the probl
Hi,
> We want to have log of what entries has been changed in the master
> (which is causing this zone transfer) at the time of zone transfer.
Two options come to mind:
1) Log the output of 'dig -t ixfr=2014030501 example.org' occasionally,
updating the serial to query for changes since the last
I'm trialling inline-signing with our provisioning system which
generates master files (rather than performing dynamic updates).
The configuration directives in use are:
inline-signing yes;
key-directory "/etc/bind/dnssec_keys/test1.local";
auto-dnssec maintain;
There i
d by opt-out, but as Chris pointed out, that
doesn't seem to be the case here).
I've left feedback for the dnsviz maintainer in the hopes that this case
can be picked up in future.
Graham
--
Graham Clinch
Systems Programmer,
Lancaster University
__
Hi List,
I'm seeing a dnssec validation error that I can't pin down, for the
domain: newsletter.postbank.de.
Neither of http://dnsviz.net/ and
http://dnssec-debugger.verisignlabs.com/ report finding a problem, but
two (ubuntu packaged) versions of bind report a failure validating the
delega
o
make the updates on its behalf, it doesn't alter the zone file itself).
so you probably want:
zone 20.10.172.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
#file "internal/db.172.10.20";
}
(and similar a change for the forward zone).
Graham
--
Graham Clinch
Sys
38 matches
Mail list logo
