broken trust chain on forwarder

Miguel Mucio Santos Moreira miguel at prodemge.gov.br
Fri Sep 30 16:56:44 UTC 2016


Hi John,

I've had the same problem than you. Either I'm gonna sign each zone on my authoritative server that I need to be forward internally on my Recursive Server or  I'm gonna create two layers of Recursive DNS, the first layer just with forward zones like your example but with DNSSEC disabled and for any other domain (INTERNET) the first layer forward queries to the second layer which has DNSSEC enabled. Obviously the second option is a workaround and should be avoided.


Good luck!

See you!

-- 
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 13:04:33, John Ratliff escreveu:
> I am building a new recursive DNS server. I have it set to forward records
for a single zone to our HQ DNS servers. When I try to resolve a record, I
get errors like this:

Sep 30 11:25:39 bltn-dns-04 named[2012]: validating @0x7fb51810b8f0:
stc.corp SOA: got insecure response; parent indicates it should be secure
Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid RRSIG) resolving
'inelhqnagios.stc.corp/DS/IN': 10.21.0.101#53
Sep 30 11:25:39 bltn-dns-04 named[2012]: validating @0x7fb520545fe0:
stc.corp SOA: got insecure response; parent indicates it should be secure
Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid RRSIG) resolving
'inelhqnagios.stc.corp/DS/IN': 10.21.0.100#53
Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid DS) resolving
'inelhqnagios.stc.corp/A/IN': 10.21.0.100#53
Sep 30 11:25:39 bltn-dns-04 named[2012]: validating @0x7fb51810ac60:
inelhqnagios.stc.corp A: bad cache hit (inelhqnagios.stc.corp/DS)
Sep 30 11:25:39 bltn-dns-04 named[2012]: error (broken trust chain)
resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.101#53

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?

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.

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.

I am running bind9 9.9.5 on Debian 8 with this single zone defined in an
otherwise stock debian bind9 configuration. I can post the remainder of my
config if it would be of use.

zone "stc.corp" IN {
        type forward;
        forwarders { 10.21.0.100; 10.21.0.101; };
        forward only;
};

Thanks.

--John


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



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


More information about the bind-users mailing list