broken trust chain on forwarder

[/dev/rob0]

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.

> 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: