Re: broken trust chain on forwarder

[Miguel Mucio Santos Moreira]

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, jratl...@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 

Re: broken trust chain on forwarder

[/dev/rob0]

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  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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: broken trust chain on forwarder

[Miguel Mucio Santos Moreira]

Dears,

I understood John has an invalid internal domain called stc.corp (Microsoft AD).
Some users will use a new Recursive DNS Server he said before and this new 
Recursive DNS needs to querie records on the internet and on the stc.corp 
Authoritative Server, then he created a forward zone in recursive server to 
stc.corp Authoritative Server.
When he disables DNSSEC on recursive server the problem doesn't happen.
Right John? 
If you can't sign stc.corp zone because it's not yours, my workaround solution 
I've sent an email before probably is gonna work. 

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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users> 



___
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

Re: broken trust chain on forwarder

[jratliff]

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.

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.
3) Change from a forwarder to a slave and thereby become authoritative and
no longer have any need of DNSSEC validation on this zone.

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

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

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

Thanks.

--John
___
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

Re: broken trust chain on forwarder

[Warren Kumari]

On Friday, September 30, 2016, /dev/rob0  wrote:

> On Fri, Sep 30, 2016 at 12:04:33PM -0400, John Ratliff wrote:
> > 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?
>
> 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.
>
>
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.
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).





> > 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.
>
> > 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;
> > };
>
> Oh, another thing you can try; offhand I don't know if it will work,
> but try a zone of type "stub" or "static-stub".
> --
>   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
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
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

Re: broken trust chain on forwarder

[Miguel Mucio Santos Moreira]

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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users> 



___
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

Re: broken trust chain on forwarder

[/dev/rob0]

On Fri, Sep 30, 2016 at 12:04:33PM -0400, John Ratliff wrote:
> 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?

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.

> 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;
> };

Oh, another thing you can try; offhand I don't know if it will work, 
but try a zone of type "stub" or "static-stub".
-- 
  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

broken trust chain on forwarder

[John Ratliff]

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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users