Ok, finally managed to get a test rig set up with wireshark and have
now seen more about what’s going on can see the pre-requisites going
over the wire.
Versions: ISC DHCPD 4.2.6, Bind 9.9.5
DHCPD sends a dynamic update with a pre-req that the name doesn’t exist
Bind replies with a fail, as
On 1 Apr 2014, at 09:52, Marty Lee ma...@maui-systems.co.uk wrote:
Ok, finally managed to get a test rig set up with wireshark and have
now seen more about what’s going on can see the pre-requisites going
over the wire.
Versions: ISC DHCPD 4.2.6, Bind 9.9.5
DHCPD sends a dynamic
Hi!
I use Bind 9.9.5 for inline signing. The zone is configured to use NSEC3
without opt-out:
example.com 0 IN NSEC3PARAM 1 0 10 BEEF
Nevertheless, most of the resulting NSEC3 records have the opt-out bit
set and insecure delegations are indeed skipped (no NSEC3
It seems Bind is a bit broken. I just removed NSEC3 and added NSEC3
again with 1 0 10 BEEF, and suddenly all NSEC3 records had the opt-out
flag clear.
Then I changed NSEC3 params to 1 1 10 BEEF. Then almost all NSEC3
records had the opt-out flag set, but two NSEC3 records still had the
flag
On Apr 1 2014, Klaus Darilion wrote:
[...]
Nevertheless, it seems there are still two bugs:
1. The NSEC3 chain is not properly cleared when switching from
non-opt-out to opt-out
2. The NSEC3PARAM record always has the opt-out flag clear, even if
opt-out is activated.
That last, at least, is
On 01.04.2014 17:09, Chris Thompson wrote:
On Apr 1 2014, Klaus Darilion wrote:
[...]
Nevertheless, it seems there are still two bugs:
1. The NSEC3 chain is not properly cleared when switching from
non-opt-out to opt-out
2. The NSEC3PARAM record always has the opt-out flag clear, even if
Nevertheless, it seems there are still two bugs:
1. The NSEC3 chain is not properly cleared when switching from
non-opt-out to opt-out
That does seem incorrect (though under the circumstances it may
be harmless). Could you please report it to bind9-b...@isc.org,
including details of how you
Hi, I have been using bind 9.9.4 for awhile suddenly looking at the looks I
see lots of socket.c errors. Looking at this it seems that bind is
complaining about the link local ipv6 address , I enabled ipv6 awhile back
and I just noticed this.
Apr 1 13:05:32 ns1 named[18769]:
So Kevin what your saying is someone using my dns created a record with
fe80::? I was under the impression that bind what trying to listen on that
subnet.
Thanks Paul
From: bind-users-bounces+razor=meganet@lists.isc.org
[mailto:bind-users-bounces+razor=meganet@lists.isc.org] On
I'm getting the same errors with bind-9.10.0b2.
Just a guess but I think it's related to using a HE IPv6 Tunnel and the
updated root servers.
On Tue, 1 Apr 2014, Paul A wrote:
Date: Tue, 1 Apr 2014 16:25:43 -0400
From: Paul A ra...@meganet.net
To: 'Kevin Darcy' k...@chrysler.com,
Im going to change bind to just listen on specified ipv6 addresses to see
what happens.
-Original Message-
From: bind-users-bounces+razor=meganet@lists.isc.org
[mailto:bind-users-bounces+razor=meganet@lists.isc.org] On Behalf Of
ca35763+b...@realsimplemail.com
Sent: Tuesday,
Just mark fe80::/10 as bogus. records do not have
enough information in them to disambiguate link-local
addresses and map them to per machine scope id's.
server fe80::/10 { bogus yes; };
Mark
In message
Thank you Mark for all your help in the mail list. I will try this instead,
so is this happening when an link local client is trying to query my server?
paul
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Tuesday, April 01, 2014 5:03 PM
To: Paul A
Cc:
Having problems with a particular insecure delegation (most are) from our
zone file, that is only not working for local users (our caching resolvers
running BIND 9.9.4-P2 or 9.9.5)
But, everybody else reports its workingits working from my other location
(FWIW, is the base bind for
14 matches
Mail list logo
