On Fri, Sep 30, 2016 at 01:32:29PM -0400, jratl...@bluemarble.net wrote:
> On Fri, 30 Sep 2016 11:37:39 -0500, /dev/rob0 <r...@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 <war...@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:
_______________________________________________
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
