<sigh> I should have pointed out that BOTH servers have recursion turned on.

Yeah, I know about having DNSSEC-enable=yes to not break downstream
validation. (I inherited this setup...)

BOTH are internal DNS servers with access to the internet to query the
internet roots (no default forwarding active).

I suspect it's the issue of having the DNSSEC-enable set to off on server B
even though it's not validating. (But that's just a guess...)

Thanks,

Bob

On Wed, Apr 11, 2018 at 9:48 AM, Tony Finch <d...@dotat.at> wrote:

> Bob McDonald <bmcdonal...@gmail.com> wrote:
> >
> > Server A
> > DNSSEC=yes
> > DNSSEC-validation=yes
> > Valid trust anchor for the root zone
> > DNSSEC validation seems to work correctly
> > Zone one.com. is setup as a forward zone to server B
> >
> > Server B
> > DNSSEC=no
> > DNSSEC-validation=N/A
> > authoritative and the master for one.com.
>
> This setup will not work reliably: the target forwarding server has to be
> a recursive server, since the forwarding client will expect it to do full
> resolution of the query - following delegations, etc. I expect it will
> have funky interactions with DNSSEC validation (e.g. chasing DS records)
> but I have not experimented with this myself.
>
> Also, you should never turn off the `dnssec-enable` setting, since that
> prevents BIND from doing the right thing with RRSIG/NSEC/DS records. This
> will break downstream validation even if the server is not itself
> validating - that is, if you turn it off on an authoritative server, it
> cannot serve any signed zones.
>
> Tony.
> --
> f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/
> Southeast Malin: Easterly 5 to 7. Slight or moderate, becoming moderate or
> rough. Mainly fair. Good.
>
_______________________________________________
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

Reply via email to