From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.etorok.net (mx.etorok.net [62.113.205.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.etorok.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A7D1221F1BF for ; Sun, 13 Apr 2014 00:51:46 -0700 (PDT) Received: by mx.etorok.net (OpenSMTPD) with ESMTP id 2419ad67; for ; Sun, 13 Apr 2014 10:51:42 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=etorok.net; h= message-id:date:from:mime-version:to:references:in-reply-to :content-type:content-transfer-encoding; s=ml; l=1675; bh=nVEy8P SA5y2rrrSAJyPzJvYZS/M=; b=ahWbFy4UroIMhc7tH5PiTVOc1naymgKol4uci9 4xw6fls0J0bRXLle+GhZc7qvWl6J9cxcGBqQ2HbUOlUc/fWSSBx1nBnjJQf6a3aO vzJWGkYTNSMzAoxPTxlE8vaIvlisbvNTASheoyu5JXxrEvUmf7eEM/GrrXzjsGAq HVvF8= Received: by mx.etorok.net (OpenSMTPD) with ESMTPSA id d4b19c58; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO; for ; Sun, 13 Apr 2014 10:51:41 +0300 (EEST) Message-ID: <534A420C.4020102@etorok.net> Date: Sun, 13 Apr 2014 10:51:40 +0300 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: cerowrt-devel@lists.bufferbloat.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Cerowrt-devel] Full blown DNSSEC by default? 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: Sun, 13 Apr 2014 07:51:47 -0000 On 04/13/2014 07:26 AM, Dave Taht wrote: > I am delighted that we have the capability now to do dnssec. > > I am not surprised that various domain name holders are doing it > wrong, nor that some ISPs and registrars don't support doing it > either. We are first past the post here, and kind of have to expect > some bugs... > > but is the overall sense here: > > A) we should do full dnssec by default, and encourage users to use > open dns resolvers like google dns that support it when their ISPs > don't? There are people who don't use Google DNS due to privacy concerns. Given the choice between not using DNSSEC, and using Google's DNS they might prefer not having DNSSEC. > > B) or should we fall back to the previous partial dnssec > implementation that didn't break as hard, and encourage folk to turn > it up full blast if supported correctly by the upstream ISP? > > C) or come up with a way of detecting a broken upstream and falling > back to a public open resolver? > > Is there a "D"? There are some tests described here, and a 'dynamic fallback' technique in section 5: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-00 I think the 'dynamic fallback' can be described in short as: try to use upstream DNS resolver, and if you don't get the DNSSEC metadata that you expected, *then* eventually fallback to iterating from Root for that metadata. So then A/AAAA/TXT/NS/etc. records would be answered by upstream, and only for the DNSSEC metadata you would need to iterate (and you could cache that, or stop iterating if you realize the zone is unsigned as per section 5.1.1) Best regards, --Edwin