Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

broken trust chain on forwarder

1,657 views
Skip to first unread message

John Ratliff

unread,
Sep 30, 2016, 12:04:40 PM9/30/16
to bind-...@lists.isc.org
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


/dev/rob0

unread,
Sep 30, 2016, 12:37:51 PM9/30/16
to bind-...@lists.isc.org
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:

Miguel Mucio Santos Moreira

unread,
Sep 30, 2016, 12:56:53 PM9/30/16
to jrat...@bluemarble.net, bind-...@lists.isc.org
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-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Warren Kumari

unread,
Sep 30, 2016, 12:57:14 PM9/30/16
to bind-...@lists.isc.org


On Friday, September 30, 2016, /dev/rob0 <ro...@gmx.co.uk> wrote:
On Fri, Sep 30, 2016 at 12:04:33PM -0400, John Ratliff wrote:
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-...@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

jrat...@bluemarble.net

unread,
Sep 30, 2016, 1:32:36 PM9/30/16
to bind-...@lists.isc.org
On Fri, 30 Sep 2016 11:37:39 -0500, /dev/rob0 <ro...@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.

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

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

Miguel Mucio Santos Moreira

unread,
Sep 30, 2016, 2:36:59 PM9/30/16
to jrat...@bluemarble.net, bind-...@lists.isc.org
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-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

/dev/rob0

unread,
Sep 30, 2016, 2:42:27 PM9/30/16
to bind-...@lists.isc.org
On Fri, Sep 30, 2016 at 01:32:29PM -0400, jrat...@bluemarble.net wrote:
> On Fri, 30 Sep 2016 11:37:39 -0500, /dev/rob0 <ro...@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.

Miguel Mucio Santos Moreira

unread,
Sep 30, 2016, 3:01:35 PM9/30/16
to bind-...@lists.isc.org
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, jrat...@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-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Tony Finch

unread,
Oct 3, 2016, 5:19:34 AM10/3/16
to bind-...@lists.isc.org
/dev/rob0 <ro...@gmx.co.uk> wrote:
>
> > 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?

Stub and static-stub just change how BIND finds a zone's nameservers; they
don't affect validation.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Fastnet: Southeast 5 to 7. Rough or very rough. Rain at times in west. Good,
occasionally poor in west.
0 new messages