From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) (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 AA89F21F1C6 for ; Thu, 6 Feb 2014 07:01:09 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:42376 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WBQRv-0002Qj-62; Thu, 06 Feb 2014 15:01:07 +0000 Received: from spike.thekelleys.org.uk ([192.168.0.193]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1WBQRu-0002s3-IC; Thu, 06 Feb 2014 15:01:06 +0000 Message-ID: <52F3A3B2.8020201@thekelleys.org.uk> Date: Thu, 06 Feb 2014 15:01:06 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= References: <87a9e6xcae.fsf@alrua-x1.kau.toke.dk> <87ob2lmqny.fsf@toke.dk> <52F29645.6010001@thekelleys.org.uk> <874n4dwcdb.fsf@alrua-x1.kau.toke.dk> <52F2BA80.9010202@thekelleys.org.uk> <87iossvgw4.fsf@alrua-x1.kau.toke.dk> <52F369AA.5060809@thekelleys.org.uk> <8761osv78r.fsf@alrua-x1.kau.toke.dk> <52F371B3.5030406@thekelleys.org.uk> <87k3d8mna8.fsf@toke.dk> In-Reply-To: <87k3d8mna8.fsf@toke.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC. 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: Thu, 06 Feb 2014 15:01:10 -0000 On 06/02/14 12:35, Toke Høiland-Jørgensen wrote: > > So, just to make sure I understand things: What kind of guarantees does > the DNSSEC support give? If an upstream server is injecting things into > DNS (for a signed zone of course), is dnsmasq guaranteed to discard the > reply? And can a malicious upstream server strip out DNSSEC results to > fool dnsmasq into accepting a bogus response? Yes, and yes, AFAICS. There are four possible results of verification, given in RFC 4025 para 4.3 Quote: Secure: An RRset for which the resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset. In this case, the RRset should be signed and is subject to signature validation, as described above. Insecure: An RRset for which the resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset. This can occur when the target RRset lies in an unsigned zone or in a descendent of an unsigned zone. In this case, the RRset may or may not be signed, but the resolver will not be able to verify the signature. Bogus: An RRset for which the resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so, either due to signatures that for some reason fail to validate or due to missing data that the relevant DNSSEC RRs indicate should be present. This case may indicate an attack but may also indicate a configuration error or some form of data corruption. Indeterminate: An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones. Dnsmasq doesn't distriguish between Insecure and Indeterminate, both are lumped together as "INSECURE". The reason it's done that way is that it would cost extra work and round-trips upstream to make the distinction, and, unless I've misunderstood, there are no differences in the external behavior required for these two results. bogus - return SERVFAIL in the answer secure - set the AD bit insecure and indeterminate - do neither of the above. Cheers, Simon. > > -Toke