broken trust chain on forwarder

Fri Sep 30 19:00:55 UTC 2016

Dears,

Once I've tried to use stub zone to solve the same kind of problem with no success.
John if it works for you tell us what you did.

Thanks

-- 
Miguel Mucio Santos Moreira
 Gerente
 GSR - Gerência de Serviços de Rede
 (31)3339-1401
 PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais 

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.

Em 30/09/2016 15:42:17, /dev/rob0 escreveu:
> 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 >  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 > 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users> 
> @kumari.net>> @gmx.co.uk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160930/9f5a2587/attachment.html>