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:
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
