Date: Sat, 13 Oct 2018 14:13:56 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Eugene Grosbein <eugen@grosbein.net> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: DNS KSK rollover, local_unbound and 11.2-STABLE Message-ID: <86y3b211tn.fsf@next.des.no> In-Reply-To: <6af09cc1-47a4-fe64-7a11-5de26fe7f607@grosbein.net> (Eugene Grosbein's message of "Sat, 13 Oct 2018 18:50:25 %2B0700") References: <5BC046FB.9080906@grosbein.net> <861s8uaodn.fsf@next.des.no> <20be8009-5de8-61f0-dc67-a6b18af7bc37@grosbein.net> <86bm7y2lui.fsf@next.des.no> <44dd8f4d-1608-b38f-2f3e-90d234065038@grosbein.net> <8636ta2i1k.fsf@next.des.no> <6af09cc1-47a4-fe64-7a11-5de26fe7f607@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Eugene Grosbein <eugen@grosbein.net> writes:
> Why unbound daemon fails to update root.key after start?
The daemon uses a different bootstrap method than unbound-anchor, and if
I recall correctly, 1.5.10 is unable to self-boostrap when there are two
concurrent KSKs, i.e. phase E of ICANN's operational plan, although it
should work when the old key is revoked in phase F.
The local_unbound service was never intended to be started without a
network connection. You can do one of two things: either add a script
that runs after the network connection is up and stops the local_unbound
service, deletes /var/unbound/root.key, and restarts the local_unbound
service (which will run unbound-anchor before starting the daemon); or
you can try the attached patch, which a) adds the new KSK to
unbound-anchor so it doesn't need to fall back to the HTTP method and b)
works around the double-key problem.
DES
--
Dag-Erling Smørgrav - des@des.no
[-- Attachment #2 --]
Index: contrib/unbound/smallapp/unbound-anchor.c
===================================================================
--- contrib/unbound/smallapp/unbound-anchor.c (revision 339291)
+++ contrib/unbound/smallapp/unbound-anchor.c (working copy)
@@ -241,7 +241,10 @@
get_builtin_ds(void)
{
return
-". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n";
+/* anchor 19036 is from 2010 */
+/* anchor 20326 is from 2017 */
+". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n"
+". IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D\n";
}
/** print hex data */
Index: contrib/unbound/validator/autotrust.c
===================================================================
--- contrib/unbound/validator/autotrust.c (revision 339291)
+++ contrib/unbound/validator/autotrust.c (working copy)
@@ -1571,6 +1571,11 @@
verbose(VERB_ALGO, "DS match attempt failed");
continue;
}
+ /* match of hash is sufficient for bootstrap of trust point */
+ (void)reason;
+ (void)ve;
+ return 1;
+ /* no need to check RRSIG, DS hash already matched with source
if(dnskey_verify_rrset(env, ve, dnskey_rrset,
dnskey_rrset, key_idx, &reason) == sec_status_secure) {
return 1;
@@ -1578,6 +1583,7 @@
verbose(VERB_ALGO, "DS match failed because the key "
"does not verify the keyset: %s", reason);
}
+ */
}
return 0;
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86y3b211tn.fsf>