broken trust chain on forwarder

[/dev/rob0]

On Fri, Sep 30, 2016 at 01:32:29PM -0400, jratliff at bluemarble.net wrote:
> 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.

Yes.  As Warren pointed out (and I meant to, forgot) the idea of 
using a make-believe top-level domain is not a good one.  A name like 
"corp" is sure to attract bidders, and while I can resist money, can 
ICANN? :)

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

Let me clarify that: it goes against the spirit of NTA as intended.

It will work, unless/until the cron job fails to renew the NTA 
eventually, but that will be a quick and easy fix, if you are aware.

> 3) Change from a forwarder to a slave and thereby become 
> authoritative and no longer have any need of DNSSEC validation on 
> this zone.

Did you try with stub or static-stub?  

> 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).

Thanks Warren, good luck at the doc.

> I don't know what a local trust anchor is. I will look into this.

I've been spoiled by the BIND 9.8+ validation features, so TBH I 
haven't done much with manual trust anchors.  I took Alan's class in 
2013, and we did a trust anchor there, but it replaced, rather than 
augmented, the real root key.

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

You might want to mention the ICANN money grab to them, if you do 
have access to Those Who Decided.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: