Ondřej Surý said:
> Hi Richard,
> this is not the case.
> slack.com botched their DS/DNSKEY deployment (there’s a thread on
> dns-operations about it).
Thanks for the correction, my mistake. Apologies for the list spam!
Richard.
___
Please visit https
le my BIND 9.17.18 / Ubuntu 21.04 servers are failing to resolve
> {anything}.slack.com at the moment, presumably because Slack have used
> LetsEncrypt to sign their zone. BIND is logging the following in my
> query-errors.log file:
>
> (app.slack.com): query failed (bro
their zone file.
For example my BIND 9.17.18 / Ubuntu 21.04 servers are failing to resolve
{anything}.slack.com at the moment, presumably because Slack have used
LetsEncrypt to sign their zone. BIND is logging the following in my
query-errors.log file:
(app.slack.com): query failed (broken trust
Hi Team,
Any clue why this? and I my BIND has stopped resolving
07-Jul-2021 15:59:34.588 client @0x7f1c50b7ea88 192.168.10.174#56213 (
cisco.com): query failed (broken trust chain) for cisco.com/IN/A at
query.c:7376
07-Jul-2021 15:59:34.844 client @0x7f1c5d9135a8 192.168.10.174#56214 (
cisco.com
https://bridgemode.bounceme.net/DNS%20BIND%20setup2.txt
%ProgramFiles%\ISC BIND 9\bin run CMD rndc-confgen -a
folder managed-keys in ect
file rndc.conf in etc
include "C:\Program Files\ISC BIND 9\etc\rndc.key";
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-por
rwards to 192.168.255.56 from 192.168.255.54 Main PC then does
the recursion lookup in the given view/ACL
*issue*
What happens is this after many days of working fine:
querylog yes;
client @0227150F1FE8 127.0.0.1#55768 (community.zyxel.com): view
loopbackPC: query failed (broken trust chai
Thank you, Andrews.
De : Mark Andrews
Envoyé : mercredi 29 juillet 2020 02:15:24
À : Youssef Fassi Fihri
Cc : bind-users@lists.isc.org
Objet : Re: broken trust chain
A network link that is dropping packets can trigger EDNS failures in versions of
BIND before
://dnsflagday.net for further details. [GL #150]
> On 29 Jul 2020, at 09:10,
> wrote:
>
> Hi All,
>
> I am using Bind as resolver for end users .
>
> At various time, bind logs show "broken trust chain" continuously , for
> about 20mn ~ 30 mn causing an inc
What version of BIND are you using?
John
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
youssef.fassifi...@inwi.ma
Sent: Tuesday, July 28, 2020 6:10 PM
To: bind-users@lists.isc.org
Subject: broken trust chain
Hi All,
I am using Bind as resolver for end users
Hi All,
I am using Bind as resolver for end users .
At various time, bind logs show "broken trust chain" continuously , for about
20mn ~ 30 mn causing an increase of "recursive clients" shown in "rndc status"
and a decrease of "DNS sucess rate KPI&quo
Hi Cody,
please check contents of managed-keys.bind or viewname.mkeys files in
bind working directory. It can be redirected somewhere else by
managed-keys-directory option.
These files contains state of managed keys of BIND. Its contents can be
analysed by manually or by perl script in contrib/sc
Hi Cody,
Well, your "managed-keys" section looks almost right. It should *not*
have the dlv.isc.org key in there, because the DLV has retired. The root
zone keys look right.
If you set "dnssec-validation" to "auto" (the recommended setting), then
BIND *should* be able to validate. We don't know w
On 14/10/2018 14:17, Cody Allen wrote:
> issue just started on 10/13/2018 both servers impacted at same time, clocks
> are correct, version of bind is 9.11.1 impacting recursion on internal view,
> authoritative zones work fine, servers have been running for couple of years
> or longer with zer
issue just started on 10/13/2018 both servers impacted at same time, clocks are
correct, version of bind is 9.11.1 impacting recursion on internal view,
authoritative zones work fine, servers have been running for couple of years or
longer with zero problems. most recent version of bind.keys in
/dev/rob0 wrote:
>
> > 3) Change from a forwarder to a slave and thereby become
> > authoritative and no longer have any need of DNSSEC validation on
> > this zone.
>
> Did you try with stub or static-stub?
Stub and static-stub just change how BIND finds a zone's nameservers; they
don't affect va
Dears,
Once I've tried to use stub zone to solve the same kind of problem with no
success.
John if it works for you tell us what you did.
Thanks
--
Miguel Mucio Santos Moreira
Gerente
GSR - Gerência de Serviços de Rede
(31)3339-1401
PRODEMGE - Companhia de Tecnologia da Informação do Est
On Fri, Sep 30, 2016 at 01:32:29PM -0400, jratl...@bluemarble.net wrote:
> On Fri, 30 Sep 2016 11:37:39 -0500, /dev/rob0 wrote:
> >>
> >> This seems to indicate that the servers at 10.21.0.100 and 101
> >> are telling me that stc.corp domain is DNSSEC enabled. However,
> >> the new server fails
/IN': 10.21.0.100#53
Sep 30 11:25:39 bltn-dns-04 named[2012]: validating @0x7fb51810ac60:
inelhqnagios.stc.corp A: bad cache hit (inelhqnagios.stc.corp/DS)
Sep 30 11:25:39 bltn-dns-04 named[2012]: error (broken trust chain)
resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.101#53
Thi
On Fri, 30 Sep 2016 11:37:39 -0500, /dev/rob0 wrote:
>>
>> This seems to indicate that the servers at 10.21.0.100 and 101 are
>> telling me that stc.corp domain is DNSSEC enabled. However, the new
>> server fails to find any DS or RRSIG records, so validating this
>> claim is not possible. Is
fb51810ac60: inelhqnagios.stc.corp A: bad cache hit
> > (inelhqnagios.stc.corp/DS)
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: error (broken trust chain)
> > resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.101#53
> >
> > This seems to indicate that the servers
ng @0x7fb51810ac60:
inelhqnagios.stc.corp A: bad cache hit (inelhqnagios.stc.corp/DS)
Sep 30 11:25:39 bltn-dns-04 named[2012]: error (broken trust chain)
resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.101#53
This seems to indicate that the servers at 10.21.0.100 and 101 are telling
m
[2012]: error (no valid DS)
> resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.100#53
> Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> @0x7fb51810ac60: inelhqnagios.stc.corp A: bad cache hit
> (inelhqnagios.stc.corp/DS)
> Sep 30 11:25:39 bltn-dns-04 named[2012]: err
2]: validating @0x7fb51810ac60:
inelhqnagios.stc.corp A: bad cache hit (inelhqnagios.stc.corp/DS)
Sep 30 11:25:39 bltn-dns-04 named[2012]: error (broken trust chain)
resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.101#53
This seems to indicate that the servers at 10.21.0.100 and 101 are telling
m
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
and installed Bind 9.7.2-P2 from source. We still have
many "broken trust chain" in the logs, at first glance i would say
even more. Is it possible by any means that this error is thrown
because of timeout at some stage of processing?
Many of the "broken trust chain" erro
Zitat von Mark Andrews :
Is this still with BIND 9.7.0-P1 or something more recent? If it
is still BIND 9.7.0-P1 then please upgrade. There really is no
point debugging validation failures in BIND 9.7.0-P1 anymore as the
validator has had really extensive changes since then.
Please remember,
message <20101118131400.37717e5p5tard...@webmail.kwsoft.de>,
> > lst_ho...@kwsof
> > t.de writes:
> >> We are using Bind 9.7 at the border to resolve DNS queries for a small
> >> LAN. After moving forward in using IPv6 we discovered many "broken
> >>
Zitat von Mark Andrews :
In message <20101118131400.37717e5p5tard...@webmail.kwsoft.de>,
lst_ho...@kwsof
t.de writes:
We are using Bind 9.7 at the border to resolve DNS queries for a small
LAN. After moving forward in using IPv6 we discovered many "broken
trust chain" er
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
Zitat von Mark Andrews :
In message <20101118131400.37717e5p5tard...@webmail.kwsoft.de>,
lst_ho...@kwsof
t.de writes:
We are using Bind 9.7 at the border to resolve DNS queries for a small
LAN. After moving forward in using IPv6 we discovered many "broken
trust chain" er
In message <20101118131400.37717e5p5tard...@webmail.kwsoft.de>, lst_ho...@kwsof
t.de writes:
> We are using Bind 9.7 at the border to resolve DNS queries for a small
> LAN. After moving forward in using IPv6 we discovered many "broken
> trust chain" errors in the
We are using Bind 9.7 at the border to resolve DNS queries for a small
LAN. After moving forward in using IPv6 we discovered many "broken
trust chain" errors in the bind log for non existing records. One
example is
Nov 18 01:18:21 firewall named[27580]: error (broken t
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
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?
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
Casey Deccio deccio.net> writes:
>
> 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
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
56 matches
Mail list logo
