From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 851D621F1F7 for ; Sat, 12 Apr 2014 13:28:55 -0700 (PDT) Received: from hms-beagle-3.home.lan ([217.86.120.237]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LcVOE-1XIYBJ23Zm-00ju6v; Sat, 12 Apr 2014 22:28:51 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: <000001cf567f$80b2f1c0$8218d540$@riepnet.com> Date: Sat, 12 Apr 2014 22:28:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000001cf567f$80b2f1c0$8218d540$@riepnet.com> To: Frits Riep , "Valdis.Kletnieks@vt.edu" X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:P8kAMHw2om4BQBEcVV4j8VY/8u9/R/2X9zipvdYs7otuelkB7CR 2v3nc8/7BwXZThpYnLDXVt/3gDX3scnIPhIafONTzQ5AyXFln8aQjN+1SvblNTHP4F0ofjz gzbzm6OUUD3X/RwI97FzkWFtZFl3eSGGUqd1H0gRhIvTQ7cAUaIb3DGSoqqFUn5K98XV5P8 ZgZfKXC8PCCPllu7NGrzg== 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, 12 Apr 2014 20:28:56 -0000 Hi Frits, On Apr 12, 2014, at 20:46 , Frits Riep wrote: > I have a Netgear WNDR-3800 and I last updated the firmware about a = week ago > 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. >=20 > 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 = that > you choose the generic image format for your platform. >=20 > Please advise if I need to do something different, or have I found a = bug. I think Valdis Kletnieks reported the same for a 3800. Please = try the "manual" route described below and report back your results to = the list: Here is the recipe I used, this should work for you as well, if you = adjust the pathes and image names and run from a unix (no idea about = windows) scp /path/to/the/sysupgrade/image.bin root@gw.home.lan:/tmp ssh root@gw.home.lan cd /tmp sysupgrade -n -d 60 -v ./image.bin Note the "-v" will make sysupgrade a bit chattier and might help = pinpoint the cause of the failure (unless it is not a sysupgrade issue = but a GUI issue) Note two if the GUI would be borked that would be a case of poetic = balance as we had the script non-functional for a while while the GUI = still worked ;) Best Regards Sebastian >=20 > thanks >=20 > -----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 >=20 > Send Cerowrt-devel mailing list submissions to > cerowrt-devel@lists.bufferbloat.net >=20 > 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 >=20 > You can reach the person managing the list at > cerowrt-devel-owner@lists.bufferbloat.net >=20 > When replying, please edit your Subject line so it is more specific = than > "Re: Contents of Cerowrt-devel digest..." >=20 >=20 > Today's Topics: >=20 > 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) >=20 >=20 > ---------------------------------------------------------------------- >=20 > 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" >=20 >=20 > I'm afraid it's not *just* underfunded. I reviewed the details of = the code > involved and the fixes, and my conclusion is that even programmers of > security software have not learned how to think about design, testing, = etc. > Especially the continuing use of C in a large shared process address = space > for writing protocols that are by definition in the "security kernel" > (according to the original definition) of applications on which the = public > depends. >=20 > 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 = vice > versa. Yet the SSL libraries are linked in, in userspace, with the > application code. >=20 > Also, upgrades/changes to protocols related to security (which always = should > have been in place on every end-to-end connection) should be reviewed = *both > at the protocol design level* and also at the *implementation level* = because > 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. >=20 > 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 = Multics > 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 = expected > to last until the remaining bits could be added)). >=20 > The open source movement, unfortunately, made a monoculture of the SSL > source code, so it's much more dangerous and the vulnerable attack = surface > of deployments is enormous. >=20 > Rant off. The summary is that good engineering is not applied where = it must > be for the public interest. That remains true even if the NSA = actually > snuck this code into the SSL implementation. >=20 >=20 > On Friday, April 11, 2014 2:22pm, "Dave Taht" = said: >=20 >=20 >=20 >> http://www.wired.com/2014/04/heartbleedslesson/ >>=20 >> And Dan Kaminisky writes about "Code in the Age of Cholera" >>=20 >> http://dankaminsky.com/2014/04/10/heartbleed/ >>=20 >>=20 >>=20 >> -- >> Dave T?ht >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > = 5a81cc38/attachment-0001.html> >=20 > ------------------------------ >=20 > 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" >=20 > 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. >=20 > The resulting queries are: >=20 > root@cerowrt:~# dig www.cloudflare.com A IN >=20 > ; <<>> DiG 9.9.4 <<>> www.cloudflare.com A IN ;; global options: +cmd = ;; Got > answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23776 ;; flags: = qr rd > ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A >=20 > ;; 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 >=20 > root@cerowrt:~# dig +adflag www.cloudflare.com A IN >=20 > ; <<>> 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 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A >=20 > ;; 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 >=20 > root@cerowrt:~# dig +cdflag www.cloudflare.com A IN >=20 > ; <<>> 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 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A >=20 > ;; 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 >=20 > ;; 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 >=20 > root@cerowrt:~# dig @8.8.8.8 www.cloudflare.com A IN >=20 > ; <<>> 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 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A >=20 > ;; 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 >=20 > ;; 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 >=20 > root@cerowrt:~# dig @8.8.8.8 +adflag www.cloudflare.com A IN >=20 > ; <<>> DiG 9.9.4 <<>> @8.8.8.8 +adflag www.cloudflare.com A IN ; (1 = server > 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 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A >=20 > ;; 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 >=20 > ;; 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 >=20 > root@cerowrt:~# dig @8.8.8.8 +cdflag www.cloudflare.com A IN >=20 > ; <<>> DiG 9.9.4 <<>> @8.8.8.8 +cdflag www.cloudflare.com A IN ; (1 = server > 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 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.cloudflare.com. IN A >=20 > ;; 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 >=20 > ;; 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 >=20 > root@cerowrt:~# >=20 > Can anyone explain why this should be the case? >=20 > -- > Robert Bradley >=20 >=20 > -------------- 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> >=20 > ------------------------------ >=20 > 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 >=20 > Robert Bradley writes: >=20 >> Can anyone explain why this should be the case? >=20 > 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 = :) >=20 > -Toke >=20 >=20 > ------------------------------ >=20 > 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" >=20 > 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. >=20 > If it helps, it seems to be an issue with dnssec-check-unsigned again.=20= > 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.) >=20 > --=20 > Robert Bradley >=20 >=20 > -------------- 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> >=20 > ------------------------------ >=20 > 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 >=20 > 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... >=20 > Still on 3.10.34-4 right now. >=20 > 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. >>=20 >> --=20 >> David P. >>=20 >=20 >=20 > ------------------------------ >=20 > 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" >=20 > On 12/04/2014 12:11, Toke H?iland-J?rgensen wrote: >> Robert Bradley writes: >>=20 >>> 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 = :) >>=20 >> -Toke >=20 > OK, with log-queries on I get: >=20 > 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 >=20 > Running tcpdump -i ge00 port 53 -v -v -n during a query from Windows 7 > nslookup, I see: >=20 > 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) >=20 > 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. >=20 > --=20 > Robert Bradley >=20 >=20 > -------------- 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> >=20 > ------------------------------ >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 > End of Cerowrt-devel Digest, Vol 29, Issue 22 > ********************************************* >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel