Hi there,
On Thu, 25 Nov 2010 Brian J. Murrell wrote:
> I am going to bug report with said distro also as I hate varying from the
> "working set" because it just causes possible future problems trying to bug
> report with them. "you are not using the version we support, bla, bla, bla".
>
> So in
Jeremy C. Reed isc.org> writes:
>
> I was reading it all along, but could never reproduce.
Given the new information I have, I'll hazard to guess that you were trying to
reproduce with something newer than 9.7.0-P2.
> I thought it was
> a temporary issue.
>
> I see your new bug report. Some
On Wed, 24 Nov 2010, Brian J. Murrell wrote:
> Yeah, I was hoping to have caught the attention of a BIND developer
> here with all of this by now. Perhaps they just don't hang out here.
> Maybe I will try to find out where to ask questions that they might
> see.
I was reading it all along, b
Casey Deccio deccio.net> writes:
>
> I still don't have the answer to this.
Fair enough. I was just looking for clarification on your previous statements.
> Perhaps a BIND developer may
> have better insight into the log messages and what may be going on.
Yeah, I was hoping to have caught th
On Mon, Nov 22, 2010 at 5:28 AM, Brian J. Murrell wrote:
> Casey Deccio deccio.net> writes:
>>
>> After a review of NSEC3 showed that this particular behavior is
>> expected because org has been signed using NSEC3 with the opt-out bit
>> set.
>
> I'm afraid I'm getting a bit lost due to my real l
Casey Deccio deccio.net> writes:
>
> After a review of NSEC3 showed that this particular behavior is
> expected because org has been signed using NSEC3 with the opt-out bit
> set.
I'm afraid I'm getting a bit lost due to my real lack of understanding of the
details of DNSSEC. I wish I had the
On Mon, Nov 15, 2010 at 6:31 AM, Casey Deccio wrote:
>
> Well, I'm curious as to why you're not getting the AD bit set for the
> negative proof of existence for bondedsender.org/DS.
After a review of NSEC3 showed that this particular behavior is
expected because org has been signed using NSEC3 wi
On Mon, Nov 15, 2010 at 6:31 AM, Casey Deccio wrote:
> On Mon, Nov 15, 2010 at 3:36 AM, Brian J. Murrell
> wrote:
>>
>> Was any of that information I posted in the previous message useful? If not,
>> I'd be happy to gather some more.
>>
>
> Well, I'm curious as to why you're not getting the AD
On Mon, Nov 15, 2010 at 3:36 AM, Brian J. Murrell wrote:
>
> Was any of that information I posted in the previous message useful? If not,
> I'd be happy to gather some more.
>
Well, I'm curious as to why you're not getting the AD bit set for the
negative proof of existence for bondedsender.org/D
Brian J. Murrell interlinx.bc.ca> writes:
>
> Casey Deccio deccio.net> writes:
> >
> > Do you get a NOERROR response with the AD bit set?
>
> Yup:
> ...
Was any of that information I posted in the previous message useful? If not,
I'd be happy to gather some more.
_
Casey Deccio deccio.net> writes:
>
> On Tue, Nov 9, 2010 at 8:10 PM, Brian J. Murrell interlinx.bc.ca>
wrote:
> > $ dig @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org txt
Doh! I forgot the +dnssec.
> What happens when you run the following queries:
>
> dig +dnssec @linux -p 1053 or
On Tue, Nov 9, 2010 at 8:10 PM, Brian J. Murrell wrote:
> The only written to that file when one of those broken chain lookups happen
> is:
>
> dnssec: validating @0x2295e9b0: 41.70.55.206.sa-trusted.bondedsender.org TXT:
> starting
> dnssec: validating @0x2295e9b0: 41.70.55.206.sa-trusted.bonded
SIZE rcvd: 58
And the syslog entry:
Nov 9 23:08:39 linux named[11040]: error (broken trust chain) resolving
'41.70.55.206.sa-trusted.bondedsender.org/TXT/IN': 209.51.221.2#53
So nothing terribly interesting in the debug as far as I can see. Perhaps I
don't have enough/the cor
Casey Deccio deccio.net> writes:
>
> This can happen in a number of different ways: If any RRSIGs in the
> chain of trust are bogus, expired, or missing. If NSEC/NSEC3 records
> are not provided or are insufficient to prove that no DS records exist
> for an insecure delegation. If DS RRs do e
C/NSEC3 records
are not provided or are insufficient to prove that no DS records exist
for an insecure delegation. If DS RRs do exist, but none correspond
to any self-signing DNSKEYs in the child zone. If DNSKEYs are not
returned by the resolver.
> named error (broken trust chain) resolving '133.1
Stephane Bortzmeyer nic.fr> writes:
>
> They are not name servers of sa-trusted.bondedsender.org:
Damn. Yes, you are correct. I forgot it was sa-trusted.bondedsender.org. in
our example and stopped at bondedsender.org. However going that one more sub-
domain deeper and testing it's NSes, the
On Wed, Nov 03, 2010 at 04:00:48PM +,
Brian J. Murrell wrote
a message of 19 lines which said:
> > Another possibility: sa-trusted.bondedsender.org is badly lame (none
> > of the name servers reply), so it may trigger a bad error message from
> > BIND.
>
> Both s0.rpdns.net. and s1.rpdns.
Stephane Bortzmeyer nic.fr> writes:
>
> Indeed. Your analysis seems right. May be you have somewhere another
> trust anchor (for DLV ISC or directly for bondedsender.org?)
Hrm. I'm not sure TBH. I know I didn't install any trust anchor specifically
for bondedsender.org, but I do have "dnsse
On Wed, Nov 03, 2010 at 11:44:18AM +,
Brian J. Murrell wrote
a message of 46 lines which said:
> named error (broken trust chain) resolving '133.168.163.66.sa-
> trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
>
> Where/why does it break? Who's is breakin
expects a
> chain to exist, but the chain does not extend properly.
How does a resolver come to this expectation? What is happening that makes
this situation any different than an insecure delegation? If we take one of
the examples from my original post:
named error (broken tru
On Tue, Nov 2, 2010 at 10:21 AM, Brian J. Murrell wrote:
> Alan Clegg isc.org> writes:
>>
>> On 11/2/2010 8:11 AM, Brian J. Murrell wrote:
>> >
>> > named error (broken trust chain) resolving '133.168.163.66.sa-
>> > trusted.bondedsender.org/TXT/
Alan Clegg isc.org> writes:
>
> On 11/2/2010 8:11 AM, Brian J. Murrell wrote:
> >
> > named error (broken trust chain) resolving '133.168.163.66.sa-
> > trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
> There isn't a chain of signed DS records
On 11/2/2010 8:36 AM, Brian J. Murrell wrote:
> Alan Clegg isc.org> writes:
>>
>
> Hi Alan,
>
>> There isn't a chain of signed DS records that lead from a trust anchor
>> to the thing that you are trying to resolve.
>
> I guess I'm going to have to learn a bit more about DNSSEC in order to pars
Alan Clegg isc.org> writes:
>
Hi Alan,
> There isn't a chain of signed DS records that lead from a trust anchor
> to the thing that you are trying to resolve.
I guess I'm going to have to learn a bit more about DNSSEC in order to parse
that. :-)
Are there any good tutorials on the mechanics
On 11/2/2010 8:11 AM, Brian J. Murrell wrote:
> Since enabling DNSSEC on my resolving server I have been seeing various
> instances of the following sort of messages:
>
> named error (broken trust chain) resolving '133.168.163.66.sa-
> trusted.bondedsender.org/TXT/IN
Since enabling DNSSEC on my resolving server I have been seeing various
instances of the following sort of messages:
named error (broken trust chain) resolving '133.168.163.66.sa-
trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
named error (broken trust chain) resolving
26 matches
Mail list logo
