<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
