From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 18AF121F208 for ; Thu, 10 Apr 2014 10:29:32 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so11120517wib.8 for ; Thu, 10 Apr 2014 10:29:30 -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=N1qeOaQmXMEEpYdwLwuq4kiaRxq/Y+97en45uqB9z78=; b=LNfHmZ2QIpkPrtW+rWxquw2hHBcIQl1z80X1uJEiadLFuePI72WPRFt1VQZgiDPdxu saupPZ2XXf0sZ89irjuzS2bL/WkqW3q1P+9iUoT3XzjVxT2BPzWVkLAxRkCqFun2kmuu 5/uTHQzFd9TT5Qodi8HbhGSxqdIBSyK0PBkY85o3NVBvdNJxt7wwUPfKQ+KA9tpEi/Z2 yrZleo1HpI+uBKhJzQtup54GJ0g38ikL+IQlKUMxGHywv3Pl17WhJRWdbGx50P5l1fuW VtVynl1Zh2FkQKjdC6cRW1T4OJ6TgTNP63C0H9IOv8Ad5n4MCBb3UTpwETupH6NdCJ5/ cuzw== MIME-Version: 1.0 X-Received: by 10.194.92.228 with SMTP id cp4mr2158085wjb.81.1397150970783; Thu, 10 Apr 2014 10:29:30 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Thu, 10 Apr 2014 10:29:30 -0700 (PDT) In-Reply-To: <5346B650.5040200@gmail.com> References: <85984.1397137700@turing-police.cc.vt.edu> <5346A561.30901@gmail.com> <87sipll0fh.fsf@toke.dk> <5346B650.5040200@gmail.com> Date: Thu, 10 Apr 2014 10:29:30 -0700 Message-ID: From: Dave Taht To: Robert Bradley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released 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, 10 Apr 2014 17:29:33 -0000 On Thu, Apr 10, 2014 at 8:18 AM, Robert Bradley wrote: > On 10/04/2014 15:32, Toke H=F8iland-J=F8rgensen wrote: >> Robert Bradley writes: >> >>> - I had to add my cable modem configuration address to the BCP38 >>> exception list (192.168.100.1). This gets used for nothing except >>> configuration and checking the modem logs so this is understandable. I >>> also end up adding a static route anyway since if Internet breaks, I >>> need a route to the modem... >> If you add a 'scope link' route on the wan interface, the BCP38 code >> *should* pick this up automatically and add an exception. Would be cool >> if you could test this :) > > Just tested this now and it works fine. :) How did you add scope link? > >>> - dnsmasq's default of dnssec-check-unsigned broke my DNS, since my >>> ISP servers do not support DNSSEC. In that case, everything winds up >>> as failing. >> That's an interesting failure mode. FWIW you can point it at >> 8.8.8.8/8.8.4.4 instead if you want dnssec verification :) > > I was tempted to leave it as-is, but tested it now with a custom > /tmp/resolv.conf.manual file and it also works well with added DNSSEC > checks. As if working around the time problem was not headache enough... I note that until now the dnssec implementation was NOT doing negative proofs (proofs of non-existence of a signature), as I added dnssec-check-unsigned to /etc/dnsmasq.conf in this release. dnssec dnssec-check-unsigned I do forsee this (and dnssec in general) causing massive problems in environments that muck with dns. I have no idea as to how prevalent this problem is. I'd like for it to not fail silently, but fall back to non-dnssec behavior in some way that gives the user a chance to figure out why their network isn't working and who to point a finger at. Automagically falling back to 8.8.8.8 doesn't bother me much, except in pla= ces where that is blocked too. Anyway. 1) You can specify your dns servers in /etc/config/network, and disable fet= ching your providers's addresses via adding option 'dns' '8.8.8.8 4.4.4.4' option 'peerdns' '0' to the ge00 declaration. This will do the right thing to resolv.conf.auto. Another thing the above is useful for if you have working ipv6 via dhcppd, you will get the ipv6 dns servers from upstream and use those only.... (otherwise dn= smasq will choose the "best" upstream and generally chooses the ipv4 one) 2) Alternatively, you can disable dnssec by commenting it out in /etc/dnsmasq.conf 3) Of course, I advocate pestering your provider to enable dnssec, (and ipv= 6) also. I would like to obsolete resolve.conf.auto in favor of some of the new options to dnsmasq -(-revaddr and another I forget), which will make resolv= ing multi-homed and dns through vpns saner and easier 4) I'd like to benchmark the impact of the non-existence proofs... > > -- > Robert Bradley > > > > _______________________________________________ > 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