From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7A8BB21F1FB for ; Mon, 24 Mar 2014 02:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id EBD561C209; Mon, 24 Mar 2014 10:59:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1395655153; bh=P5c1tCaR7DCrG4DhLLblIynbzCdCHmcxOP/d+fIeuYQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=SoPWSu8JqdspO3eOT8SOlkQktvtILZzMdhJf4SMXJWzlKa7l2+rFIJ0jOHLwXC8zS 1AjfE87C8jAPkDeGxENxeTdf90uN98UUm5tzrxmzjYSQPwerPody7MJBHB5IPIZceO G+5kLg9AOjPGDruOHHa/J1ucUzTBWkvDUJWc06xw= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Aaron Wood References: <8738i9rwrx.fsf@alrua-x1.karlstad.toke.dk> <12727.1395614516@sandelman.ca> Date: Mon, 24 Mar 2014 10:59:08 +0100 In-Reply-To: (Aaron Wood's message of "Mon, 24 Mar 2014 10:51:44 +0100") Message-ID: <87txanj4sz.fsf@alrua-x1.karlstad.toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 09:59:20 -0000 --=-=-= Content-Type: text/plain Aaron Wood writes: > That would scale well for CeroWRT, but doesn't seem like it would > scale well for general-use (OpenWRT). Or rather, the use of > bufferbloat.net wouldn't scale well. But OpenWRT might be able to do > the same with it's key, and have it's own ntp.openwrt.org which > resolves into the general ntp pool. Would this "caching of the key" be akin to distributing an extra trust anchor with the key of the domain in question? And would the gain of doing this be sufficient to warrant the extra complexity (as opposed to just caching the IP address of one or more NTP servers)? -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTMAHsAAoJEENeEGz1+utPiskH/3y6WBA+EoOzGN1A9rls9QOQ 7anJIwLZTh4CN1iqGdH9r9B45fBae6oQc0kpJZ7rKlYu0WdGeZKdzM78qfRm3GZ4 CVXSNp2KNHidZelyZ9c4wJtecOLdn3JiVLhWF0mlSsjrQXO62LrLS7eAX2/EwlsL 3Iv3yphVNHdAe93wODGSUloOFiEwz0X/t3F8dus22mgDVcEi/5Fd4xjyJF7jSPcn zNWnRd+SthfuocfDyLimbxEg/+hYR235X64EMUKJZ4UQC8O61WW5HPVc59FlBFHl UDvdGggBX2HLSGPl9Q7986KHT4c1I9mgt4O6Vpos0JJL9EdeJFGhu/iIktlvBzM= =1H+h -----END PGP SIGNATURE----- --=-=-=--