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
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
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
Casey Deccio casey at 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 expects a
chain to exist, but the
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
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
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
Casey Deccio casey at deccio.net writes:
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
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
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:
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
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
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.
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I am having is that when I make a dynamic
On 11-06-24 09:57 AM, Lyle Giese wrote:
It's expected behavior in a way.
Given your explanation, indeed. :-)
You are probably making this change in
the internal view and the internal named process knows about the change
and reloads the zone.
The external view's process is unaware of
On 11-06-24 12:39 PM, Evan Hunt wrote:
You can specify the view in the reload command:
$ rndc reload example.com in external
But reload doesn't work for dynamic zones:
# rndc reload rbl.interlinx.bc.ca in greatunwashed
rndc: 'reload' failed: dynamic zone
and since I want the same
On 11-06-24 01:47 PM, Evan Hunt wrote:
Do the internal and external versions *both* need to be dynamic?
No, only the internal in fact.
I'd expect it to work okay if you had only one of them dynamic, and
sent periodic reload commands to the other one.
Yeah. I got the master/slave approach
On 11-06-24 03:19 PM, David Sparro wrote:
Do you have control of the update process.
Sure.
You could potentially send
and update to both views (in other words, send two updates).
How do I, with nsupdate, specify which view's zone I want to update?
I think
you'd need separate zone files
On 12-05-02 09:29 AM, Mark Andrews wrote:
The zones are signed. Possible reason are:
* a firewall blocking EDNS queries.
This shouldn't be the case. Outgoing traffic from the bind9 server
being used here should be completely unfettered.
* using a non DNSSEC enabled forwarder so you
On 12-05-02 09:29 AM, Mark Andrews wrote:
* a firewall blocking EDNS queries.
* using a non DNSSEC enabled forwarder so you don't get signatures.
* a firewall blocking fragmented UDP and named falling back to
plain DNS.
* other packet loss causing named to fallback to plain DNS.
Given
On 12-05-15 09:01 AM, Phil Mayers wrote:
Sorry about the way delayed response. There seems to be some confusion
about which list/group gmane is following.
Isn't it more likely it's a local problem?
Indeed. But what, is the question (and I do have the answer, now --
see below).
Which
On 12-07-20 08:34 AM, Brian J. Murrell wrote:
The problem here seems to be fragmented UDP.
I seem to have misdiagnosed this due to tcpdump peculiarities. I only
initially saw/suspected the problem since my capture for port 53
packets was including (only the first) ipv4 fragments. When adding
On 12-07-20 09:11 AM, Phil Mayers wrote:
Or, what happens if you start bind up in debug mode and run the query?
There will be a lot of output, but I've found most problems to be fairly
obvious if you read through it.
Yeah, there is a lot of output. Too big of a haystack for me to find
the
On 12-07-20 10:42 AM, Mark Andrews wrote:
The NS RRset is the delegation records and as such has no RRSIGs.
If you turn on minimal-responses the NS rrset won't be added and
AD won't be cleared. AD is only set to 1 if all the records in the
answer and authority sections are marked as
On 12-07-20 07:16 PM, Mark Andrews wrote:
dnssec-validation auto;
Well, this seems to have done the trick. Changing it from yes to auto
has eliminated most (almost all in fact) of the validation
warnings/errors I was getting in my logs.
tells named to use the compiled
in
I've come across something interesting in my named logs:
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
On 12-07-24 07:05 AM, Brian J. Murrell wrote:
I've come across something interesting in my named logs:
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query
On 12-07-24 07:53 AM, Phil Mayers wrote:
On 24/07/12 12:05, Brian J. Murrell wrote:
Change ISP?
A. You must be one of those people who live in that part of the
world where internet service providing is not a monopoly, duopoly or at
best a price-fixing oligopoly. :-) Unfortunately
Trying to follow an example I found of manually verifying a name's
DNSSEC records I did the following:
# dig . DNSKEY | grep -Ev '^($|;)' root.keys
# dig +sigchase +trusted-key=./root.keys www.eurid.eu. A
That resulted in some errors but more importantly the following in my
syslog:
Mar 23
I have a BIND (9.9.4)[1] server that runs well most of the time, but
periodically it will start returning SERVFAIL for very high-level
domains such as *.google.com, *.gstatic.com, *.github.com, etc. It
seems to happen most frequently with Google domains, but I wonder if
that is just a reflection
On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote:
>
> Does the time to recovery correspond to the lame-ttl setting?
I am not sure. I'm not always aware of when it starts. I guess if I
am running a trace level permanently the log would tell me though.
> The default
> is 10 minutes - try
OK. I now have named trace logging
http://brian.interlinx.bc.ca/named.run.log
and a packet dump:
http://brian.interlinx.bc.ca/dns-packets.txt
that demonstrates how BIND is getting .com referrals from the root
servers when doing a query for www.google.com and then doing nothing
with those
On Thu, 2018-01-18 at 17:46 +, Tony Finch wrote:
> Brian J. Murrell <br...@interlinx.bc.ca> wrote:
> > On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote:
> > >
> > > The default is 10 minutes - try reducing it and see if the outage
> > >
On Fri, 2018-01-19 at 15:22 +, Tony Finch wrote:
>
> You don't have any weird middleboxes between your resolver and the
> Internet, do you?
I don't believe so. Not entirely sure what "weird middleboxes" refers
to in this context though. And by resolver are you referring to my
BIND9 server
On Fri, 2018-01-19 at 14:54 +, Tony Finch wrote:
>
> Those responses look like referrals from the root servers to the .com
> servers;
Ahhh. Right. That makes sense.
> I would expect you to see `named` repeating the queries as it
> follows the iterative resolution algorithm.
Indeed. I
On Mon, 2018-01-22 at 12:04 +, Tony Finch wrote:
>
> That indicates that it has already marked the servers as lame, so the
> packet trace isn't going to tell you what caused the lameness.
OK.
> The thing to look out for is the minutes before the outage starts -
> see
> what kind of failures
Here's a new most interesting data point.
All of these outages happen right after a DHCP client connect and sends
a DDNS update to BIND.
It would be an interesting experiment to isolate the zone that receives
DDNS updates for the DHCP clients onto a separate server to see if that
makes this
On Mon, 2018-01-22 at 12:45 +, Tony Finch wrote:
>
> lame-servers is also a log category, and tends to be quite noisy
> about
> various problems :-)
Turns out I do already have lame server logging enabled. I.e.:
20-Jan-2018 12:01:37.053 lame server resolving 'backup-ns.yn.cninfo.net' (in
On Tue, 2018-01-23 at 13:38 +0100, Reindl Harald wrote:
>
> pretty sure it's possible and likely not much different than the
> unbound-sample below which asks a rbldnsd on port 1043 on the same
> machine
>
> stub-zone:
> name: "zone-name."
> stub-addr: 127.0.0.1@1053
That's the sort of
On Wed, 2018-01-17 at 10:45 -0500, Brian J. Murrell wrote:
> I have a BIND (9.9.4)[1] server that runs well most of the time, but
> periodically it will start returning SERVFAIL for very high-level
> domains such as *.google.com, *.gstatic.com, *.github.com, etc. It
> seems to
On Mon, 2018-01-22 at 12:04 +, Tony Finch wrote:
>
> The thing to look out for is the minutes before the outage starts -
> see
> what kind of failures you get.
So, taking this approach, looking for the first occurrence of just any
one of the names ns[1-4].google.com prior to the A/
On Mon, 2018-01-22 at 16:10 +, Tony Finch wrote:
>
> You should make sure it is enabled, because there are vital clues in
> those
> log lines :-)
But they will only occur if there is some lameness with the ns[1-
4].google.com records and that will already be reported with lame:n in
the
On Mon, 2018-01-22 at 12:45 +, Tony Finch wrote:
>
> They'll have a log category of edns-disabled.
But if the problem were EDNS, would it be so intermittent and always
fixable by rndc reload?
> But, looking through the
> code, if this is leading to lameness you will also get lame-servers
>
On Tue, 2018-01-23 at 13:38 +0100, Reindl Harald wrote:
>
> pretty sure it's possible and likely not much different than the
> unbound-sample below which asks a rbldnsd on port 1043 on the same
> machine
>
> stub-zone:
> name: "zone-name."
> stub-addr: 127.0.0.1@1053
This all falls apart
On Tue, 2018-01-23 at 09:53 -0700, Grant Taylor via bind-users wrote:
>
> Could you try disabling DDNS updates for a little while?
That's effectively what I have done.
I set up a second server configuration running new zone on a different
IP address and pointed the DHCP server at it so that the
I'm really not sure about what the name of this feature I am going to
describe would be. I would probably call it an "overlay view". But I
am sure there are better names.
Imagine I have a BIND 9 server for the following network topology:
Network 1
192.168.1.0/24
I am trying to do some testing of an IPv6-only network here using some
nat64 to reach the "legacy" :-) IPv4 Internet. My network is currently
dual-stack.
I have dns64 query mapping working, but I am still seeing some clients
that I am trying to test with (that still have IPv4 addresses until the
I have a BIND9 server configured as a resolver for the local network to
forward all requests to 1.1.1.1. Given that that 1.1.1.1 includes
(RFC8914) EDE EDNS options in it's responses, can I configure the BIND
resolver to forward those EDNS options in it's response to the client?
While I know
On Sat, 2022-02-19 at 19:02 +0100, Matus UHLAR - fantomas wrote:
>
> what's the point of this setup?
> BIND can resolve by itself perfectly and you wouldn't rely on 3rd
> party
> service
Except that it cannot do EDE, as I already said in my original message.
Cheers,
b.
signature.asc
On Sun, 2022-02-20 at 08:16 +1100, Mark Andrews wrote:
>
> EDNS is hop by hop. There is no copying by any compliant server.
Fair enough. I thought it was a long shot.
Cheers,
b.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the
On Fri, 2023-05-26 at 16:51 +0530, Shailendra Gautam wrote:
> Does bind provide any way to manage(add,update,delete) resource
> records
> with HTTP API, like powerdns?
Not TTBOMK. It does have an API for managing RRs but that is using RFC
2136 and not HTTP.
> I currently use zonefiles to store
51 matches
Mail list logo
