error (broken trust chain) resolving
Brian J. Murrell
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.bb.barracudacentral.org/A/IN': 75.101.148.228#53
named error (broken trust chain) resolving '133.168.163.66.sa-
accredit.habeas.com/TXT/IN': 72.232.184.122#53
named error (broken trust chain) resolving
'151.168.163.66.bb.barracudacentral.org/A/IN': 75.101.148.228#53
named error (broken trust chain) resolving
'149.65.147.69.bb.barracudacentral.org/A/IN': 75.101.143.130#53
named error (broken trust chain) resolving
'133.168.163.66.bb.barracudacentral.org/A/IN': 75.101.130.80#53
named error (broken trust chain) resolving
'52.241.193.67.bb.barracudacentral.org/A/IN': 75.101.143.130#53
named error (broken trust chain) resolving
'61.94.196.66.bb.barracudacentral.org/A/IN': 75.101.148.228#53
named error (broken trust chain) resolving
'154.168.163.66.bb.barracudacentral.org/A/IN': 75.101.130.80#53
named error (broken trust chain) resolving
'106.94.196.66.bb.barracudacentral.org/A/IN': 75.101.130.80#53
named error (broken trust chain) resolving
'184.34.137.98.bb.barracudacentral.org/A/IN': 75.101.143.130#53
named error (broken trust chain) resolving
'92.45.136.98.bb.barracudacentral.org/A/IN': 75.101.148.228#53
named error (broken trust chain) resolving
'36.34.137.98.bb.barracudacentral.org/A/IN': 75.101.130.80#53
named error (broken trust chain) resolving
'154.168.163.66.bb.barracudacentral.org/A/IN': 75.101.143.130#53
named error (broken trust chain) resolving
'64.218.193.67.bb.barracudacentral.org/A/IN': 75.101.148.228#53
named error (broken trust chain) resolving '92.45.136.98.sa-
accredit.habeas.com/TXT/IN': 173.45.100.162#53
named error (broken trust chain) resolving
'148.65.147.69.bb.barracudacentral.org/A/IN': 75.101.130.80#53
named error (broken trust chain) resolving
'158.169.163.66.bb.barracudacentral.org/A/IN': 75.101.143.130#53
named error (broken trust chain) resolving
'172.65.147.69.bb.barracudacentral.org/A/IN': 75.101.148.228#53
named error (broken trust chain) resolving
'45.34.137.98.bb.barracudacentral.org/A/IN': 75.101.148.228#53
named error (broken trust chain) resolving '92.45.136.98.sa-
trusted.bondedsender.org/TXT/IN': 64.251.27.187#53
named error (broken trust chain) resolving
'40.34.137.98.bb.barracudacentral.org/A/IN': 75.101.148.228#53
named error (broken trust chain) resolving '101.43.195.217.sa-
accredit.habeas.com/TXT/IN': 64.251.27.185#53
named error (broken trust chain) resolving
'103.179.83.130.bb.barracudacentral.org/A/IN': 75.101.143.130#53
named error (broken trust chain) resolving
'101.43.195.217.bb.barracudacentral.org/A/IN': 75.101.143.130#53
named error (broken trust chain) resolving '101.43.195.217.sa-
trusted.bondedsender.org/TXT/IN': 72.232.192.162#53
I haven't been able to find an explanation of what that "broken trust chain"
message means, exactly.
Anyone care to explain?
Thanx,
b.
Alan Clegg
> 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
> '101.43.195.217.bb.barracudacentral.org/A/IN': 75.101.143.130#53
> named error (broken trust chain) resolving '101.43.195.217.sa-
> trusted.bondedsender.org/TXT/IN': 72.232.192.162#53
>
> I haven't been able to find an explanation of what that "broken trust chain"
> message means, exactly.
>
> Anyone care to explain?
There isn't a chain of signed DS records that lead from a trust anchor
to the thing that you are trying to resolve.
AlanC
Brian J. Murrell
>
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 (as opposed to howtos about
setting up and configuring trusted zones, etc.) of DNSSEC? i.e. Alice and Bob
examples.
Thanx much!
b.
Alan Clegg
Well, there is a presentation that I gave at NANOG-50..
that gives a relatively clear (I hope) explanation of what is going on
in the DNSSEC validation process.
AlanC
Brian J. Murrell
> >
> > named error (broken trust chain) resolving '133.168.163.66.sa-
> > trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
> to the thing that you are trying to resolve.
So basically it just means that one or more zones from . down to the thing I'm
trying to resolve has not been DNSSECized? i.e. no zone keys, signing, etc.?
Wouldn't that be the case for the majority of "things" I (or anyone else) would
be trying to resolve, in these early days of DNSSEC?
It just seems like I'd see way more records (i.e. pretty much everything we try
to resolve here) of the sort that I posted if that were the case. Maybe the
variation in things we try to resolve here is not as much as I'd have thought.
Am I misunderstanding?
b.
Casey Deccio
> 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 that you are trying to resolve.
>
> So basically it just means that one or more zones from . down to the thing I'm
> trying to resolve has not been DNSSECized? i.e. no zone keys, signing, etc.?
>
There is a difference between a "broken" trust chain and a trust chain
that securely "ends" before reaching the name being queried. The
latter is referred to as an insecure delegation, and, as you suggest,
will be pervasive while DNSSEC deployment grows. The result is an
answer that simply cannot be verified because there is provably no
path for validation. Such is treated by the resolver as "insecure".
However, a broken chain means that the validating resolver expects a
chain to exist, but the chain does not extend properly. This could be
because of expired signatures, missing DNSKEYs, etc. This results in
SERVFAIL.
I'm assuming the error above refers to a broken chain, but it's hard
to tell why without looking at the context, including cache contents
at the time of the failure, etc. The DNSSEC configuration (resulting
in insecure answer) looks okay from my perspective. Is the error
persistent or was it a one-time deal?
Casey
Brian J. Murrell
>
> There is a difference between a "broken" trust chain and a trust chain
> that securely "ends" before reaching the name being queried.
Ahhh. That makes sense.
> However, a broken chain means that the validating resolver 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 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 can see that org. is rife
with DNSSEC data but that bondedsender.org. is completely void of it. But
surely that would be the case of a plain insecure delegation, yes?
> I'm assuming the error above refers to a broken chain, but it's hard
> to tell why without looking at the context, including cache contents
> at the time of the failure, etc. The DNSSEC configuration (resulting
> in insecure answer) looks okay from my perspective. Is the error
> persistent or was it a one-time deal?
Well given the particular one above is a dnsbl lookup it's difficult to say if
I've even looked it up more than once.
Looking at the various occurrences I have it seems to be pervasive for reverse
addr lookups in bb.barracudacentral.org, sa-accredit.habeas.com, sa-
trusted.bondedsender.org, rbl-plus.mail-abuse.org, relays.mail-abuse.org,
dialups.mail-abuse.org, blackholes.mail-abuse.org looking for A and TXT records.
It also seems to occur quite frequently for AAAA lookups to domains like
{seal,ocsp}.verisign.net, login.facebook.com, *.slashdot.org,
newswww.bbc.net.uk, and others.
Apart from that there are a few domains in which A, MX and PTR lookups return a
broken chain, but nowhere near as much as the reverse addr lookups and the AAAA
lookups above.
Cheers,
b.
Stephane Bortzmeyer
> 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 can see that
> org. is rife with DNSSEC data but that bondedsender.org. is
> completely void of it. But surely that would be the case of a plain
> insecure delegation, yes?
Indeed. Your analysis seems right. May be you have somewhere another
trust anchor (for DLV@ISC or directly for bondedsender.org?)
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.
Brian J. Murrell
>
> Indeed. Your analysis seems right. May be you have somewhere another
Hrm. I'm not sure TBH. I know I didn't install any trust anchor specifically
for bondedsender.org, but I do have "dnssec-lookaside auto;" configured in my
bind options.
I don't know how to do the same verification of bondedsender.org given that
however.
> 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.net. seem to be responsive. The number of high-
profile domains involved seems to reduce the probability of this option.
Stephane Bortzmeyer
> > 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.net. seem to be responsive.
They are not name servers of sa-trusted.bondedsender.org:
% dig +short NS sa-trusted.bondedsender.org
spns1.rpdns.net.
ltns3.rpdns.net.
spns4.rpdns.net.
spns2.rpdns.net.
spns3.rpdns.net.
xlns17.rpdns.net.
xlns1.rpdns.net.
spns5.rpdns.net.
xlns11.rpdns.net.
eukns1.rpdns.net.
xlns18.rpdns.net.
ltns4.rpdns.net.
xlns19.rpdns.net.
xlns12.rpdns.net.
ltns2.rpdns.net.
Brian J. Murrell
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, they are all responsive.
And per my previous message, the number of domains affected makes the idea that
it's lame servers lower probability.
Thanx for keeping me honest. :-)
b.
Casey Deccio
> Casey Deccio <casey <at> deccio.net> writes:
>>
>> However, a broken chain means that the validating resolver 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:
>
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 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-
> trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
>
> Where/why does it break? Who's is breaking it? I can see that org. is rife
> with DNSSEC data but that bondedsender.org. is completely void of it. But
> surely that would be the case of a plain insecure delegation, yes?
>
Yes, bondedsender.org is an insecure delegation.
Reproducing these errors and analyzing the debug-level log messages
would be helpful since everything looks consistent from a DNSSEC
perspective, as far as I can see.
Casey
Brian J. Murrell
>
> 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 exist, but none correspond
> to any self-signing DNSKEYs in the child zone. If DNSKEYs are not
> returned by the resolver.
None of which appear to be the case for this example-case domain "sa-
trusted.bondedsender.org" as far as I have been able to determine with my
"green" DNSSEC skills.
> Yes, bondedsender.org is an insecure delegation.
So from what I have been able to learn so far, there shouldn't be any legitimate
reason why one should be getting broken trust chain errors about a domain that
has been insecurely delegated, yes? I mean there is no security in the
delegation to be broken, right?
> Reproducing these errors and analyzing the debug-level log messages
> would be helpful since everything looks consistent from a DNSSEC
> perspective, as far as I can see.
I might be able to set up a shadow bind installation that mirrors the
configuration of primary resolver here to do some debugging. Do you have any
suggestions as to which debug flags/levels to set to get some meaningful
information? Once set up, simply doing some digs with +dnssec against the
configured server should suffice, yes?
b.
Brian J. Murrell
>
> Reproducing these errors and analyzing the debug-level log messages
> would be helpful since everything looks consistent from a DNSSEC
> perspective, as far as I can see.
Well, I have attempted this. I reproduced my existing bind configuration and
added the following to logging:
category "dnssec" { "debug_log"; };
channel debug_log {
file "/var/tmp/named.debug";
severity debug 100;
print-category yes;
};
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.bondedsender.org TXT:
attempting negative response validation
dnssec: validator @0x2295e9b0: dns_validator_destroy
The dig query that produced that:
$ dig @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org txt
; <<>> DiG 9.7.1-P2 <<>> @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org
txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40957
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, 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 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 correct debugging enabled?
Cheers,
b.
Casey Deccio
> 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.bondedsender.org TXT:
> attempting negative response validation
> dnssec: validator @0x2295e9b0: dns_validator_destroy
>
> The dig query that produced that:
>
> $ dig @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org txt
>
What happens when you run the following queries:
dig +dnssec @linux -p 1053 org SOA
Do you get a NOERROR response with the AD bit set?
dig +dnssec @linux -p 1053 bondedsender.org DS
Do you get a NOERROR response with AD bit set and NSEC3 RRs and their
covering RRSIGs?
Casey
Brian J. Murrell
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 org SOA
>
> Do you get a NOERROR response with the AD bit set?
Yup:
$ dig +dnssec @linux -p 1053 org SOA
; <<>> DiG 9.7.1-P2 <<>> +dnssec @linux -p 1053 org SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44657
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;org. IN SOA
;; ANSWER SECTION:
org. 670 IN SOA a0.org.afilias-nst.info.
noc.afilias-nst.info. 2009390492 1800 900 604800 86400
org. 670 IN RRSIG SOA 7 1 900 20101124135902
20101110125902 61598 org.
cqufQ6aorG5AeM7mFR/lwm9TnLwdK9PjTH36lEo4fYBk5jH+sgLM17rG
wZD6c4/ZZHuT4ZvcQMa6pR1CgEtBLq1YAIT5zl0ncWs2pbyS2BFr35k5
B9thalfcHAGXFATzCFcVzQTVBSFy5QDPMuHpz2LTvaFc0xiE6sGqF+Fr Q14=
;; AUTHORITY SECTION:
org. 86175 IN NS a2.org.afilias-nst.info.
org. 86175 IN NS b0.org.afilias-nst.org.
org. 86175 IN NS a0.org.afilias-nst.info.
org. 86175 IN NS d0.org.afilias-nst.org.
org. 86175 IN NS c0.org.afilias-nst.info.
org. 86175 IN NS b2.org.afilias-nst.org.
org. 86175 IN RRSIG NS 7 1 86400 20101123154737
20101109144737 61598 org.
KncVCF0Fbp56Cf7xW376cEuGnNL/G19WM0GfXhWwWHuWKn2HDjx7OJMi
a0OYeoo/KlUn0pO0ORgT96vurhOkweEfdZXnpdPRRHBStfmpFZYD9wxG
FiyGounAQuso/EWSZhmwHXsFieElBQ8+J8sKY+EDo4K92uCZ5QtQAI6S 7m8=
;; Query time: 2 msec
;; SERVER: 10.75.22.3#1053(10.75.22.3)
;; WHEN: Wed Nov 10 09:02:03 2010
;; MSG SIZE rcvd: 536
> dig +dnssec @linux -p 1053 bondedsender.org DS
>
> Do you get a NOERROR response with AD bit
No AD bit set, however...
> set and NSEC3 RRs and their
> covering RRSIGs?
I do get NSEC3 and RRSIG RRs:
; <<>> DiG 9.7.1-P2 <<>> +dnssec @linux -p 1053 bondedsender.org DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18923
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bondedsender.org. IN DS
;; AUTHORITY SECTION:
org. 590 IN SOA a0.org.afilias-nst.info.
noc.afilias-nst.info. 2009390497 1800 900 604800 86400
org. 590 IN RRSIG SOA 7 1 900 20101124140403
20101110130403 61598 org.
C92vKu2HbiWyt+hgBJD5Arj4egcuL197n0AQWgnKPMQ+XdG90tGG0/5h
81dQZI/xKQQsoTA5I4oKa9qspxXqC1T1Ej7bBzFqnSrgVDpv1fI/GvIt
UWbxYL888sn9XE/IP/tHWsbY6aIoSsheYTdJP0oOuunVMkF+i4c25c0v 9Yo=
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 590 IN RRSIG NSEC3 7 2 86400
20101124140403 20101110130403 61598 org.
qUeV9GSkAD4cY9ftHxclrhrX9tzzZmUJSDXgDab78x8DoBFZ9LNKg+jG
Yvqqbk0CqOxAJKE7CGDV6WzcsBQJCdM1+3r3+L660i6jIgubxMwGpWc0
C/GXRhtYZXOuAHpVI0gHPCSoQzLqYU+QxxBepgOUUxSnLS4Zx7tftpqI zAg=
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 590 IN NSEC3 1 1 1 D399EAAB
H9PLJ7JCGLSRA48965QFJNJ3D0HC4FP5 NS SOA RRSIG DNSKEY NSEC3PARAM
t2ei86koq1j2hk8c8m677mgc115vgvu8.org. 590 IN RRSIG NSEC3 7 2 86400
20101124010350 20101110000350 61598 org.
MLy2iRpF6yKCUfcb0zxow1Dn6ky7BaZQrMZCHsfbFOsV7p5fI13JQJ2r
ihceyFt5G3VcJrnzm5E51YVlKKFEJmHIwaTUdHDTcBznqzOk+s3xm1iC
o3cBgrMMEOOQwsX7sVMHLg9NuQ395lq2GZtOrvYZWAEpCU9dOmqcSbFO 2+M=
t2ei86koq1j2hk8c8m677mgc115vgvu8.org. 590 IN NSEC3 1 1 1 D399EAAB
T2GH7ROARI9U6G24CR9QK4J52L88HKPV
;; Query time: 3993 msec
;; SERVER: 10.75.22.3#1053(10.75.22.3)
;; WHEN: Wed Nov 10 09:03:23 2010
;; MSG SIZE rcvd: 756
The above produced the following in the bind debug log [ sorry for all the line
wrapping. Stupid gmane enforces that ]:
dnssec: validating @0x20fc49b0: bondedsender.org DS: starting
dnssec: validating @0x20fc49b0: bondedsender.org DS: attempting negative
response validation
dnssec: validating @0x20fc49b0: bondedsender.org DS: nsecvalidate: creating
validator for org SOA
dnssec: validating @0x20fc7b98: org SOA: starting
dnssec: validating @0x20fc7b98: org SOA: attempting positive response
validation
dnssec: validating @0x20fc7b98: org SOA: keyset with trust 8
dnssec: validating @0x20fc7b98: org SOA: verify rdataset (keyid=61598):
success
dnssec: validating @0x20fc7b98: org SOA: marking as secure, noqname proof not
needed
dnssec: validator @0x20fc7b98: dns_validator_destroy
dnssec: validating @0x20fc49b0: bondedsender.org DS: in authvalidated
dnssec: validating @0x20fc49b0: bondedsender.org DS: resuming nsecvalidate
dnssec: validating @0x20fc49b0: bondedsender.org DS: nsecvalidate: creating
validator for h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3
dnssec: validating @0x20fc7b98: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3:
starting
dnssec: validating @0x20fc7b98: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3:
attempting positive response validation
dnssec: validating @0x20fc7b98: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3:
keyset with trust 8
dnssec: validating @0x20fc7b98: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3:
verify rdataset (keyid=61598): success
dnssec: validating @0x20fc7b98: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org NSEC3:
marking as secure, noqname proof not needed
dnssec: validator @0x20fc7b98: dns_validator_destroy
dnssec: validating @0x20fc49b0: bondedsender.org DS: in authvalidated
dnssec: validating @0x20fc49b0: bondedsender.org DS: resuming nsecvalidate
dnssec: validating @0x20fc49b0: bondedsender.org DS: nsecvalidate: creating
validator for t2ei86koq1j2hk8c8m677mgc115vgvu8.org NSEC3
dnssec: validating @0x20fc7b98: t2ei86koq1j2hk8c8m677mgc115vgvu8.org NSEC3:
starting
dnssec: validating @0x20fc7b98: t2ei86koq1j2hk8c8m677mgc115vgvu8.org NSEC3:
attempting positive response validation
dnssec: validating @0x20fc7b98: t2ei86koq1j2hk8c8m677mgc115vgvu8.org NSEC3:
keyset with trust 8
dnssec: validating @0x20fc7b98: t2ei86koq1j2hk8c8m677mgc115vgvu8.org NSEC3:
verify rdataset (keyid=61598): success
dnssec: validating @0x20fc7b98: t2ei86koq1j2hk8c8m677mgc115vgvu8.org NSEC3:
marking as secure, noqname proof not needed
dnssec: validator @0x20fc7b98: dns_validator_destroy
dnssec: validating @0x20fc49b0: bondedsender.org DS: in authvalidated
dnssec: validating @0x20fc49b0: bondedsender.org DS: resuming nsecvalidate
dnssec: validating @0x20fc49b0: bondedsender.org DS: looking for relevant NSEC3
dnssec: validating @0x20fc49b0: bondedsender.org DS: looking for relevant NSEC3
dnssec: validating @0x20fc49b0: bondedsender.org DS: looking for relevant NSEC3
dnssec: validating @0x20fc49b0: bondedsender.org DS: NSEC3 indicates potential
closest encloser: 'org'
dnssec: validating @0x20fc49b0: bondedsender.org DS: NSEC3 at super-domain org
dnssec: validating @0x20fc49b0: bondedsender.org DS: looking for relevant NSEC3
dnssec: validating @0x20fc49b0: bondedsender.org DS: NSEC3 proves name does not
exist: 'bondedsender.org'
dnssec: validating @0x20fc49b0: bondedsender.org DS: NSEC3 indicates optout
dnssec: validating @0x20fc49b0: bondedsender.org DS: in checkwildcard: *.org
dnssec: validating @0x20fc49b0: bondedsender.org DS: looking for relevant NSEC3
dnssec: validating @0x20fc49b0: bondedsender.org DS: NSEC3 at super-domain org
dnssec: validating @0x20fc49b0: bondedsender.org DS: looking for relevant NSEC3
dnssec: validating @0x20fc49b0: bondedsender.org DS: in checkwildcard: *.org
dnssec: validating @0x20fc49b0: bondedsender.org DS: nonexistence proof(s) found
dnssec: validator @0x20fc49b0: dns_validator_destroy
dnssec: validating @0x20fc49b0: 94.114.201.117.in-addr.arpa PTR: starting
dnssec: validating @0x20fc49b0: 94.114.201.117.in-addr.arpa PTR: attempting
negative response validation
dnssec: validating @0x20fc49b0: 94.114.201.117.in-addr.arpa PTR: nsecvalidate:
creating validator for 117.in-addr.arpa SOA
dnssec: validating @0x20fc7b98: 117.in-addr.arpa SOA: starting
dnssec: validating @0x20fc7b98: 117.in-addr.arpa SOA: attempting positive
response validation
dnssec: validating @0x20fc7b98: 117.in-addr.arpa SOA: get_key: creating fetch
for 117.in-addr.arpa DNSKEY
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: starting
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: looking for DLV
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: plain DNSSEC returns
unsecure (.): looking for DLV
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: looking for DLV 117.in-
addr.arpa.dlv.isc.org
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: DNS_R_COVERINGNSEC
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: covering nsec: not in
range
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: finddlvsep: creating
fetch for 117.in-addr.arpa.dlv.isc.org DLV
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: DLV lookup: wait
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: starting
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: attempting
negative response validation
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: nsecvalidate:
creating validator for dlv.isc.org SOA
dnssec: validating @0x21472f58: dlv.isc.org SOA: starting
dnssec: validating @0x21472f58: dlv.isc.org SOA: attempting positive response
validation
dnssec: validating @0x21472f58: dlv.isc.org SOA: keyset with trust 8
dnssec: validating @0x21472f58: dlv.isc.org SOA: verify rdataset
(keyid=64263): success
dnssec: validating @0x21472f58: dlv.isc.org SOA: marking as secure, noqname
proof not needed
dnssec: validator @0x21472f58: dns_validator_destroy
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: in
authvalidated
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: resuming
nsecvalidate
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: nsecvalidate:
creating validator for 6.12.174.109.in-addr.arpa.dlv.isc.org NSEC
dnssec: validating @0x21472f58: 6.12.174.109.in-addr.arpa.dlv.isc.org NSEC:
starting
dnssec: validating @0x21472f58: 6.12.174.109.in-addr.arpa.dlv.isc.org NSEC:
attempting positive response validation
dnssec: validating @0x21472f58: 6.12.174.109.in-addr.arpa.dlv.isc.org NSEC:
keyset with trust 8
dnssec: validating @0x21472f58: 6.12.174.109.in-addr.arpa.dlv.isc.org NSEC:
verify rdataset (keyid=64263): success
dnssec: validating @0x21472f58: 6.12.174.109.in-addr.arpa.dlv.isc.org NSEC:
marking as secure, noqname proof not needed
dnssec: validator @0x21472f58: dns_validator_destroy
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: in
authvalidated
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: looking for
relevant nsec
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: nsec range ok
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: resuming
nsecvalidate
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: nsecvalidate:
creating validator for 0.3.0.2.9.2.3.1.2.7.9.4.e164.arpa.dlv.isc.org NSEC
dnssec: validating @0x21471f50: 0.3.0.2.9.2.3.1.2.7.9.4.e164.arpa.dlv.isc.org
NSEC: starting
dnssec: validating @0x21471f50: 0.3.0.2.9.2.3.1.2.7.9.4.e164.arpa.dlv.isc.org
NSEC: attempting positive response validation
dnssec: validating @0x21471f50: 0.3.0.2.9.2.3.1.2.7.9.4.e164.arpa.dlv.isc.org
NSEC: keyset with trust 8
dnssec: validating @0x21471f50: 0.3.0.2.9.2.3.1.2.7.9.4.e164.arpa.dlv.isc.org
NSEC: verify rdataset (keyid=64263): success
dnssec: validating @0x21471f50: 0.3.0.2.9.2.3.1.2.7.9.4.e164.arpa.dlv.isc.org
NSEC: marking as secure, noqname proof not needed
dnssec: validator @0x21471f50: dns_validator_destroy
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: in
authvalidated
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: resuming
nsecvalidate
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: in
checkwildcard: *.in-addr.arpa.dlv.isc.org
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: looking for
relevant nsec
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: NSEC does not
cover name, before NSEC
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: looking for
relevant nsec
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: nsec range ok
dnssec: validating @0x2146b048: 117.in-addr.arpa.dlv.isc.org DLV: nonexistence
proof(s) found
dnssec: validator @0x2146b048: dns_validator_destroy
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: in dlvfetched: ncache
nxdomain
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: looking for DLV in-
addr.arpa.dlv.isc.org
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: looking for DLV
arpa.dlv.isc.org
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: DLV arpa found
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: dlv_validator_start
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: restarting using DLV
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: attempting positive
response validation
dnssec: validating @0x214348b0: 117.in-addr.arpa DNSKEY: validatezonekey:
creating fetch for 117.in-addr.arpa DS
b.
Brian J. Murrell
>
> 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
>
> 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/DS. What happens if
you disable DLV and run the DS query again?
Casey
Casey Deccio
I just realized that your debugging output involving DLV lookups is
related to a different query and shouldn't affect the result of
bondedsender.org/DS. However, querying the original TXT RR with DLV
disabled might also give more insight.
Casey
Casey Deccio
>
> 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 with the opt-out bit
set. RFC 5155, section 9.2:
http://tools.ietf.org/html/rfc5155#section-9.2
Casey
Brian J. Murrell
> 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 time to really sit down and understand the
concepts in complete detail. :-(
So does the RFC reference just explain why the AD bit (i.e. and not the bigger
problem of the spew of log entries from named) is not set or does that explain
the entire problem I am seeing (namely the continuous log spew from named)?
Cheers,
b.
Casey Deccio
> 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 the time to really sit down and understand the
> concepts in complete detail. :-(
>
> So does the RFC reference just explain why the AD bit (i.e. and not the bigger
> problem of the spew of log entries from named) is not set
yes, I was clarifying that my particular observation with respect to
the AD bit was not a useful insight into troubleshooting the other
issues.
> or does that explain
> the entire problem I am seeing (namely the continuous log spew from named)?
>
I still don't have the answer to this. Perhaps a BIND developer may
have better insight into the log messages and what may be going on.
Casey
Brian J. Murrell
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 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.
Thanx!
b.
Jeremy C. Reed
> 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 could never reproduce. I thought it was
a temporary issue.
I see your new bug report. Someone will follow up soon.
Brian J. Murrell
>
> 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. Someone will follow up soon.
That can probably be closed out (I will follow-up on it as soon as I'm done
here) but I have taken a variance from my distro's prescribed BIND version of
9.7.0-P2 and built a 9.7.2-P2 and after about 12h of data collecting the
problem seems to be gone.
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 it seems that perhaps it was a bug/situation that was cleared up
between 9.7.0-P2 and 9.7.2-P2.
Thanx to all that persevered through all of this. I really should have just
bitten the bullet and upgraded in the first place.
Cheers,
b.