Discussion:
broken trust chain
Cody Allen
2018-10-14 12:17:10 UTC
Permalink
issue just started on 10/13/2018 both servers impacted at same time, clocks are correct, version of bind is 9.11.1 impacting recursion on internal view, authoritative zones work fine, servers have been running for couple of years or longer with zero problems. most recent version of bind.keys installed. only solution has been to set dnssec-validation to no


_______________________________________________
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
Anand Buddhdev
2018-10-14 12:54:18 UTC
Permalink
Post by Cody Allen
issue just started on 10/13/2018 both servers impacted at same time, clocks are correct, version of bind is 9.11.1 impacting recursion on internal view, authoritative zones work fine, servers have been running for couple of years or longer with zero problems. most recent version of bind.keys installed. only solution has been to set dnssec-validation to no
On 11 October 2018, at 16:00 UTC, the root zone KSK was rolled. You're
almost certainly affected by this. But saying that "the most recent
version of bind.keys is installed" is meaningless, because I have no
idea what your definition of "most recent" is. At the very least,
provide the key IDs of the keys in your bind.keys file. If you don't
have key ID 20326 in there, you won't be able to do DNSSEC validation.

Regards,
Anand
_______________________________________________
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
Anand Buddhdev
2018-10-14 13:43:21 UTC
Permalink
Hi Cody,

Well, your "managed-keys" section looks almost right. It should *not*
have the dlv.isc.org key in there, because the DLV has retired. The root
zone keys look right.

If you set "dnssec-validation" to "auto" (the recommended setting), then
BIND *should* be able to validate. We don't know what your previous
setting of "dnssec-validation" was, before you turned it off. If it
still can't, then look at its log for more hints.

Regards,
Anand
definitely not seeing those keys showing keyid: 19036 when i do rndc managed-keys status but the key file
shows both 20326 and 19036
bind.keys managed key section below
managed-keys {
# ISC DLV: See https://www.isc.org/solutions/dlv for details.
#
# NOTE: The ISC DLV zone is being phased out as of February 2017;
# the key will remain in place but the zone will be otherwise empty.
# Configuring "dnssec-lookaside auto;" to activate this key is
# harmless, but is no longer useful and is not recommended.
dlv.isc.org. initial-key 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
TDN0YUuWrBNh";
# ROOT KEYS: See https://data.iana.org/root-anchors/root-anchors.xml
# for current trust anchor information.
#
# These keys are activated by setting "dnssec-validation auto;"
# in named.conf.
#
# This key (19036) is to be phased out starting in 2017. It will
# remain in the root zone for some time after its successor key
# has been added. It will remain this file until it is removed from
# the root zone.
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
# This key (20326) is to be published in the root zone in 2017.
# Servers which were already using the old key (19036) should
# roll seamlessly to this new one via RFC 5011 rollover. Servers
# being set up for the first time can use the contents of this
# file as initializing keys; thereafter, the keys in the
# managed key database will be trusted and maintained
# automatically.
. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
Post by Anand Buddhdev
Post by Cody Allen
issue just started on 10/13/2018 both servers impacted at same time, clocks are correct, version of bind is 9.11.1 impacting recursion on internal view, authoritative zones work fine, servers have been running for couple of years or longer with zero problems. most recent version of bind.keys installed. only solution has been to set dnssec-validation to no
On 11 October 2018, at 16:00 UTC, the root zone KSK was rolled. You're
almost certainly affected by this. But saying that "the most recent
version of bind.keys is installed" is meaningless, because I have no
idea what your definition of "most recent" is. At the very least,
provide the key IDs of the keys in your bind.keys file. If you don't
have key ID 20326 in there, you won't be able to do DNSSEC validation.
Regards,
Anand
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Petr Mensik
2018-10-15 12:33:07 UTC
Permalink
Hi Cody,

please check contents of managed-keys.bind or viewname.mkeys files in
bind working directory. It can be redirected somewhere else by
managed-keys-directory option.

These files contains state of managed keys of BIND. Its contents can be
analysed by manually or by perl script in contrib/scripts/check5011.pl.

Path to file depends on distribution. Default path on Fedora without
views would be:
perl contrib/scripts/check5011.pl /var/named/dynamic/managed-keys.bind
. tag 19036 RSASHA256 trusted
. tag 20326 RSASHA256 trusted

Maybe simpler validation would be rndc secroots, then find
named.secroots in the working directory of bind. It should contain:
Secure roots:

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed

BIND will initialize managed-keys first time it is able to reach root
servers to validate it. Once it does, it will use RFC 5011 mechanism to
update the key. It has to use dnssec enabled forwarder or have direct
root access to maintain the keys. If neither of that is available,
dnssec keys are no longer automatically managed but no warning is
emitted. If managed-keys.bind and its jnl files are deleted and bind is
restarted, it will recreate it from managed-keys found in configuration.

File bind.keys is used only the zone is initialized in managed-keys.bind
for the first time. It requires 30 days after that to trust new key.
Post by Cody Allen
issue just started on 10/13/2018 both servers impacted at same time, clocks are correct, version of bind is 9.11.1 impacting recursion on internal view, authoritative zones work fine, servers have been running for couple of years or longer with zero problems. most recent version of bind.keys installed. only solution has been to set dnssec-validation to no
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: ***@redhat.com PGP: 65C6C973
_______________________________________________
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/mail
Loading...