From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (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 6B56B21F207 for ; Sat, 12 Apr 2014 11:47:21 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so6891129qgd.9 for ; Sat, 12 Apr 2014 11:47:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=bqexpzziuK1FH5ZXCgEWF7fCzDlQAU7WZwP505pydFs=; b=MPa3jEC3rstrc6hhJWRzQfbEiiBhMlyhjUk7/7rDNbvRQWw9km5fxuqUDMkQ5icPkc zXDVFl4W9ISHCXCD6V40LLgvrZfsTfgyZjGyQ30HxotScNBB2phC4u0oZeZMnGA127mH YzXsOD0pvL0G5YfwJsJ84WXgItNeUZm2ObujPkzZVZZPeX3//86SOYex/jR+lZ45adwh oG69zeHUXjLofcb21vKEJ6tDRSkbcAqjFRlmjQdD5vUcxgdfRLGMMLXZCzwNs9K0zSR1 YUvb1oqMYgd/zpa7M8I1LQWcgav2aJaal2hWFu3HBAkO6uRzmY0V4UbblW3K+nSevrRD fqcw== X-Gm-Message-State: ALoCoQkZEfjFE3Jk03hjxdOVPKmrDUjxmC5O4Hga0bUVWYjS34H2tipatRrbLY05p/meN4hSQ0yN X-Received: by 10.224.56.5 with SMTP id w5mr7840841qag.60.1397328440012; Sat, 12 Apr 2014 11:47:20 -0700 (PDT) Received: from riepPC3 (pool-108-49-217-37.bstnma.fios.verizon.net. [108.49.217.37]) by mx.google.com with ESMTPSA id m4sm5050857qae.35.2014.04.12.11.47.19 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 12 Apr 2014 11:47:19 -0700 (PDT) From: "Frits Riep" To: Date: Sat, 12 Apr 2014 14:46:22 -0400 Message-ID: <000001cf567f$80b2f1c0$8218d540$@riepnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9Wf4ALQxYTRu3URX6Q7OCNMDFBeA== Content-Language: en-us Subject: [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 18:47:21 -0000 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. 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="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" 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: ------------------------------ 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="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: ------------------------------ 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="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: ------------------------------ 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=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 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="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=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: ------------------------------ _______________________________________________ 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 *********************************************