From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (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 C502421F231 for ; Sat, 19 Apr 2014 12:12:18 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so1486299wgh.23 for ; Sat, 19 Apr 2014 12:12:17 -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=Z7k1uCW84Wm2jxZjNXdZbGJHtKaA0NMBVBCaiGlUKJk=; b=Mzz2FUqksxmgp0BQl5TZ67mFo4/hs9PIEx0xd/RQ85+3acHUEUQsO/1hTBNpkTFXlx mN+zSP746AKttY29enwoABngzQWO0C/d09U3wGNP1goUaAr5y60w8Nso9wMItcz+OarP Gt0FntmUIB6Fs6k/fWNyA453BgwYyf74Tv8K5i2poAMcP1BM1LHe6U9TvipoqJjIVLEm A6skbFYtW/vhft2SGHNr+JlhO4eE/ZH8rn01SvaAVQKaPvbH+HxiYryPBuAJY2LtB95m PGuMSbzKXz//aQR2IV2kzkrdKpF213TzUJQYzh1XxmRzdvYSbnwuMJBhrZei9vLrF7nP NF9A== MIME-Version: 1.0 X-Received: by 10.180.19.167 with SMTP id g7mr7573974wie.46.1397934736907; Sat, 19 Apr 2014 12:12:16 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Sat, 19 Apr 2014 12:12:16 -0700 (PDT) In-Reply-To: <000001cf567f$80b2f1c0$8218d540$@riepnet.com> References: <000001cf567f$80b2f1c0$8218d540$@riepnet.com> Date: Sat, 19 Apr 2014 12:12:16 -0700 Message-ID: From: Dave Taht To: Frits Riep Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4 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: Sat, 19 Apr 2014 19:12:19 -0000 I just tried a sysupgrade from 3.10.36-1 to 3.10.36-6 and saw this error go= by: Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not = found Error fixing up TRX header The upgrade did indeed succeed, regardless, and kept the files in place. The only "big" update to the conf files I think I've made to the default config since -1 was enabling dnssec-check-unsigned by default in /etc/dnsmasq.conf Going to go beat up wifi for a while today and look into some other dnssec issues. On Sat, Apr 12, 2014 at 11:46 AM, Frits Riep wrote: > I have a Netgear WNDR-3800 and I last updated the firmware about a week a= go > successfully using the web interface. I've been trying today to upgrade = to > the latest image the same way, but I am not having success and I've tried > the download several times and even with three different browsers but the > result is the same. > > Current Image is 3.10.36-3 > Using this new image for 3.10.36-4: > openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin > Error Message: > The uploaded image file does not contain a supported format. Make sure th= at > you choose the generic image format for your platform. > > Please advise if I need to do something different, or have I found a bug. > > thanks > > -----Original Message----- > From: cerowrt-devel-bounces@lists.bufferbloat.net > [mailto:cerowrt-devel-bounces@lists.bufferbloat.net] On Behalf Of > cerowrt-devel-request@lists.bufferbloat.net > Sent: Saturday, April 12, 2014 7:54 AM > To: cerowrt-devel@lists.bufferbloat.net > Subject: Cerowrt-devel Digest, Vol 29, Issue 22 > > Send Cerowrt-devel mailing list submissions to > cerowrt-devel@lists.bufferbloat.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.bufferbloat.net/listinfo/cerowrt-devel > or, via email, send a message with subject or body 'help' to > cerowrt-devel-request@lists.bufferbloat.net > > You can reach the person managing the list at > cerowrt-devel-owner@lists.bufferbloat.net > > When replying, please edit your Subject line so it is more specific than > "Re: Contents of Cerowrt-devel digest..." > > > Today's Topics: > > 1. Re: wired article about bleed and bloat and underfunded > critical infrastructure (dpreed@reed.com) > 2. DNSSEC failure for *.cloudflare.com via dnsmasq? (Robert Bradley) > 3. Re: DNSSEC failure for *.cloudflare.com via dnsmasq? > (Toke H?iland-J?rgensen) > 4. Re: DNSSEC failure for *.cloudflare.com via dnsmasq? > (Robert Bradley) > 5. Re: cerowrt-3.10.36-4 released (Neil Shepperd) > 6. Re: DNSSEC failure for *.cloudflare.com via dnsmasq? > (Robert Bradley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 11 Apr 2014 15:43:19 -0400 (EDT) > From: dpreed@reed.com > To: "Dave Taht" > Cc: "cerowrt-devel@lists.bufferbloat.net" > , bloat > > Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and > underfunded critical infrastructure > Message-ID: <1397245399.392818481@apps.rackspace.com> > Content-Type: text/plain; charset=3D"utf-8" > > > I'm afraid it's not *just* underfunded. I reviewed the details of the c= ode > involved and the fixes, and my conclusion is that even programmers of > security software have not learned how to think about design, testing, et= c. > Especially the continuing use of C in a large shared process address spac= e > for writing protocols that are by definition in the "security kernel" > (according to the original definition) of applications on which the publi= c > depends. > > Ever since I was part of the Multics Security Project (which was part of = the > effort that produced the Orange Book > http://csrc.nist.gov/publications/history/dod85.pdf) in the 80's, we've > known that security-based code should not be exposed to user code and vic= e > versa. Yet the SSL libraries are linked in, in userspace, with the > application code. > > Also, upgrades/changes to protocols related to security (which always sho= uld > have been in place on every end-to-end connection) should be reviewed *bo= th > at the protocol design level* and also at the *implementation level* beca= use > change creates risk. They should not be adopted blindly without serious > examination and pen-testing, yet this change just was casually thrown in = in > a patch release. > > I suspect that even if it were well funded, the folks who deploy the > technology would be slapdash at best. Remember the Y2K issue and the cost= of > lazy thinking about dates. (I feel a little superior because in 1968 Mult= ics > standardized on a 72-bit hardware microsecond-resolution hardware clock > because the designers actually thought about long-lived systems (actually > only 56 bits of the original clock worked, but the hardware was not expec= ted > to last until the remaining bits could be added)). > > The open source movement, unfortunately, made a monoculture of the SSL > source code, so it's much more dangerous and the vulnerable attack surfac= e > of deployments is enormous. > > Rant off. The summary is that good engineering is not applied where it m= ust > be for the public interest. That remains true even if the NSA actually > snuck this code into the SSL implementation. > > > On Friday, April 11, 2014 2:22pm, "Dave Taht" said: > > > >> http://www.wired.com/2014/04/heartbleedslesson/ >> >> And Dan Kaminisky writes about "Code in the Age of Cholera" >> >> http://dankaminsky.com/2014/04/10/heartbleed/ >> >> >> >> -- >> Dave T?ht >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 5a81cc38/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Sat, 12 Apr 2014 12:06:55 +0100 > From: Robert Bradley > To: cerowrt-devel > Subject: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via > dnsmasq? > Message-ID: <53491E4F.4040108@gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > I noticed today that attempts to visit www.cloudflare.com and other > subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when DNSS= EC > checks are enabled, but not if I query Google DNS directly. > > The resulting queries are: > > root@cerowrt:~# dig www.cloudflare.com A IN > > ; <<>> DiG 9.9.4 <<>> www.cloudflare.com A IN ;; global options: +cmd ;; = Got > answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23776 ;; flags: qr r= d > ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A > > ;; Query time: 808 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Apr 12 11:04:10 UTC 2014 > ;; MSG SIZE rcvd: 47 > > root@cerowrt:~# dig +adflag www.cloudflare.com A IN > > ; <<>> DiG 9.9.4 <<>> +adflag www.cloudflare.com A IN ;; global options: > +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3689 ;; flags: qr rd > ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A > > ;; Query time: 913 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Apr 12 11:04:21 UTC 2014 > ;; MSG SIZE rcvd: 47 > > root@cerowrt:~# dig +cdflag www.cloudflare.com A IN > > ; <<>> DiG 9.9.4 <<>> +cdflag www.cloudflare.com A IN ;; global options: > +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19768 ;; flags: qr rd= ra > cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A > > ;; ANSWER SECTION: > www.cloudflare.com. 297 IN CNAME > www.cloudflare.com.cdn.cloudflare.net. > www.cloudflare.com.cdn.cloudflare.net. 297 IN CNAME > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 297 IN A > 198.41.212.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net= . > 297 IN A 198.41.213.157 > > ;; Query time: 22 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Apr 12 11:04:26 UTC 2014 > ;; MSG SIZE rcvd: 169 > > root@cerowrt:~# dig @8.8.8.8 www.cloudflare.com A IN > > ; <<>> DiG 9.9.4 <<>> @8.8.8.8 www.cloudflare.com A IN ; (1 server found)= ;; > global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31488 ;; flags: qr rd > ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A > > ;; ANSWER SECTION: > www.cloudflare.com. 84 IN CNAME > www.cloudflare.com.cdn.cloudflare.net. > www.cloudflare.com.cdn.cloudflare.net. 166 IN CNAME > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 166 IN A > 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net= . > 166 IN A 198.41.212.157 > > ;; Query time: 22 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Sat Apr 12 11:04:35 UTC 2014 > ;; MSG SIZE rcvd: 169 > > root@cerowrt:~# dig @8.8.8.8 +adflag www.cloudflare.com A IN > > ; <<>> DiG 9.9.4 <<>> @8.8.8.8 +adflag www.cloudflare.com A IN ; (1 serve= r > found) ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59486 ;; flags: qr rd > ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A > > ;; ANSWER SECTION: > www.cloudflare.com. 77 IN CNAME > www.cloudflare.com.cdn.cloudflare.net. > www.cloudflare.com.cdn.cloudflare.net. 159 IN CNAME > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 159 IN A > 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net= . > 159 IN A 198.41.212.157 > > ;; Query time: 22 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Sat Apr 12 11:04:41 UTC 2014 > ;; MSG SIZE rcvd: 169 > > root@cerowrt:~# dig @8.8.8.8 +cdflag www.cloudflare.com A IN > > ; <<>> DiG 9.9.4 <<>> @8.8.8.8 +cdflag www.cloudflare.com A IN ; (1 serve= r > found) ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43503 ;; flags: qr rd= ra > cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A > > ;; ANSWER SECTION: > www.cloudflare.com. 69 IN CNAME > www.cloudflare.com.cdn.cloudflare.net. > www.cloudflare.com.cdn.cloudflare.net. 151 IN CNAME > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. 151 IN A > 198.41.213.157 cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net= . > 151 IN A 198.41.212.157 > > ;; Query time: 26 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Sat Apr 12 11:04:48 UTC 2014 > ;; MSG SIZE rcvd: 169 > > root@cerowrt:~# > > Can anyone explain why this should be the case? > > -- > Robert Bradley > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 899 bytes > Desc: OpenPGP digital signature > URL: > 4de94408/attachment-0001.pgp> > > ------------------------------ > > Message: 3 > Date: Sat, 12 Apr 2014 13:11:56 +0200 > From: Toke H?iland-J?rgensen > To: Robert Bradley > Cc: cerowrt-devel > Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via > dnsmasq? > Message-ID: <878urakdj7.fsf@alrua-x1.kau.toke.dk> > Content-Type: text/plain > > Robert Bradley writes: > >> Can anyone explain why this should be the case? > > If you turn on log-queries in the dnsmasq config, you can see the > results of the dnssec validation in the logs which might give a hint :) > > -Toke > > > ------------------------------ > > Message: 4 > Date: Sat, 12 Apr 2014 12:13:25 +0100 > From: Robert Bradley > To: cerowrt-devel > Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via > dnsmasq? > Message-ID: <53491FD5.4020600@gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > On 12/04/2014 12:06, Robert Bradley wrote: >> I noticed today that attempts to visit www.cloudflare.com and other >> subdomains seem to be failing on the latest CeroWRT (3.10.36-4) when >> DNSSEC checks are enabled, but not if I query Google DNS directly. > > If it helps, it seems to be an issue with dnssec-check-unsigned again. > This time though was via Google's DNS. (Using the Virgin Media DNS > servers, dnssec-check-unsigned kills all DNS as per my previous posts.) > > -- > Robert Bradley > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 899 bytes > Desc: OpenPGP digital signature > URL: > 04b015bc/attachment-0001.pgp> > > ------------------------------ > > Message: 5 > Date: Sat, 12 Apr 2014 21:45:09 +1000 > From: Neil Shepperd > To: cerowrt-devel@lists.bufferbloat.net > Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released > Message-ID: <53492745.90101@gmail.com> > Content-Type: text/plain; charset=3DISO-8859-1 > > Bad news, or perhaps "interesting news": I just managed to trigger the > bug while testing with sw00 configured to use sfq. I don't know anything > about the qdiscs code (maybe even sfq and fq_codel share code), but this > might not be a bug in fq_codel... > > Still on 3.10.34-4 right now. > > On 11/04/14 19:50, David Personette wrote: >> I just thought of it now, but at Dave's suggestion (because of having a >> DSL with only 4/.5), I was using nfq_codel instead of straight up >> fq_codel. Could the difference in the nfq_codel code path have protected >> me from the bug? Just thought that it might be a clue for Felix... >> hopefully not a red herring. Thanks all. >> >> -- >> David P. >> > > > ------------------------------ > > Message: 6 > Date: Sat, 12 Apr 2014 12:53:29 +0100 > From: Robert Bradley > To: Toke H?iland-J?rgensen > Cc: cerowrt-devel > Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via > dnsmasq? > Message-ID: <53492939.4090508@gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > On 12/04/2014 12:11, Toke H?iland-J?rgensen wrote: >> Robert Bradley writes: >> >>> Can anyone explain why this should be the case? >> If you turn on log-queries in the dnsmasq config, you can see the >> results of the dnssec validation in the logs which might give a hint :) >> >> -Toke > > OK, with log-queries on I get: > > Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: query[A] > www.cloudflare.com from 127.0.0.1 > Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: forwarded > www.cloudflare.com to 8.8.4.4 > Sat Apr 12 11:41:50 2014 daemon.info dnsmasq[14581]: dnssec-query[DS] > www.cloudflare.com to 8.8.4.4 > Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded > www.cloudflare.com to 8.8.8.8 > Sat Apr 12 11:41:51 2014 daemon.info dnsmasq[14581]: forwarded > www.cloudflare.com to 8.8.4.4 > Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply > www.cloudflare.com is BOGUS DS > Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: validation result > is BOGUS > Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply > www.cloudflare.com is > Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply > www.cloudflare.com.cdn.cloudflare.net is > Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.213.= 157 > Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net is 198.41.212.= 157 > > Running tcpdump -i ge00 port 53 -v -v -n during a query from Windows 7 > nslookup, I see: > > 11:44:44.884477 IP (tos 0x90, ttl 64, id 16465, offset 0, flags [DF], > proto UDP (17), length 75) > 86.1.32.208.44272 > 8.8.8.8.53: [udp sum ok] 20890+ [1au] A? > www.cloudflare.com. ar: . OPT UDPsize=3D4096 OK (47) > 11:44:44.884652 IP (tos 0x90, ttl 64, id 26115, offset 0, flags [DF], > proto UDP (17), length 75) > 86.1.32.208.44272 > 8.8.4.4.53: [udp sum ok] 20890+ [1au] A? > www.cloudflare.com. ar: . OPT UDPsize=3D4096 OK (47) > 11:44:44.904068 IP (tos 0x0, ttl 47, id 47459, offset 0, flags [none], > proto UDP (17), length 197) > 8.8.8.8.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A? > www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME > www.cloudflare.com.cdn.cloudflare.net., > www.cloudflare.com.cdn.cloudflare.net. CNAME > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net., > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A > 198.41.212.157, > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A > 198.41.213.157 ar: . OPT UDPsize=3D512 OK (169) > 11:44:44.904120 IP (tos 0x0, ttl 45, id 57740, offset 0, flags [none], > proto UDP (17), length 197) > 8.8.4.4.53 > 86.1.32.208.44272: [udp sum ok] 20890 q: A? > www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME > www.cloudflare.com.cdn.cloudflare.net., > www.cloudflare.com.cdn.cloudflare.net. CNAME > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net., > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A > 198.41.212.157, > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. A > 198.41.213.157 ar: . OPT UDPsize=3D512 OK (169) > 11:44:44.904720 IP (tos 0x90, ttl 64, id 16466, offset 0, flags [DF], > proto UDP (17), length 75) > 86.1.32.208.60232 > 8.8.8.8.53: [udp sum ok] 43145+ [1au] DS? > www.cloudflare.com. ar: . OPT UDPsize=3D4096 OK (47) > 11:44:45.430963 IP (tos 0x0, ttl 49, id 13829, offset 0, flags [none], > proto UDP (17), length 75) > 8.8.8.8.53 > 86.1.32.208.60232: [udp sum ok] 43145 ServFail q: DS? > www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=3D512 OK (47) > 11:44:45.434094 IP (tos 0x90, ttl 64, id 16467, offset 0, flags [DF], > proto UDP (17), length 75) > 86.1.32.208.27765 > 8.8.8.8.53: [udp sum ok] 6810+ [1au] AAAA? > www.cloudflare.com. ar: . OPT UDPsize=3D4096 OK (47) > 11:44:45.455145 IP (tos 0x0, ttl 47, id 13830, offset 0, flags [none], > proto UDP (17), length 221) > 8.8.8.8.53 > 86.1.32.208.27765: [udp sum ok] 6810 q: AAAA? > www.cloudflare.com. 4/0/1 www.cloudflare.com. CNAME > www.cloudflare.com.cdn.cloudflare.net., > www.cloudflare.com.cdn.cloudflare.net. CNAME > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net., > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA > 2400:cb00:2048:1::c629:d59d, > cf-ssl2463-protected-www.cloudflare.com.cdn.cloudflare.net. AAAA > 2400:cb00:2048:1::c629:d49d ar: . OPT UDPsize=3D512 OK (193) > 11:44:45.455845 IP (tos 0x90, ttl 64, id 16468, offset 0, flags [DF], > proto UDP (17), length 75) > 86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [1au] DS? > www.cloudflare.com. ar: . OPT UDPsize=3D4096 OK (47) > 11:44:45.895583 IP (tos 0x0, ttl 47, id 16395, offset 0, flags [none], > proto UDP (17), length 75) > 8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS? > www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=3D512 OK (47) > 11:44:45.896049 IP (tos 0x90, ttl 64, id 26116, offset 0, flags [DF], > proto UDP (17), length 75) > 86.1.32.208.63524 > 8.8.4.4.53: [udp sum ok] 37758+ [b2&3=3D0x182] > [1au] DS? www.cloudflare.com. ar: . OPT UDPsize=3D512 OK (47) > 11:44:45.896242 IP (tos 0x90, ttl 64, id 16469, offset 0, flags [DF], > proto UDP (17), length 75) > 86.1.32.208.63524 > 8.8.8.8.53: [udp sum ok] 37758+ [b2&3=3D0x182] > [1au] DS? www.cloudflare.com. ar: . OPT UDPsize=3D512 OK (47) > 11:44:46.335616 IP (tos 0x0, ttl 46, id 44525, offset 0, flags [none], > proto UDP (17), length 75) > 8.8.4.4.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS? > www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=3D512 OK (47) > 11:44:46.341564 IP (tos 0x0, ttl 47, id 47460, offset 0, flags [none], > proto UDP (17), length 75) > 8.8.8.8.53 > 86.1.32.208.63524: [udp sum ok] 37758 ServFail q: DS? > www.cloudflare.com. 0/0/1 ar: . OPT UDPsize=3D512 OK (47) > > That seems to suggest that it's the DS queries that are failing and that > this is probably not a dnsmasq bug. Trying Verisign's DNSSEC debugger > (http://dnssec-debugger.verisignlabs.com/blog.cloudflare.com) seems to > suggest that their nameservers refuse requests for DNSKEY records. > > -- > Robert Bradley > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 899 bytes > Desc: OpenPGP digital signature > URL: > f7c270a9/attachment.pgp> > > ------------------------------ > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > End of Cerowrt-devel Digest, Vol 29, Issue 22 > ********************************************* > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article