From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8CAF121F19B for ; Sun, 13 Apr 2014 08:04:37 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so7133993wgg.13 for ; Sun, 13 Apr 2014 08:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wR/MuapetMOkN+h6w79kNeGLmOXhQa1LNQrVDkPp3Fg=; b=dQC086h9cmRXZa9sUPOmsysLDXgez+hFCkC6+DgP0iMQxmGGbOrYYhdyaFT6AJ2jM2 v5cBJV8kfSKB+/m5zYoEFgafkk3hIt4NNy1sLuORK3dcEFmIPViAl05SuljcXexxKPRT SKjRJJnJ3e7rSn7XeOBrAqGHzaPCWNeNBDCBgfmiF6E6JCZN+vIzhIxvXptD4zSfXO/S ERlaGB/O/lXHaBUQK1nvCUd+ZZciV3qIHDf7kS0pOT1Kiwn0k9QLn/xjjoTTBREcFI+X z0c+Qqo3ljDwZaRyEFat2zg9MYXWnDRVwlNWK1MbEdYMvNxZsrT/QFX1jp6x3mou0EzQ Y6XA== MIME-Version: 1.0 X-Received: by 10.180.97.37 with SMTP id dx5mr6038736wib.53.1397401475574; Sun, 13 Apr 2014 08:04:35 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Sun, 13 Apr 2014 08:04:35 -0700 (PDT) In-Reply-To: <534A420C.4020102@etorok.net> References: <534A420C.4020102@etorok.net> Date: Sun, 13 Apr 2014 08:04:35 -0700 Message-ID: From: Dave Taht To: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" 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 15:04:38 -0000 On Sun, Apr 13, 2014 at 12:51 AM, T=F6r=F6k Edwin wrote: > 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 mi= ght prefer not having DNSSEC. Good point. Well there is also dnscrypt and opendns. There's a (broken) dnscrypt packaging attempt in ceropackages. > >> >> 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 i= n 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 u= pstream DNS resolver, > and if you don't get the DNSSEC metadata that you expected, *then* eventu= ally fallback to iterating from Root for that metadata. Which only works for a full blown local resolver. In the dnsmasq case the switch would have to be another open dns resolver. We could iterate over a list of open dns resolvers to find the best one. > So then A/AAAA/TXT/NS/etc. records would be answered by upstream, and onl= y for the DNSSEC metadata you would need to iterate > (and you could cache that, or stop iterating if you realize the zone is u= nsigned as per section 5.1.1) Maybe there could be a "dnssec-fallback-resolver" setting in dnsmasq, that it could fall back to if a known-not-to-resolve-properly domain can't do a proof of non-existence properly? bork.bork.bork.bork.example.org > Best regards, > --Edwin > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=E4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article