> Seeing this after upgrading to 9.6.2-P1.
>
> We've made no other changes to the host or any configuration files, etc.
>
> /var/named # dnssec-signzone -g -o xxx.xxx.gov.au db.xxx.xxx.gov.au
> dnssec-signzone: fatal: no self signed KSK's found
When dnssec-signzone has finished signing, it chec
On Tue, Mar 30, 2010 at 01:50:23PM +1100, chris liesfield wrote:
> Here's the output ...
> /var/named # named-checkzone sro.vic.gov.au db.sro.vic.gov.au
> zone sro.vic.gov.au/IN: loaded serial 2010033001
> OK
>
> I chose level 7 debugging to yield as much information as possible, so sorry
> for th
On Tue, Mar 30, 2010 at 12:39:58PM +1100, chris liesfield wrote:
> Seeing this after upgrading to 9.6.2-P1.
> We've made no other changes to the host or any configuration files, etc.
> /var/named # dnssec-signzone -g -o xxx.xxx.gov.au db.xxx.xxx.gov.au
> dnssec-signzone: fatal: no self signed KSK'
In article ,
Matus UHLAR - fantomas wrote:
> Hello,
>
> on one of my nameservers I see many of these messages in log files:
>
> Mar 29 07:59:07 gtssk1 named[5012]: security: error: client
> 195.168.29.200#65293: view gtsi: check-names failure
> dns_registration.in.nextra.sk/A/IN
>
> I'm curio
Thanks for the response Kevin. However when I flush the cache and snoop the
interface on this recursive DNS I don't see any request going to the nameserver
(ns1.nse.spx.net) of the child zone. It appears it is just displaying the
output it received from the ns1.spx.net nameserver. I don't have a
Seeing this after upgrading to 9.6.2-P1.
We've made no other changes to the host or any configuration files, etc.
/var/named # dnssec-signzone -g -o xxx.xxx.gov.au db.xxx.xxx.gov.au
dnssec-signzone: fatal: no self signed KSK's found
No idea what's going on here and we need advice on how to go a
In message <1269885784.31597.68.ca...@mjenet.posix.co.za>, Mark Elkins writes:
> On Mon, 2010-03-29 at 11:17 +0200, Mark Elkins wrote:
> > I'm trying to come up with an interim solution for my ISP's DNS
> > Recursive Resolver that is DNSSEC aware.
> >=20
> > My thoughts so far:-
> > Use BIND 9.6.1
The nameserver is recursive (RA in the header of the response means
"Recursion Available"). It recursed to the nameservers of the child
zone, which returned NXDOMAIN for the name mil.nse.spx.net, and it
passed that answer back.
Everything is working the way it is supposed to, including your ne
Hello all,
I'm running BIND 9.6.1-P1 on a Solaris box. This DNS (ns1.spx.net) is
authoritative to domain spx.net (this is just example). And I'm trying to
delegate nse.spx.net to ns1.nse.spx.net. I think I have configured correctly
but when I run a dig from a different DNS node for a subdoamin
On Mon, 2010-03-29 at 11:17 +0200, Mark Elkins wrote:
> I'm trying to come up with an interim solution for my ISP's DNS
> Recursive Resolver that is DNSSEC aware.
>
> My thoughts so far:-
> Use BIND 9.6.1-P3 (this is the latest version named that Gentoo Linux
> gives me).
Ouch! - bitten by the si
> I have seen this happen when bind for some reason (eg mtu issues with
> vpn) cannot query for the DLV key at dlv.isc.org. I have not figured
> out the exact failure mode there. Check the logs to see errors for DNSKEY
> queries for dlv.isc.org to see if this is happening here too. However in
> tha
> > Yes, I agree freebsd.org is insecure, but I still want to be able to
> > resolve it :-)
>
> The point was, you should not be getting DNSSEC-related errors from
> a domain that is not secured.
I disagree. In order for a validating resolver to resolve freebsd.org
(or any other insecure domain
On 01/-10/37 13:59, Barry Margolin wrote:
Or do I need to provide glue records in the delegated zone ... probably
not, but thought I'd better ask.
The only time you're required to provide glue is when a subzone is
delegated to a nameserver whose name is in the subzone, to prevent a
chicken-a
Hello,
Sufficient resources on the Internet may be helpful.
For example, http://www.indelible.org/ink/classless/
Searching for "RFC2317" or "classless in-addr.arpa delegation" may result in
additional references.
Hope this helps.
- Original Message
From: Alex
To: bind-users@lists.i
On Mon, 29 Mar 2010, Matthew Pounsett wrote:
On 2010/03/28, at 18:48, Roy Badami wrote:
configured). The queries are resulting in SERVFAIL, and I'm pretty
sure the failures are DNSSEC-related, as when I've seen problems as
they occur (dig failing from the command line) then repeating the
quer
On Sun, 28 Mar 2010, Nate Itkin wrote:
28-Mar-2010 21:02:27.467 dnssec: warning: client 200.160.7.134#6363: view
external: expected covering NSEC3, got an exact match
The error suggests the following happened. The client asked for something
that did not exist. The server then hashes the hostn
On 2010/03/29, at 06:04, Roy Badami wrote:
>
>> It looks to me like your example, freebsd.org, is insecure.
>
> Yes, I agree freebsd.org is insecure, but I still want to be able to
> resolve it :-)
The point was, you should not be getting DNSSEC-related errors from a domain
that is not secu
> It looks to me like your example, freebsd.org, is insecure.
Yes, I agree freebsd.org is insecure, but I still want to be able to
resolve it :-)
.org is signed with NSEC3 and (I think, but could be misremembering)
is using opt-out. org is registered in DLV, so BIND still has to do
some work
I'm trying to come up with an interim solution for my ISP's DNS
Recursive Resolver that is DNSSEC aware.
My thoughts so far:-
Use BIND 9.6.1-P3 (this is the latest version named that Gentoo Linux
gives me).
In order to fetch both iTAR and DLV signatures - use a patched version
of WGET that is dnss
Hello,
on one of my nameservers I see many of these messages in log files:
Mar 29 07:59:07 gtssk1 named[5012]: security: error: client
195.168.29.200#65293: view gtsi: check-names failure
dns_registration.in.nextra.sk/A/IN
I'm curious of the reason because they are going to sevrer authoritative
Sorry about that truncated subject line. Let's try that again.
If someone would kindly explain what this error message means, I would
appreciate it. I'm running BIND 9.6.2-P1 and I get quite a few of these:
28-Mar-2010 21:02:27.467 dnssec: warning: client 200.160.7.134#6363: view
external: expe
On 2010/03/28, at 18:48, Roy Badami wrote:
> configured). The queries are resulting in SERVFAIL, and I'm pretty
> sure the failures are DNSSEC-related, as when I've seen problems as
> they occur (dig failing from the command line) then repeating the
> query with the CD bit allowed it to succeed.
If someone would kindly explain what this error message means, I would
appreciate it. I'm running BIND 9.6.2-P1 and I get quite a few of these:
28-Mar-2010 21:02:27.467 dnssec: warning: client 200.160.7.134#6363: view
external: expected covering NSEC3, got an exact match
Thank you,
Nate Itkin
23 matches
Mail list logo
