broken trust chain on forwarder

[jratliff at bluemarble.net]

On Fri, 30 Sep 2016 11:37:39 -0500, /dev/rob0 <rob0 at gmx.co.uk> 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 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.

What I'm hearing is that the real problem is that stc.corp, not being a
valid TLD, cannot be verified back to the root using DNSSEC. So, the HQ
DNS
server is not necessarily misconfigured, but there is no possibility of
doing any configuration involving DNSSEC validation including this zone,
because the chain of trust cannot ever be verified.

So, my options are.

1) Disable DNSSEC validation. Works, but is global, at least in my version
of BIND.
2) Update BIND to 9.11 and use negative trust anchors, which is not
recommended.
3) Change from a forwarder to a slave and thereby become authoritative and
no longer have any need of DNSSEC validation on this zone.

On Fri, 30 Sep 2016 12:57:02 -0400, Warren Kumari <warren at kumari.net>
wrote:
> 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 [2].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 don't know what a local trust anchor is. I will look into this.

Yeah, .corp is a bad idea, but unfortunately for me, it is not within my
control.

Thanks.

--John