<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title></title><style type="text/css">.expressomail-body-blockquote {margin: 5px 10px 0 3px;padding-left: 10px;border-left: 2px solid #000088;} </style></head><body>Dears,<br><br>Once I've tried to use stub zone to solve the same kind of problem with no success.<br>John if it works for you tell us what you did.<br><br>Thanks<br><br><br><br><span id="expressomail-body-signature">-- <br><p><font size="3">Miguel Mucio Santos Moreira<br> Gerente<br> GSR - Gerência de Serviços de Rede<br> (31)3339-1401<br> PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais</font> <br> <br> <font size="2">Aviso:
Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é
dirigida, podendo conter informação confidencial e legalmente protegida.
Se você não for destinatário dela, desde já fica notificado de
abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer
forma, utilizar a informação contida nesta mensagem, por ser ilegal.
Caso você tenha recebido por engano, pedimos que responda essa mensagem
informando o acontecido.</font></p></span><br><br><br><br>Em 30/09/2016 15:42:17, /dev/rob0 escreveu:<br><blockquote class="expressomail-body-blockquote"><pre class="message-viewer">On Fri, Sep 30, 2016 at 01:32:29PM -0400, jratliff@bluemarble.net wrote:
> On Fri, 30 Sep 2016 11:37:39 -0500, /dev/rob0 <rob0@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@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.
--
<a href="http://rob0.nodns4.us/" target="_blank">http://rob0.nodns4.us/</a>
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
_______________________________________________
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>
</warren@kumari.net></rob0@gmx.co.uk></pre></blockquote><br></body></html>