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 the end
Jeremy C. Reed jreed at 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.
Casey Deccio casey at 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
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, but
Casey Deccio casey at 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
Brian J. Murrell brian at interlinx.bc.ca writes:
Casey Deccio casey at 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 casey at deccio.net writes:
On Tue, Nov 9, 2010 at 8:10 PM, Brian J. Murrell brian at 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
, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;41.70.55.206.sa-trusted.bondedsender.org. IN TXT
;; Query time: 43 msec
;; SERVER: 10.75.22.3#1053(10.75.22.3)
;; WHEN: Tue Nov 9 23:08:39 2010
;; MSG SIZE rcvd: 58
And the syslog entry:
Nov 9 23:08:39 linux named[11040]: error (broken trust
On Tue, Nov 9, 2010 at 8:10 PM, Brian J. Murrell br...@interlinx.bc.ca 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:
, 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 trust chain) resolving '133.168.163.66.sa
On Wed, Nov 03, 2010 at 11:44:18AM +,
Brian J. Murrell br...@interlinx.bc.ca 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 breaking it? I
Stephane Bortzmeyer bortzmeyer at nic.fr writes:
Indeed. Your analysis seems right. May be you have somewhere another
trust anchor (for DLV at 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
On Wed, Nov 03, 2010 at 04:00:48PM +,
Brian J. Murrell br...@interlinx.bc.ca 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.
Stephane Bortzmeyer bortzmeyer at 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
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.168.163.66.sa
Casey Deccio casey at 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
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
'173.65.147.69
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': 173.45.100.146#53
Alan Clegg aclegg at 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
On 11/2/2010 8:36 AM, Brian J. Murrell wrote:
Alan Clegg aclegg at 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
Alan Clegg aclegg at 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 that lead from a trust anchor
to the thing
On Tue, Nov 2, 2010 at 10:21 AM, Brian J. Murrell br...@interlinx.bc.ca wrote:
Alan Clegg aclegg at 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
22 matches
Mail list logo
