broken trust chain on forwarder

[Warren Kumari]

On Friday, September 30, 2016, /dev/rob0 <rob0 at gmx.co.uk> wrote:

> On Fri, Sep 30, 2016 at 12:04:33PM -0400, John Ratliff wrote:
> > I am building a new recursive DNS server. I have it set to forward
> > records for a single zone to our HQ DNS servers. When I try to
> > resolve a record, I get errors like this:
> >
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> > @0x7fb51810b8f0: stc.corp SOA: got insecure response; parent
> > indicates it should be secure
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid RRSIG)
> > resolving 'inelhqnagios.stc.corp/DS/IN': 10.21.0.101#53
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> > @0x7fb520545fe0: stc.corp SOA: got insecure response; parent
> > indicates it should be secure
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid RRSIG)
> > resolving 'inelhqnagios.stc.corp/DS/IN': 10.21.0.100#53
> > Sep 30 11:25:39 bltn-dns-04 named[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]: 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 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 this interpretation accurate? Are the
> > errors I'm seeing here the result of a misconfigured DNS server at
> > our HQ?
>
> Not quite, no.  The 10.21.0.10[01] servers are giving you insecure
> answers which conflict with those you have already gotten from the
> root, which say there is no "corp." TLD.
>
>
What about creating and installing a local trust anchor for .Corp?

Also, im assuming that you already know that using a local / non-delegated
TLD is a really bad idea. You should strongly consider moving your
namespace under E.g companyname.com.
See the whole set of discussions on name collisions, home/Corp/mail, the
inability to get TLS certificates, etc.

W
(Apologies for terseness, about to go into dr appt).





> > I've seen on the internet people suggest disabling DNSSEC
> > validation. That seems to be an extreme solution to this problem.
> > It works, but my understanding is that this would disable DNSSEC
> > validation globally, not just for a single zone.
>
> That's correct, and it's the only workaround I know of, other than
> going to BIND 9.11 and having a cron job to set a negative trust
> anchor ("rndc nta") for stc.corp.
>
> Note that this usage of NTA is undocumented and not recommended; NTAs
> are intended to be temporary.
>
> > The HQ DNS servers at 10.21.0.100 and 101 are Microsoft DNS servers
> > over which I have no control, if that information is relevant.
>
> It is.  If you could have at least one of those allow you to transfer
> the stc.corp zone, you could have a slave zone, which would have been
> another possible workaround.
>
> As a slave zone, your server would have authoritative answers, and
> thus no need to go to the root.
>
> > I am running bind9 9.9.5 on Debian 8 with this single zone defined
> > in an otherwise stock debian bind9 configuration. I can post the
> > remainder of my config if it would be of use.
> >
> > zone "stc.corp" IN {
> >         type forward;
> >         forwarders { 10.21.0.100; 10.21.0.101; };
> >         forward only;
> > };
>
> Oh, another thing you can try; offhand I don't know if it will work,
> but try a zone of type "stub" or "static-stub".
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org <javascript:;>
> https://lists.isc.org/mailman/listinfo/bind-users
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160930/353df4a3/attachment-0001.html>