Hi Frits,
On Apr 12, 2014, at 20:46 , Frits Riep <[email protected]> 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. > > 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. > > 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 [email protected]:/tmp ssh [email protected] 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 > > thanks > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Saturday, April 12, 2014 7:54 AM > To: [email protected] > Subject: Cerowrt-devel Digest, Vol 29, Issue 22 > > Send Cerowrt-devel mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 ([email protected]) > 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: [email protected] > To: "Dave Taht" <[email protected]> > Cc: "[email protected]" > <[email protected]>, bloat > <[email protected]> > Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and > underfunded critical infrastructure > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > > 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. > > 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. > > 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. > > 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)). > > 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. > > 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. > > > On Friday, April 11, 2014 2:22pm, "Dave Taht" <[email protected]> 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 >> [email protected] >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140411/ > 5a81cc38/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Sat, 12 Apr 2014 12:06:55 +0100 > From: Robert Bradley <[email protected]> > To: cerowrt-devel <[email protected]> > Subject: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via > dnsmasq? > Message-ID: <[email protected]> > Content-Type: text/plain; charset="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 DNSSEC > 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 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: 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 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 > > ;; 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 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 > > ;; 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: > <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/ > 4de94408/attachment-0001.pgp> > > ------------------------------ > > Message: 3 > Date: Sat, 12 Apr 2014 13:11:56 +0200 > From: Toke H?iland-J?rgensen <[email protected]> > To: Robert Bradley <[email protected]> > Cc: cerowrt-devel <[email protected]> > Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via > dnsmasq? > Message-ID: <[email protected]> > Content-Type: text/plain > > Robert Bradley <[email protected]> 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 <[email protected]> > To: cerowrt-devel <[email protected]> > Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via > dnsmasq? > Message-ID: <[email protected]> > Content-Type: text/plain; charset="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: > <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/ > 04b015bc/attachment-0001.pgp> > > ------------------------------ > > Message: 5 > Date: Sat, 12 Apr 2014 21:45:09 +1000 > From: Neil Shepperd <[email protected]> > To: [email protected] > Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-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 <[email protected]> > To: Toke H?iland-J?rgensen <[email protected]> > Cc: cerowrt-devel <[email protected]> > Subject: Re: [Cerowrt-devel] DNSSEC failure for *.cloudflare.com via > dnsmasq? > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > On 12/04/2014 12:11, Toke H?iland-J?rgensen wrote: >> Robert Bradley <[email protected]> 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 <CNAME> > Sat Apr 12 11:41:52 2014 daemon.info dnsmasq[14581]: reply > www.cloudflare.com.cdn.cloudflare.net is <CNAME> > 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=4096 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=4096 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=512 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=512 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=4096 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=512 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=4096 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=512 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=4096 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=512 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=0x182] > [1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 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=0x182] > [1au] DS? www.cloudflare.com. ar: . OPT UDPsize=512 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=512 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=512 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: > <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140412/ > f7c270a9/attachment.pgp> > > ------------------------------ > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > End of Cerowrt-devel Digest, Vol 29, Issue 22 > ********************************************* > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
