From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bytemark.thekelleys.org.uk (bytemark.thekelleys.org.uk [IPv6:2001:41c8:51:46b:feff:ff:fe00:3310]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8F74021F225 for ; Tue, 29 Apr 2014 06:22:39 -0700 (PDT) Received: from [213.205.230.165] (helo=[192.168.150.151]) by bytemark.thekelleys.org.uk with esmtpa (Exim 4.80) (envelope-from ) id 1Wf7zW-0001gs-9k; Tue, 29 Apr 2014 13:22:34 +0000 Message-ID: <535FA793.8020502@thekelleys.org.uk> Date: Tue, 29 Apr 2014 14:22:27 +0100 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dave Taht , Jim Gettys , dnsmasq-discuss , "cerowrt-devel@lists.bufferbloat.net" References: <535EACCB.7090104@thekelleys.org.uk> <20140428232459.GA55372@redoubt.spodhuis.org> In-Reply-To: <20140428232459.GA55372@redoubt.spodhuis.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 29 Apr 2014 13:22:39 -0000 On 29/04/14 00:24, Phil Pennock wrote: > 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 A NOERROR answer from the authoritative server for test-ipv6.com would be fine. What actually happens is no answer at all and a timeout (or a closed TCP connection if TCP is used.) It's maybe worth expanding on what we're trying to do here. The original query is "A ds.test-ipv6.com". The answer to that comes back fine, but there are no RRSIGs proving that that answer is good. Now we have to distinguish between no signatures because the domain isn't signed, and no signatures because the answer has come from the Bad Guys. To do that, we need to find proof (NSEC or NSEC3 records) that a DS doesn't exist somewhere between ds.test-ipv6.com and the root. Bear in mind that dnsmasq is a DNS forwarder, not a recursive DNS server, so it doesn't know where the zone cuts are. The current strategy it to start at ds.test-ipv6.com and do DS queries. There are three possible results. unsigned NOERROR -> chop one label off the RHS and repeat DS record -> definite Bad Guy activity, return BOGUS signed no DS record -> we expect unsigned original answer, return INSECURE result.ds.test-ipv6.com The other alternative approach is to start from the root and add labels, but that has a problem. Consider department.campus.university.edu where there are zone cuts between university and edu and between department and campus. All the zones are signed, so if we look up something under .department, we expect a signature, if we don't get it, we check DS .edu gives an answer DS university.edu gives secure NODATA secure no DS means that the original unsigned answer should be accepted, except that it shouldn't. There's no way to distinguish between secure lack of DS because we've reached an unsigned branch of the tree, and secure lack of DS because we're not at a zone cut, except if we know where the zone cuts are, and we don't. That's why dnsmasq works up from the bottom. The first secure no-DS answer we find marks the boundary between signed and unsigned tree. Dnsmasq is acting as a validating stub resolver here. That's a supported role for DNSSEC, so this must be possible. If it's not then we have a standards problem. > > 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. ds.test-ipv6.com Doing NS queries to find zone cuts is a possible solution, but I know of ISP nameservers that elide the Authority section for "performance". Simon. > > 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------------------------------ >