From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (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 1655721F1A5 for ; Sun, 13 Apr 2014 09:16:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B7C211A80A9; Sun, 13 Apr 2014 12:16:12 -0400 (EDT) X-Virus-Scanned: OK Received: from app37.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9EBDC1A8094; Sun, 13 Apr 2014 12:16:12 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app37.wa-webapps.iad3a (Postfix) with ESMTP id 8472380044; Sun, 13 Apr 2014 12:16:12 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sun, 13 Apr 2014 12:16:12 -0400 (EDT) Date: Sun, 13 Apr 2014 12:16:12 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140413121612000000_45478" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1397405772.54075631@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] =?utf-8?q?Full_blown_DNSSEC_by_default=3F?= 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 16:16:14 -0000 ------=_20140413121612000000_45478 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI'd be for A. Or C with a very, very strong warning that would encourag= e users to pressure their broken upstream. Users in China will never not h= ave a broken upstream, of course, but they know that already... :-)=0A =0AS= imilarly, I hope we don't have Heartbleed in our SSL. Maybe we should put = a probe in Cero's SSL that tests clients to see if they have Heartbleed fix= ed on their side, and warns them.=0A =0AAny DNS provider that doesn't do DN= SSEC should be deprecated strongly (I'm pretty sure OpenDNS cannot do so, s= ince it deliberately fakes its lookups, redirecting to "man in the middle" = sites that it runs).=0A =0A=0A=0AOn Sunday, April 13, 2014 12:26am, "Dave T= aht" said:=0A=0A=0A=0A> I am delighted that we have t= he capability now to do dnssec.=0A> =0A> I am not surprised that various do= main name holders are doing it=0A> wrong, nor that some ISPs and registrars= don't support doing it=0A> either. We are first past the post here, and ki= nd of have to expect=0A> some bugs...=0A> =0A> but is the overall sense her= e:=0A> =0A> A) we should do full dnssec by default, and encourage users to = use=0A> open dns resolvers like google dns that support it when their ISPs= =0A> don't?=0A> =0A> B) or should we fall back to the previous partial dnss= ec=0A> implementation that didn't break as hard, and encourage folk to turn= =0A> it up full blast if supported correctly by the upstream ISP?=0A> =0A> = C) or come up with a way of detecting a broken upstream and falling=0A> bac= k to a public open resolver?=0A> =0A> Is there a "D"?=0A> =0A> --=0A> Dave = T=C3=A4ht=0A> =0A> NSFW:=0A> https://w2.eff.org/Censorship/Internet_censors= hip_bills/russell_0296_indecent.article=0A> _______________________________= ________________=0A> Cerowrt-devel mailing list=0A> Cerowrt-devel@lists.buf= ferbloat.net=0A> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> ------=_20140413121612000000_45478 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'd be for= A.  Or C with a very, very strong warning that would encourage users = to pressure their broken upstream.  Users in China will never not have= a broken upstream, of course, but they know that already... :-)

=0A

 

=0A

= Similarly, I hope we don't have Heartbleed in our SSL.  Maybe we shoul= d put a probe in Cero's SSL that tests clients to see if they have Heartble= ed fixed on their side, and warns them.

=0A

 

=0A

Any DNS provider that doe= sn't do DNSSEC should be deprecated strongly (I'm pretty sure OpenDNS canno= t do so, since it deliberately fakes its lookups, redirecting to "man in th= e middle" sites that it runs).

=0A

 = ;

=0A=0A=



On Sunday, April 13, 2014 12:2= 6am, "Dave Taht" <dave.taht@gmail.com> said:

=0A
=0A

> I am de= lighted 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
> e= ither. 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 thei= r ISPs
> don't?
>
> B) or should we fall back to t= he previous partial dnssec
> implementation that didn't break as ha= rd, and encourage folk to turn
> it up full blast if supported corr= ectly by the upstream ISP?
>
> C) or come up with a way of= detecting a broken upstream and falling
> back to a public open re= solver?
>
> Is there a "D"?
>
> --
&= gt; Dave T=C3=A4ht
>
> NSFW:
> https://w2.eff.org/= Censorship/Internet_censorship_bills/russell_0296_indecent.article
>= ; _______________________________________________
> Cerowrt-devel m= ailing list
> Cerowrt-devel@lists.bufferbloat.net
> https:/= /lists.bufferbloat.net/listinfo/cerowrt-devel
>

=0A
 ------=_20140413121612000000_45478--