From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (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 3DD9B21F200 for ; Mon, 28 Apr 2014 16:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201312; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=PLqoAy1b6Z2LaB2ib4bS5xaUKzkfPrVcMtMft6eM9tU=; b=I827AwjYa609uuLosIjYBAKXHixwUBI/iOBU1y4jCE2hAEAp4t3ehS6Ac0paW4zEIWhsK9qqhEfy+onWneIVXj05RRTfF3OBaXNE6MlVbbdrWwq79w7CSJtpMcPXGWT02qmw1TTPNcy2CVsOH0zRT/Ii62ASN6lgZHoSYPZU+4m8IsO1W4hnPBR98nka7b80Ckh3GGcyOYDzqcy4; Received: from authenticated user by smtp.spodhuis.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1Weuuy-000ERo-QM; Mon, 28 Apr 2014 23:25:01 +0000 Date: Mon, 28 Apr 2014 19:24:59 -0400 From: Phil Pennock To: Simon Kelley Message-ID: <20140428232459.GA55372@redoubt.spodhuis.org> Mail-Followup-To: Simon Kelley , Dave Taht , Jim Gettys , dnsmasq-discuss , "cerowrt-devel@lists.bufferbloat.net" References: <535EACCB.7090104@thekelleys.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535EACCB.7090104@thekelleys.org.uk> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x3903637F.asc Cc: dnsmasq-discuss , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014 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, 28 Apr 2014 23:25:05 -0000 On 2014-04-28 at 20:32 +0100, Simon Kelley wrote: > On 28/04/14 19:56, Dave Taht wrote: > > I see A and AAAA requests for for "ds.test-ipv6.com" that fail. > > The root of this failure is that DS ds.test-ipv6.com is broken. > > <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 ds ds.test-ipv6.com > The latest fix I made (when the SERVFAIL reply comes, try the next > possible secure-nonexistent DS record at test-ipv6.com) works sometimes, > but the query above is taking long enough to fail that sometimes the > original requestor has timed out before it gets the answer and tries again. Er, DS records are authoritative in the parent domain and are equivalent to glue; they are not expected to exist below the zone cut. This is why you'll get results from: $ dig -t ds spodhuis.org @a2.org.afilias-nst.info but a NOERROR from: $ dig -t ds spodhuis.org @nsauth.spodhuis.org An NS query for "ds.test-ipv6.com" gives "test-ipv6.com", so that is the zone cut, so it's in the COM. zone that you should expect to find any DS records for "test-ipv6.com" and there's no need for a DS for anything below that unless there's also a zone cut, in which case there's a DS at the delegation point. RFC 4033: ----------------------------8< cut here >8------------------------------ 3.1. Data Origin Authentication and Data Integrity [...] The Delegation Signer (DS) RR type simplifies some of the administrative tasks involved in signing delegations across organizational boundaries. The DS RRset resides at a delegation point in a parent zone and indicates the public key(s) corresponding to the private key(s) used to self-sign the DNSKEY RRset at the delegated child zone's apex. The administrator of the child zone, in turn, uses the private key(s) corresponding to one or more of the public keys in this DNSKEY RRset to sign the child zone's data. The typical authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more complex authentication chains, such as additional layers of DNSKEY RRs signing other DNSKEY RRs within a zone. ----------------------------8< cut here >8------------------------------